AI API pricing is usually presented as a few rates per million tokens. That looks straightforward until a real application starts making thousands of requests. The same model can charge different rates for newly processed input, previously cached input, cache writes and generated output. A comparison based only on the headline input rate can therefore miss the largest part of the bill.
To make the distinction concrete, Unhyd modeled two hypothetical workloads using the standard, short-context API rates published for OpenAI's GPT-6.1 Sol, inspected on October 18, 2026. This is a transparent calculation, not an audit of a customer's invoices, a performance benchmark or a forecast of anyone's actual spending. It illustrates a more general budgeting problem: the price of a token depends on what that token is doing.
Four token categories, not one headline price
At the time of this review, the official standard short-context price table listed GPT-6.1 Sol at $2 per million regular input tokens, $0.10 per million cached-input reads, $2.50 per million cache-write tokens and $10 per million output tokens. The rates are not interchangeable. A cached read represents eligible context reused from an earlier computation; a cache write records a reusable prefix; and output tokens are generated by the model. Other models and service tiers have different prices.
The provider's prompt-caching guide explains that a cache can reuse an unchanged prompt prefix, but eligibility, minimum prefix length, cache retention and actual reuse all matter. It also cautions against assuming that a shorter prompt is automatically cheaper than a longer cacheable one: the answer depends on how often the prefix will be reused and the cost of writes. A prompt with a shared instruction block and variable material at the end may be more cache-friendly than one whose beginning changes with every request.
A worked example: 10,000 calls, two bills
Consider a hypothetical service that makes 10,000 model calls during a reporting period. Each call averages 4,000 input tokens and 1,000 output tokens. Across the period, that is 40 million input tokens and 10 million output tokens. Assume standard short-context processing, with no additional tool, storage, regional, batch or other feature charges. The workload is deliberately simplified to expose the arithmetic.
Scenario A: no cache reuse. All 40 million input tokens are billed at $2 per million, costing $80. The 10 million output tokens cost $100 at $10 per million. The modeled total is $180.
Scenario B: a measured-style token mix, but still hypothetical. Suppose those same 40 million input tokens are classified as 10 million regular input tokens, 28 million cached-input reads and 2 million cache-write tokens. The categories sum to 40 million; no token is double-counted. Regular input costs $20; cache reads cost $2.80; cache writes cost $5; and output still costs $100. The modeled total becomes $127.80.
The difference is $52.20, or 29% of Scenario A's modeled bill. That is not a promised caching discount. It is the consequence of the assumed token classification and the specific rates above. A different prefix structure, retention window, number of cache writes or output length would change the result.
Why output becomes the largest line item
In Scenario B, output is $100 of the $127.80 total—about 78.2%. If the same workload instead generated 2,000 output tokens per call, output would rise to 20 million tokens and cost $200, lifting the hypothetical bill to $227.80 with the input categories held constant. The extra 1,000 generated tokens per call would add $100, more than the entire modeled regular-input charge.
This is why an application that produces long reports, verbose reasoning traces or repeated agent messages may have a very different cost profile from a short-answer assistant, even if both use the same model. The pricing table alone cannot establish which application is cheaper: it has no knowledge of the actual prompt lengths, response lengths, tool calls, quality requirements or retry behavior.
The hidden variables a price comparison should disclose
Context tier. The same official price table distinguishes short-context from long-context rates for the flagship models. Applying the short-context rates to a request that falls into a higher-priced tier would understate the bill. Check the model's current context thresholds and how its provider applies them before multiplying token counts.
Cache behavior. A high share of repeated text is not necessarily the same as a high share of billable cache reads. The prompt must satisfy the provider's eligibility rules, and the relevant prefix must actually be reusable when the request arrives. The provider documents cache writes and reads as distinct billed categories for GPT-6.1 Sol. Teams should record both rather than assuming all repetition earns the lowest rate.
Work beyond text. Search, file retrieval, image and audio processing, hosted computation, external services and other tools can add charges beyond basic text-token usage. The official pricing page lists separate tool and modality charges. An agent that invokes tools multiple times per user request can cost more than a single-call spreadsheet suggests.
Retries and quality. A cheaper token price is not automatically a cheaper successful task. If a system frequently retries failed outputs or requires a second model to repair them, cost per completed and accepted task may rise. Conversely, an expensive model may be justified for a task where lower error rates reduce manual review. That relationship must be measured in the actual application; this analysis does not compare model accuracy.
A practical cost-per-accepted-task worksheet
For a defensible comparison, begin with one real workflow: for example, extracting fields from a document, answering a customer question or generating a draft. Run a representative sample, then record each request's model, service tier, regular input tokens, cache reads, cache writes, output tokens and tool charges. Include unsuccessful attempts, retries and human corrections. Separate test traffic from production traffic.
Next, calculate total billed cost divided by the number of accepted tasks, not merely total cost divided by API calls. If 1,000 calls produce only 700 usable results, cost per accepted result has a different denominator from cost per call. Report both numbers. Document the quality standard so the metric does not reward cheap but unusable answers.
Then run a sensitivity check. What happens if output doubles? If a stable prefix expires before reuse? If the model moves into a long-context tier? If a tool is invoked twice instead of once? The worked examples above demonstrate why these changes can matter more than a small difference in the headline input rate.
For readers building or auditing AI workflows, Unhyd's AI-agent evaluation guide explains how to test task success before scaling access, while its analysis of AI ROI and accountability examines why claimed returns should be separated from evidence of reliable operation. Both are complementary questions to token cost.
What this analysis does—and does not—prove
The arithmetic proves only that, under the stated prices and hypothetical token distributions, Scenario A costs $180 and Scenario B costs $127.80. It does not establish a typical cache-hit rate, a guaranteed saving, a representative enterprise bill, or a ranking of models or providers. No private invoices, production logs or cross-provider benchmarks were used.
The broader lesson is a measurement rule: compare AI API pricing with the same task, actual billed token categories, complete feature charges and an explicit quality threshold. A per-million-token sticker price is a starting point. The cost of a dependable result is the number that ultimately matters.
