Why I care about the multipliers more than the rates
I build integrations and APIs at eesel, which means I spend my days on the side of this that nobody blogs about: what a model call actually costs when it is wired into a live support queue rather than a notebook. I have been putting AI agents on real helpdesks for years now, across thousands of tickets a day, and the pattern is consistent enough to be boring.
Here is one that stuck with me. A buyer evaluating us, an email-security company on Freshdesk scaling toward twenty thousand tickets a year, burned through 200 interactions in a single day of testing and came back worried about what nine thousand a month would look like. He was not wrong to worry. He was just worried about the wrong variable. His demo traffic was not what would set his bill; his retrieval prompt size and his service tier were.
That is the whole reason this post is structured the way it is. The rate card comes first because you asked for it, and then the four things that actually move it, because those are what I would look at if you handed me your invoice and asked why it was double last month.
The full OpenAI API pricing card
All figures per 1M tokens in USD, read off OpenAI's pricing page on 17 August 2026. This is the standard tier, short context, which is the version most people mean when they say "OpenAI API pricing".
| Model | Input | Cached input | Cache write | Output | Context window | Max output |
|---|---|---|---|---|---|---|
gpt-5.6-sol | $5.00 | $0.50 | $6.25 | $30.00 | 1,050,000 | 128,000 |
gpt-5.6-terra | $2.00 | $0.20 | $2.50 | $12.00 | 1,050,000 | 128,000 |
gpt-5.6-luna | $0.20 | $0.02 | $0.25 | $1.20 | 1,050,000 | 128,000 |
gpt-5.6-cyber | $12.50 | $1.25 | $15.625 | $75.00 | short context only | 128,000 |
chat-latest | $5.00 | $0.50 | not listed | $30.00 | not listed | not listed |
gpt-5.3-codex | $1.75 | $0.175 | not listed | $14.00 | not listed | not listed |
gpt-5.6 is an alias that routes to Sol. All three flagship models share a Feb 16, 2026 knowledge cutoff and accept reasoning.effort of none, low, medium (the default), high, xhigh and max, per the models catalog. The full lineup, including the older snapshots still callable, is in our OpenAI models list.
Two rows deserve a note. gpt-5.6-cyber is the Daybreak Red model, priced at 2.5x Sol on both sides and with no long-context band offered at all; we broke its rate card down separately in GPT-5.6 Cyber pricing. And chat-latest bills identically to Sol, which is worth knowing if you were assuming the ChatGPT-flavoured endpoint came at a discount. It does not.
The aliases daybreak-blue-latest and daybreak-red-latest currently point at gpt-5.6-sol and gpt-5.6-cyber. OpenAI says both will be repointed as newer frontier models ship through the program, "with pricing adjusted to match each underlying model", so pinning an alias is pinning a price you have not agreed to yet.
The 30 July repricing changed where you put model calls
Two of those rows moved on 30 July 2026, and the shape of the change matters more than the size. Luna dropped 80% to $0.20 and $1.20, Terra dropped 20% to $2.00 and $12.00, and Sol did not move. The reaction on Hacker News was appropriately loud:
"80% price cut for luna is a very aggressive pricing move
makes it by far the best choice for most workloads that do not need bleeding edge intelligence"
The consequence nobody put on the announcement, though, is the one an AI Builders post picked up:
"Luna and Terra now sit 10x apart on both input and output, where the gap was 2.5x. Routing decisions that were rounding errors at $1.00 per million are now the dominant line in a high-volume cost model."
That is exactly right, and it is why any cost model built before August needs rebuilding. A team on Terra that could have run on Luna used to be overpaying by 2.5x. Now they are overpaying by 10x. One production team on the Gemini 3.7 Flash thread said the cut alone was enough to make them re-benchmark:
"gpt-5-mini was the clear pareto frontier leader for our in-house LLM benchmarks -- benchmarks that we built and tailored to our specific use cases. Then gpt-5.6-luna came along with the price cuts and immediately supplanted gpt-5-mini."
The rate on the card is one of eight
This is the part that catches people. Every flagship model on that page has eight published rates, because the card splits two ways at once: four service tiers, and two context bands, each with its own input, cached-input, cache-write and output column.
On output alone, gpt-5.6-sol runs from $15.00 (Batch, short context) to $90.00 (Fast mode, long context). Same weights, same prompt, 6x the price, and the only thing that changed is two fields in your request. The cache dial moves input separately, from $0.50 on a read up to $6.25 on a write.
Which produces the inversion I keep having to explain in calls:
| Configuration | Input | Output |
|---|---|---|
gpt-5.6-sol on Batch, short context | $2.50 | $15.00 |
gpt-5.6-terra on Fast mode, short context | $4.00 | $24.00 |
gpt-5.6-terra on Fast mode, long context | $8.00 | $36.00 |
Terra on Fast mode costs exactly 1.6x Sol on Batch, on both input and output. So a team that "cut costs by dropping from the flagship to the mid-tier model" while leaving service_tier: "fast" in place has increased its bill by 60%. I have watched this happen. The model row really is the least important number on the page.
The 272K cliff
Here is the single most expensive line item that almost nobody budgets for, and it is not on the pricing page at all. It is on the GPT-5.6 Sol model page, in one sentence:
Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request.
Three things follow from that, and all three matter.
First, the threshold is 272,000 input tokens, not the 1,050,000-token context window the marketing leads with. You get roughly a quarter of the advertised window at the advertised price.
Second, it reprices the full request, not the overflow. A 272,001-token prompt does not bill 272,000 tokens at $5 and one token at $10. It bills all 272,001 at $10. It is a cliff, not a ramp.
Third, it moves output as well, at 1.5x, even though the length of your reply has nothing to do with how long the prompt was.
The reason I lead with this rather than bury it is that the mechanic lives on a model page, not the pricing page, and people keep finding it the hard way. Korbinian Abstreiter's LinkedIn post is the version of this I have seen most often:
"I just discovered this in OpenAI's fine print below the pricing: "Prompts with >272K input tokens are priced at 2x input and 1.5x output for the full request."
Imagine during all this time, your most expensive requests were actually 2x of what they should've cost! [...] Still didn't expect it - and it looks like OpenAI doesn't want you to actively read it either..."
His practical takeaway is the right one and I would put it on a wall: compact context before 272K, not at it.
The most convincing evidence that the cliff bites hard, though, is that OpenAI moved a product to dodge it. In July, Codex's default context window was cut from 372k back down to 272k, and the explanation on the Hacker News thread was blunt:
"This was done because they were charging the 100%/50% premium for long-context over 272k to Codex users, even though they set 372k as the default. It cost people a LOT of money."
A shipped default that sat above the surcharge line, walked back as a billing fix. If it caught OpenAI's own product team, it will catch your retrieval config.
To be fair to the design, there is a real cost behind it. Attention is quadratic, so a token at 372K really is more expensive to serve than one at 272K, and one commenter on that same thread put the gap at 87% under purely quadratic attention, which is roughly the size of the step. The complaint that lands is not the price, it is the shape:
"I'm actually surprised it's implemented as a hard cutoff instead of a smooth gradient."
There is also a separate rate limit for long-context requests, which is only visible in the developer console rather than published on the docs page, per the rate limits guide. So the cliff costs you throughput too, not just money. Our writeup on OpenAI rate limits goes further into how those buckets interact.
Worth being fair on the vendor level too: xAI does the same thing. Grok 4.6 carries an equivalent step, and we covered its shape in Grok 4.6 pricing. This is not an OpenAI-only design. It is just that Anthropic and Google chose differently, which I will get to.
What the cliff costs on a real workload
Take a retrieval answer bot on Sol: 40,000 input tokens per request, 900 output, 30,000 requests a month, 50% of the input hitting cache. That is $4,110 a month on standard.
Now suppose someone widens the retrieval window and each request carries 300,000 input tokens instead. Same model, same tier, same volume.
| Input tokens per request | Band | Monthly cost |
|---|---|---|
| 40,000 | short | $4,110 |
| 271,000 | short | $23,168 |
| 300,000 | long | $50,715 |
Trimming the prompt from 300,000 to 271,000 tokens, a cut of under 10%, takes the monthly bill from $50,715 to $23,168. That is a 54% reduction for shaving 29,000 tokens off the top. If you take one operational thing from this post, it is that number: the highest-leverage cost work on OpenAI's API is keeping requests just under 272K, and it beats almost any model swap you could make.
You do not have to take my arithmetic for it. Someone on r/openrouter posted their own reconciliation after auditing a batch of requests:
"Approximately 221 requests exceeded the 272K threshold."
Their billed total for that batch was $2.297 against the $1.35 it would have been at standard rates, on 221 requests they did not know had crossed the line. Small money at that volume, and exactly the same ratio at a hundred times the volume.
Prompt caching gives you 90% off and a 25% penalty
Cached input on Sol is $0.50 against $5.00 uncached, so a read is a 90% discount. That part is well known. The part that is not: cache writes bill at 1.25x the uncached input rate, which the Sol model page states plainly.
This charge is new. It arrived with GPT-5.6 and it was the only line item on Sol that moved at launch, which caught people who had read the card as unchanged:
"There was no cache write before!"
"Charging for cache writes is cringe and literally only Anthropic did it. Anyway this does mean the "real" prices are +25% on top of what you wrote there."
So caching is not a free option you switch on. It is a bet. Write once at $6.25 and read it back even once at $0.50 and you are ahead of the $10.00 you would have paid for two uncached passes. Write it and never read it, and you paid a 25% premium for nothing. The teams this hurts most are the ones whose requests are all unique, which the r/OpenAI thread on it put well:
"Most of our API usage isn't for chat bots or long-running agents. We build task-oriented applications where every request is unique: document processing, …"
There is a real argument on the other side, and Artificial Analysis made it rather than just complaining:
"Charging for a cache write more accurately reflects the model's cost to serve, as cached tokens occupy memory whether or not they are reused."
That is fair. A KV cache is a memory reservation, one entry per input token per layer, held whether you come back or not. Anthropic charges the same 1.25x for a 5-minute write on Claude Opus 5 and 2x for a one-hour write, so this is now how both major vendors price it.
The mechanics that decide whether you win the bet
From the prompt caching guide:
| Mechanic | Value |
|---|---|
| Minimum cacheable prefix, GPT-5.6 and later | 1,024 tokens, a strict minimum |
| Minimum on earlier models | 1,024 to 2,048 tokens, varies by model |
| Cache lifetime | 30 minutes, refreshed on reuse with no new write charge |
| Cache read rate | 10% of the input rate |
| Cache write rate | 125% of the input rate |
| Matching | Exact prefix match at an eligible breakpoint |
| Key requirement | Both requests must share the same prompt_cache_key |
| Throughput per key | About 15 requests per minute before hits start dropping |
| Writes per request | Maximum of 4 |
| Breakpoints considered on read | The latest 50 |
That throughput line is the one I would flag hardest for anyone running a support queue, because it is not a pricing rule and it is easy to miss. The docs say to keep traffic for each prompt_cache_key to roughly 15 requests per minute, because "if a key receives a higher rate, some requests may miss the cache." A busy helpdesk on a single shared key will quietly fall out of cache at peak and pay full input rates exactly when volume is highest. The fix in the docs is to partition across more keys with a stable mapping.
The docs are also explicit that "repeated prompt content alone does not guarantee a cache hit." The failure modes are mundane and expensive, and Eric Nowoslawski's LinkedIn writeup is the clearest statement of them I have found, from someone who got it wrong first:
"As much of your prompt needs to be the same from the beginning of the prompt to whenever you make a change. [...] We were messing it up with putting custom parts of the prompt in the second or third sentence.
Put all that custom stuff at the end and you will have a really high chance of hitting cached inputs."
And here is the credit OpenAI rarely gets. Its 30-minute sliding window is materially better than Anthropic's 5-minute default for anything on a schedule. Roy Derks ran the arithmetic on both for an agent firing every ten minutes with a 100k-token reusable prompt:
"Take a 100k-token reusable prompt and call it 10 times. With Claude's default 5-minute cache, every request arrives after the previous cache expired. So you never get the cheap cache read… Instead of paying $1.00 each time, you pay $1.25 to write a cache entry. $10 without caching becomes $12.50 with caching. [...] OpenAI's GPT-5.6+ cache implementation lasts 30 minutes, and every successful cache hit refreshes that 30-minute window. So in the same example: $5.00 of normal input becomes roughly $1.08."
A cache that survives a ten-minute gap is worth more than a 20% lower write rate, and on that workload OpenAI's design wins outright.
Finally, the number that should temper your model: real hit rates are not the demo hit rates. Ravi Kiran's caching post has both halves of it, a team going from $720 a month to $72 by adding one breakpoint, and the reality check:
"real-world hit rates sit at 20 to 45%, not the 90% the demo shows. You need sticky routing, stable prefixes, and workloads that actually repeat."
Set the slider in the calculator above to 30% rather than 90% and you will get a forecast you can defend.
Reasoning tokens bill at the output rate
All three GPT-5.6 models accept reasoning.effort at none, low, medium, high, xhigh or max, with medium as the default. Those reasoning tokens are billed as output tokens.
This is the multiplier that does not appear on any table because it is not a rate, it is a volume. Turning the dial up does not change your $30.00 per 1M; it changes how many millions you buy. And because medium is the default rather than low, the out-of-the-box configuration is already spending more than the floor.
"Thinking tokens aren't free though. This is not a valid point of view. If I was being charged for the raw, output/input token count, excluding thinking/reasoning token costs, then sure. But at least via the API, you pay for tokens you cannot see."
The knock-on effect is that reasoning effort partly collapses the price gap the model tiers are supposed to represent. One commenter on the Qwen 3.8 Max thread framed it precisely:
"So a mid priced model, with heavy reasoning output, cost the same as a expensive model, with medium reasoning output."
On other models we have measured this properly: Gemini 3.7 Flash scores 50.9 on the Artificial Analysis Intelligence Index at low effort versus 56.0 at high, but costs $0.16 per task instead of $0.40. Five points of index score for 2.5x the money. For reference on the other side, Artificial Analysis puts Sol at $1.04 per task on the same index at max reasoning effort, which it describes as one third the cost of Claude Fable 5.
Here is the most instructive real bill I found on any of this. A developer posted a full breakdown of a 933-session month totalling $19,221 in agentic API spend, and the composition is not what anyone expects: cache reads were 56% of the bill, cache writes 35%, and output including reasoning only 8%, at a 353:1 input-to-output ratio and a 97% cache hit rate.
"Same shape as yours: re-read dominates, reasoning is the biggest re-read line, caching is the only thing keeping it sane."
Read that again, because it inverts the usual advice. On a long-running agent, your invoice is a caching bill, not an output bill, because every turn re-reads the whole accumulated context to add a few thousand tokens. Which means the two numbers that actually decide your cost are the cache read rate and whether your provider has a context cliff. The per-million input price on the front page barely enters into it.
The practical advice is unglamorous: measure your token counts per effort level on your own traffic before you pick one, because the right answer is workload-specific and the default is a guess someone else made. Community A/B tests point the same way, with the only reliably cheaper lever being a tier drop rather than any prompt-compression trick. If you are choosing a model for ticket work specifically, we ran that comparison in AI models for support tickets, and the finding was that retrieval quality moved accuracy far more than model tier did.
Batch, Flex and Fast mode
The four service tiers are the cleanest lever on the card, because they are one field in your request and the price change is exact.
| Tier | Multiplier | What you give up or get | Field value |
|---|---|---|---|
| Batch | 0.5x | 24-hour completion window, no other window offered | Batch API endpoint |
| Flex | 0.5x | Slower responses, occasional resource unavailability | service_tier: "flex" |
| Standard | 1x | The default | none |
| Fast mode | 2x | Up to 2.5x faster, more consistent latency | service_tier: "fast" or "priority" |
A few details from the docs that change how you would use them.
The Batch API gives you the 50% discount plus "a separate pool of significantly higher rate limits", which for Sol at Tier 5 means a 15,000,000,000-token queue limit against a 40,000,000 TPM synchronous cap. The completion window "can only be set to 24h". Hard limits worth knowing before you design around it: 50,000 requests and 200 MB per batch, 2,000 batches an hour, and requests that expire unfinished are cancelled while the ones that did complete are still billed. This is the largest single discount available and it does not degrade output at all, which is why it is the least-argued-about claim in the whole community corpus. The most interesting thing I read about it was someone treating the latency as a product design problem rather than a constraint:
"The other thing I started looking into is batch pricing which represents 50% off for OAI tokens right now. With some tweaks to the UI/UX of an enterprise chatbot, I think it is possible we could have users get comfortable with the idea that questions to the robot might take a day to come back."
The real limit on Batch is model coverage rather than latency. Codex and most Pro-tier models are not available on it, so the discount does not reach the workloads most likely to be expensive. Our Codex pricing breakdown covers that side.
Flex processing is the same 50% off but synchronous, in exchange for "slower response times and occasional resource unavailability". OpenAI positions it for "non-production or lower priority tasks, such as model evaluations, data enrichment, and asynchronous workloads", and the docs recommend raising your client timeout from the SDK default of 10 minutes to 15. One reassuring detail: a 429 Resource Unavailable on Flex is not charged, so a failed attempt costs nothing but the retry logic. A practitioner on the Codex Spark thread reported the added latency in practice as "just a few seconds extra," which is a different picture from what the docs' timeout advice implies. Test it on your own traffic before you rule it out of a user-facing path.
Fast mode was renamed from Priority processing on 30 July 2026, and both service_tier: "priority" and service_tier: "fast" still work, so old code kept running at the new name's price. It buys "up to 2.5× faster speeds and more consistent latency" for exactly 2x the tokens on the rate card, though the guide itself only says "a per-token premium" without naming the multiple. It does not support fine-tuned models or embeddings.
Two warnings on it. The first is that Fast mode compounds with the long-context surcharge: Sol on Fast in the long-context band is $20.00 input against $5.00 on standard short context, which is 4x, not 2x. The second is the failure mode I would actually check for tonight, because it is not hypothetical:
"When I was going through this it was because OpenAI had defaulted to /fast mode with 2x token usage"
That was someone diagnosing an unexplained burn-rate spike on the GPT-5.6 launch thread. Whether 2.5x speed is worth 2x cost is a real question with a real answer for your product. Paying it by accident on a background job is not a question at all.
Everything else that lands on the invoice
Tokens are not the whole bill. Tools, audio, images and video all carry their own meters, and this is where a "cheap" prototype quietly stops being cheap.
Tools
| Tool | Detail | Price |
|---|---|---|
| Web search | All models | $10.00 / 1k calls, plus content tokens at model rates |
| Web search preview | Non-reasoning models | $25.00 / 1k calls, content tokens free |
| File search | Tool call | $2.50 / 1k calls |
| File search | Storage | $0.10 / GB per day, 1 GB free |
| Containers | Hosted Shell and Code Interpreter | $0.03 to $1.92 per 20-min session, by memory size |
| AgentKit | ChatKit upload storage | $0.10 / GB-day after 1 GB free per month |
The wrinkle worth internalising: web search "content tokens" are the tokens pulled from the search index and fed to your model alongside your prompt, and they bill at your model's input rate. On Sol that means a search-heavy request can carry a token bill several times the size of the prompt you wrote. Container sessions bill by the minute with a 5-minute minimum, so a one-second code execution costs five minutes. File search tool-call pricing applies to the Responses API only. If you are building on that surface, our AgentKit writeup and the vector stores API reference cover the plumbing, and the Assistants API guide covers the older path.
Audio, realtime and transcription
| Model | Modality | Input | Cached input | Output |
|---|---|---|---|---|
gpt-realtime-2.1 | Audio | $32.00 | $0.40 | $64.00 |
gpt-realtime-2.1 | Text | $4.00 | $0.40 | $24.00 |
gpt-realtime-2.1-mini | Audio | $10.00 | $0.30 | $20.00 |
gpt-realtime-2.1-mini | Text | $0.60 | $0.06 | $2.40 |
Audio output at $64.00 per 1M tokens is the most expensive published rate on the entire card, more than double Sol's text output. The mini variant cuts it to $20.00, which is the single biggest saving available anywhere in the multimodal section. We went deeper on that tradeoff in GPT-realtime mini pricing, and the audio and speech API guide covers the non-realtime path.
Transcription is priced per minute rather than per token:
| Model | Use case | Cost per minute |
|---|---|---|
gpt-realtime-translate | Live translation | $0.034 |
gpt-live-transcribe | Live transcription | $0.017 |
gpt-realtime-whisper | Live transcription | $0.017 |
gpt-transcribe | Transcription | $0.0045 |
gpt-4o-transcribe | Transcription | $0.006 |
gpt-4o-mini-transcribe | Transcription | $0.003 |
Live transcription is 3.8x the per-minute cost of batch transcription. If your use case can tolerate a delay, that is a straightforward 74% cut.
Embeddings, priced in a unit nobody else uses
Embeddings are the one row where OpenAI does not publish a per-token rate at all. The embeddings guide gives you pages per dollar instead:
| Model | Pages per dollar | MTEB score | Max input |
|---|---|---|---|
text-embedding-3-small | 62,500 | 62.3% | 8,192 |
text-embedding-3-large | 9,615 | 64.6% | 8,192 |
That is 6.5x the cost per page for 2.3 points of retrieval benchmark. If you are embedding a help centre for a support bot, that tradeoff is worth measuring on your own corpus before you default to the large model, because retrieval quality in practice depends far more on how you chunk than on which of these two you picked. Our notes on building an AI knowledge base go into the chunking side.
Images and video
gpt-image-2 bills $8.00 per 1M image input tokens, $2.00 cached, and $30.00 output, with text input at $5.00. Note that cached input here is 25% of input rather than the 10% text models get. Batch halves all of it.
Per-image, the generation guide publishes the resolved costs, and there is a quirk worth pocketing:
| Quality | Square 1024x1024 | Portrait 1024x1536 | Landscape 1536x1024 |
|---|---|---|---|
| Low | $0.006 | $0.005 | $0.005 |
| High | $0.211 | $0.165 | $0.165 |
A high-quality square image costs 28% more than a high-quality landscape one, despite being fewer pixels, because the token grid does not map to area the way you would expect. Low to high on a square is a 35x jump. Streaming partial images adds 100 tokens each. Our image edit API notes cover the editing endpoints.
Video is per second, not per token:
| Model | Size | Standard | Batch |
|---|---|---|---|
sora-2 | 720p | $0.10 | $0.05 |
sora-2-pro | 720p | $0.30 | $0.15 |
sora-2-pro | 1024p | $0.50 | $0.25 |
sora-2-pro | 1080p | $0.70 | $0.35 |
A single minute of 1080p sora-2-pro is $42.00 on standard. Our Sora 2 breakdown covers what you get for it.
Usage tiers decide what you are allowed to spend
Before any of the above applies, there is a spend gate. OpenAI graduates your organisation through usage tiers based on cumulative payment, and each tier carries a monthly ceiling.
| Tier | Qualification | Monthly usage limit |
|---|---|---|
| Free | Allowed geography only | $100 / month |
| Tier 1 | $5 paid | $100 / month |
| Tier 2 | $50 paid | $500 / month |
| Tier 3 | $100 paid | $1,000 / month |
| Tier 4 | $250 paid | $5,000 / month |
| Tier 5 | $1,000 paid | $200,000 / month |
And the per-model rate limits move with it. For gpt-5.6-sol:
| Tier | RPM | TPM | Batch queue limit |
|---|---|---|---|
| Free | Not supported | Not supported | Not supported |
| Tier 1 | 500 | 500,000 | 1,500,000 |
| Tier 2 | 5,000 | 1,000,000 | 3,000,000 |
| Tier 3 | 5,000 | 2,000,000 | 100,000,000 |
| Tier 4 | 10,000 | 4,000,000 | 200,000,000 |
| Tier 5 | 15,000 | 40,000,000 | 15,000,000,000 |
Two things jump out. The flagship is not available on the free tier at all: Sol's Free-tier row reads "Not supported", so $5 of paid usage is the entry fee to call it. And the Tier 4 to Tier 5 step is 10x on TPM and 75x on the batch queue, off a $1,000 cumulative-spend gate, which makes Tier 5 the real production threshold rather than Tier 4.
Rate limits are set at the organisation and project level rather than per user, and some model families share a pool, so a noisy internal tool can throttle your production traffic. Vector store ingestion has its own cap of 300 requests per minute per store.
Two surcharges that sit outside every table
Data residency costs 10%. The note appears under all four service-tier tables: regional processing endpoints "are charged a 10% uplift for models released on or after March 5, 2026, that are eligible for data residency." If you are in a regulated vertical and assumed EU processing was free, it is not. The your data guide lists supported regions.
Bedrock is a different rate card. "OpenAI models in Amazon Bedrock are billed through AWS and may differ from direct OpenAI pricing." Bedrock also caps GPT-5.4 and GPT-5.5 at a 272,000-token context window rather than the direct API's larger one, so an architecture diagram that says "OpenAI via Bedrock" is not the pricing you read above.
And one deprecation with real cost consequences: fine-tuning is being wound down. OpenAI's own words on the pricing page are that "the platform is no longer accessible to new users, but existing users of the fine-tuning platform will be able to create training jobs for the coming months." The deprecations page dates it: new organisations were blocked on 7 May 2026, dormant ones on 2 July 2026, and all new training jobs end on 6 January 2027. One model remains on the card, o4-mini-2025-04-16, at $100.00 per hour of training, and enabling data sharing halves its inference rate.
If your cost model assumed you would fine-tune a small model down to a cheap per-token rate, that route has a closing date now. Prompt caching plus better retrieval is the substitute, which is a fine trade for most workloads and a real loss for the few that needed a specialised small model.
How OpenAI compares on price
Here is the honest picture, all standard-tier, all read off each vendor's own page this week.
| Model | Input | Cached read | Output | Long-context surcharge | Free tier |
|---|---|---|---|---|---|
gpt-5.6-sol | $5.00 | $0.50 | $30.00 | 2x in / 1.5x out over 272K | flagship not supported |
gpt-5.6-terra | $2.00 | $0.20 | $12.00 | same | yes |
gpt-5.6-luna | $0.20 | $0.02 | $1.20 | same | yes |
| Claude Opus 5 | $5.00 | $0.50 | $25.00 | none | no |
| Claude Sonnet 5 | $2.00 | $0.20 | $10.00 | none | no |
| Claude Haiku 4.5 | $1.00 | $0.10 | $5.00 | none | no |
| Gemini 3.7 Flash | $0.75 | $0.075 | $3.75 | none | yes |
| DeepSeek V4 Flash | $0.22 off-peak | $0.007 | $0.66 off-peak | none | no |
| Kimi K3 | $3.00 | $0.30 | $15.00 | none | no |
The comparison that matters most is Anthropic's, because it is a direct architectural disagreement rather than a rounding difference. At matched input prices, Anthropic is cheaper on output at both tiers, $25.00 against Sol's $30.00 and $10.00 against Terra's $12.00. And its docs make the long-context position explicit:
Claude 4.6 and later models and Claude Mythos Preview include the full 1M token context window at standard pricing. (A 900k-token request is billed at the same per-token rate as a 9k-token request.)
That is the whole disagreement in one sentence. If your workload lives in long prompts, that line is worth more than any per-token gap. If your workload lives in short prompts and you want the cheapest capable option, Gemini 3.7 Flash at $0.75 and $3.75 undercuts Luna on output while including a real free tier, though note that its promotional rate doubles to $1.50 and $7.50 on 1 January 2027. And if you are optimising purely for floor price, DeepSeek V4 Flash is an order of magnitude below everyone, with a peak-hours surcharge that doubles its rates between 01:00 and 10:00 UTC.
My take: if you are already on OpenAI and the bill is the problem, do not switch vendors first. Get every request under 272K, move anything that tolerates delay to Batch, audit for stray service_tier: "fast", and check your actual cache hit rate. Those four moves are usually worth more than a migration, and they take an afternoon.
Only after that is a vendor comparison worth your time, and our GPT-5.6 alternatives roundup compares the field properly. If what you are actually costing is a consumer seat rather than metered tokens, ChatGPT pricing is the equivalent breakdown.
Three worked examples
Abstract rates are hard to argue with and easy to misjudge, so here are three real workload shapes priced end to end. All assume a 50% cache hit rate on input unless stated.
A ticket classifier at volume. Luna, 4,000 input tokens per ticket, 300 output, 50,000 tickets a month, 60% cache hit. That is $36.40 a month on standard, $18.20 on Batch. Classification is the workload where token pricing really is cheap, and where a flagship model is money on fire.
A retrieval answer bot. Sol, 40,000 input tokens, 900 output, 30,000 requests a month. $4,110 on standard, $2,055 on Batch, $8,220 on Fast mode. The Batch-to-Fast spread here is $6,165 a month on identical output quality.
The same bot after a retrieval change. Sol, 300,000 input tokens, 900 output, 30,000 requests. $50,715 a month, because every request now bills in the long-context band. Nobody shipped a new model, nobody changed the tier, and the bill went up 12x. This is the shape of almost every surprise invoice I have looked at.
The third case is why I keep saying the model row is not the story. And it is also why, for a support queue specifically, I think token pricing is often the wrong abstraction to be reasoning in at all.
Where token pricing stops being the right question
Everything above is a fair description of what you pay a model provider. It is a poor description of what a support ticket costs you.
A resolved ticket is not one API call. It is a retrieval pass, a plan, two or three tool calls against your helpdesk, a drafted reply, sometimes a second pass after a follow-up. Each of those is its own token bill, each has its own cache behaviour, and the total varies by an order of magnitude between a "where is my order" and a refund dispute. You can model that. Teams do. But you are now maintaining a cost model as a product surface, and it will drift every time you change a prompt.
And the tail risk is not theoretical. This is the single most on-the-nose thing I read while researching this post, from r/SaaS:
"Hey everyone, I just got hit with a $4,200 OpenAI bill because an agent I deployed for customer support got stuck in a recursive loop with my CRM tool call."
A support agent, a tool call against a CRM, a loop, and a bill with no ceiling on it. Every one of those four things is normal. That is the shape of the risk you take on when your billing unit is a token and your work unit is a ticket.
It also explains why an API bill looks nothing like the subscription you tested with. Simon Willison put the gap in numbers on the Anthropic funding thread:
"I spent $200/month on subscriptions last month ($100 each to Anthropic and OpenAI) and the API cost version of my token spend was $2,100"
That is a 10.5x gap for identical usage. If you prototyped on a Plus plan and budgeted from that experience, the metered version is the number to plan against.
I saw the same forecasting problem from the other side with a very-high-volume operator we talked to, scaling toward 150,000 tickets a month, who found the per-interaction versus per-ticket distinction confusing enough mid-call that he projected about $30,000 a month for himself and stopped there. The confusion was the problem, not the number. When your unit of billing does not match your unit of work, you cannot forecast, and if you cannot forecast you cannot commit.
I picked the other side of that tradeoff deliberately. How the per-ticket economics compare against building it yourself is a whole post of its own, and we wrote it up in AI customer support cost savings.
If you are earlier than that and still sizing the category rather than the bill, our AI ticketing system guide is the better starting point.
Try eesel
If what you are actually pricing is AI on a support queue, eesel bills per ticket, not per token. $0.40 per ticket or helpdesk conversation handled, whatever happens inside it, with $50 of free usage to start, no platform fee, no per-seat charge and no minimum. A thousand tickets a month is $400, and it stays $400 whether the agent needed one model call or nine.
Two things I would want to know if I were reading this as a buyer. First, you can route a fraction of your queue and pay only for that fraction, so the rollout is not all-or-nothing. Second, we simulate against your historical tickets before anything goes live, because we have watched confident-sounding bots give wrong answers and would rather find that in a dry run than in production. The reports view counts tasks, which is the same unit the invoice counts, so the forecast and the bill are the same number.
Where it is not the right fit: if you are building a general-purpose product on top of a model rather than automating a support queue, you want the raw API and the arithmetic above, not us. Per-ticket pricing only makes sense when the ticket is the unit.
Setup takes a few minutes against whatever you already run, and it reads your existing help centre without a migration. The full integration list covers Zendesk, Freshdesk, Gorgias and the rest.
Before you commit either way, price it against what your own helpdesk already charges for its native AI. We costed that in Zendesk pricing, and the numbers are usually closer than people expect.
Try eesel free if the arithmetic in this post looked like your problem. If security review is the real gate, read the security posture first.
Frequently Asked Questions
How much does the OpenAI API cost per 1M tokens in 2026?
What is the cheapest way to use the OpenAI API?
Is there a free tier for the OpenAI API?
gpt-5.6-sol lists its Free-tier rate limit as "Not supported", so you need at least $5 of paid usage to reach Tier 1 and call it. Gemini's pricing does include a genuine free tier for its current Flash model, which is a real difference if you are only prototyping.Why is my OpenAI API bill higher than the pricing page suggested?
reasoning_effort is producing far more output tokens than you counted. Tool calls also bill separately on top of tokens. Our guide to OpenAI rate limits covers the related throughput caps.How does OpenAI API pricing compare to Claude and Gemini?
What does OpenAI charge for tools like web search and file search?
How much does AI customer support cost if I do not want to manage tokens?
Article by
Rama Adi Nugraha
Rama is a software engineer at eesel AI with two years of experience writing about B2B SaaS, AI tools, and customer support technology. Based in Bali, Indonesia, he brings a developer's perspective to product comparisons — cutting through marketing copy to what the integrations and APIs actually do.
