CTXDEX Scenarios: From Model Pricing to AI Solution Economics
CTXDEX started by helping me understand models, commercial offerings, and pricing in a more structured way.
But after a while, another question became harder to ignore: what does the AI solution itself cost — not just the model inside it?
A real AI application is rarely one API call. It may interpret a request, retrieve knowledge, embed and rerank, call search, reason, process documents, generate media, validate its own output, retry, or use shared capacity. So CTXDEX Scenarios grew out of a simple idea: price the solution, not just the model.
Start with the business event
The useful unit is usually not “one million tokens”. It is something closer to one employee question, one document, one engineering task, one research request, one investigation case, or one creative asset.
That business event is then broken into the operations and activities needed to deliver it. A knowledge-assistant request, for example, might involve interpreting the question, preparing retrieval, embedding, searching, reranking, assembling context, generating an answer, and optionally verifying and revising it.
The scenario becomes an economic description of the solution architecture.
Different designs, different economics
One of the ideas I like most is the Design Variant. The business outcome can stay the same while the implementation changes.
A Quick Knowledge Answer may retrieve enough evidence and generate a response. A Verified Knowledge Answer may retrieve more, use a stronger model, add a verification pass, and revise the answer if needed.
The point is not to declare one better. It is to make the trade-off visible: what changed in the design, and what did that change do to the economics?
Providers bill differently from how businesses think
Providers may bill in tokens, queries, document pages, audio minutes, image outputs, video seconds, sessions, or capacity-unit hours. But someone designing a product thinks in cost per support question, per document, per meeting, per engineering task, per creative request, or per investigation.
Scenarios bridges those two levels. That becomes especially important for agentic and multimodal systems, where several very different billing units may contribute to one final business outcome.
Not everything needs a fake price
A workflow can also contain work that is real but not directly provider-priced: database reads, local search, deterministic calculations, application logic, normalization, or human review.
CTXDEX keeps those activities in the scenario without inventing a monetary charge for them. An unpriced activity, a genuine zero price, and an unknown price are different things.
One architecture, many kinds of solution
The broader experiment is to see whether the same scenario model can work across very different AI systems. The current portfolio covers areas such as enterprise support, document processing, research, software engineering agents, realtime voice, image and video production, enterprise knowledge assistants, investigations, BI analysis, sales intelligence, and meeting intelligence.
Together they pressure-test the same underlying approach across text, retrieval, web search, documents, audio, images, video, code execution, allowances, repeated activities, and shared capacity. I find that more interesting than building a separate calculator for every workload.
Where it is now
The CTXDEX pricing engine and Scenario Economics foundation are built and hardened. Customer Support and Enterprise Document Processing form the implemented baseline, while the wider Reference Solution portfolio is being added in controlled waves.
The catalogue and economics remain synthetic, because the point is to test the architecture and product ideas rather than present live provider billing. What I am really exploring is an intermediate layer between provider price cards and business application economics.
Provider pricing tells you what the building blocks cost. CTXDEX Scenarios is my attempt to make the economics of the architecture itself visible.