Claude vs ChatGPT API: Which Is Cheaper?
Neither API wins every workload. Learn the token arithmetic once, then read three costed jobs and see exactly where the Claude bill runs higher.
The short answer
Claude vs ChatGPT API pricing has no single winner, because the two vendors price input and output differently at every tier. As of August 2026 the upper two Claude tiers charge the same per input token as their OpenAI counterparts and less per output token, so Claude comes out slightly ahead on output-heavy work. At the small tier Claude costs several times more for the same job. Any answer that does not name a tier and a token mix is a guess.
So this page gives you the arithmetic first, then three costed workloads with their token mixes, then the multipliers that move a real bill further than the headline rate does.
The only formula you need
Both APIs bill text the same way. You pay for the tokens you send, and you pay a higher rate for the tokens the model writes back.
cost = (input tokens / 1,000,000) * input rate + (output tokens / 1,000,000) * output rate
A token is about 4 characters of English, near 0.75 of a word. Use that for a first estimate only. For a real bill you use the counts each API returns in the usage object of every response.
# Rates are US dollars per million tokens.
def cost(in_tok, out_tok, in_rate, out_rate):
return in_tok / 1e6 * in_rate + out_tok / 1e6 * out_rate
# One support-chat turn: 1,400 tokens in, 220 tokens out, on a $2 / $10 model.
print(round(cost(1400, 220, 2.0, 10.0), 6))The script prints 0.005, which is half a cent per turn. Multiply by the number of turns you expect in a month and you have a budget. Learn this one formula and every price change after today becomes a one-line edit instead of a new analysis.
The published rates, August 2026
These are the list prices both vendors published on 1 August 2026. This block is the only place in the post where a price is written down. Check it against claude.com/pricing and OpenAI's pricing page before you commit a budget.
The data behind this chart
[
{
"label": "Frontier",
"claude_input": 5,
"claude_output": 25,
"openai_input": 5,
"openai_output": 30
},
{
"label": "Workhorse",
"claude_input": 2,
"claude_output": 10,
"openai_input": 2,
"openai_output": 12
},
{
"label": "Workhorse from September",
"claude_input": 3,
"claude_output": 15,
"openai_input": 2,
"openai_output": 12
},
{
"label": "Small",
"claude_input": 1,
"claude_output": 5,
"openai_input": 0.2,
"openai_output": 1.2
}
]The pairings are by position in each lineup, not by fame. Frontier is Claude Opus 5 against gpt-5.6-sol. Workhorse is Claude Sonnet 5 against gpt-5.6-terra. Small is Claude Haiku 4.5 against gpt-5.6-luna. Both vendors also sell higher tiers above this block, and OpenAI keeps older generations listed at their original rates. Comparing a flagship on one side to a budget model on the other produces a number that means nothing, which is how most published comparisons get their headline.
Two things in that block need saying out loud. Sonnet 5's 2 and 10 are introductory rates, and Anthropic documents them as ending on 31 August 2026, after which Sonnet 5 charges 3 and 15. That one change turns the workhorse tier from a narrow Claude win into a clear OpenAI win, and it lands inside this post's shelf life.
The second thing is a pattern worth memorising: Claude prices output at exactly 5 times its own input rate on every row above, and OpenAI prices output at 6 times. That ratio, not the absolute rate, is what makes the winner change with your token mix.
Why a rate per million tokens does not compare across vendors
A rate is dollars per token. A bill is dollars per token multiplied by tokens, and the token count for a piece of text is a property of the model, not of the text.
Anthropic documents this directly: Claude 4.7 and later models, which includes Claude Opus 5 and Claude Sonnet 5, use a newer tokenizer that produces roughly 30% more tokens for the same text than Claude Sonnet 4.6 and earlier. The rate did not move. The bill did.
So two rates that look identical are not two identical bills. Count tokens on both sides, with your own text, before you trust any comparison including this one.
curl https://api.anthropic.com/v1/messages/count_tokens \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5",
"messages": [{"role": "user", "content": "Summarise the attached contract."}]
}'A healthy response is a small JSON object holding input_tokens. A 401 means the key variable is empty in your shell. Run the same text through the other vendor's tokenizer, divide one count by the other, then multiply that ratio into the published rate before you compare. If the ratio favours one vendor by more than about 1.2, it outweighs every rate difference in the block above.
Scenario one: a chat feature
A support assistant inside a web application. 120,000 turns a month. Each turn sends a system prompt, tool schemas, two retrieved help-desk snippets and a few earlier messages, about 1,400 input tokens, and the model answers in about 220 tokens. It is interactive, so the batch discount can never apply here. Run it on the workhorse tier.
The data behind this chart
[
{
"label": "List price",
"claude_usd": "600.00",
"openai_usd": "652.80"
},
{
"label": "Cached prefix",
"claude_usd": "427.20",
"openai_usd": "480.00"
},
{
"label": "Small tier, cached",
"claude_usd": "213.60",
"openai_usd": "48.00"
}
]At list price Claude bills 600.00 against OpenAI's 652.80. The input legs are identical, because the input rates are identical. The entire gap is output, and Claude wins it by a margin too small to pick a vendor on.
Now mark 800 of those 1,400 input tokens as a stable prefix: the system prompt and the tool schemas, which do not change between turns. Both vendors charge 10% of their base input rate for a cache hit. Claude's bill drops to 427.20 and OpenAI's to 480.00. Caching is worth more than the vendor choice, and both platforms offer it.
Here is where Claude loses. Most support answers do not need a workhorse model. Move the same traffic to the small tier and Claude bills 213.60 while OpenAI bills 48.00. Divide one by the other and Claude costs about four and a half times as much for the same job. Claude Haiku 4.5 charges 1 per million input tokens against gpt-5.6-luna at 0.2, and no amount of caching closes a fivefold gap. If your workload fits a small model, OpenAI is cheaper and the margin is large.
Scenario two: a long-context document pipeline
25,000 contracts a month. Every request carries the same 9,000-token instruction and JSON schema, then 12,000 tokens of contract text, and the model returns about 700 tokens of structured fields. Output is under 4% of the tokens in this job, and that single fact decides the comparison.
The data behind this chart
[
{
"label": "Chat feature",
"claude_usd": "427.20",
"openai_usd": "480.00"
},
{
"label": "Document pipeline",
"claude_usd": "820.00",
"openai_usd": "855.00"
},
{
"label": "Coding agent",
"claude_usd": "116.10",
"openai_usd": "124.20"
}
]With the 9,000-token prefix cached on both sides, Claude bills 820.00 and OpenAI bills 855.00. The input legs match to the cent, because the workhorse input rates match in August 2026. The whole difference is the output leg, priced at 5 times input on Claude and 6 times on OpenAI.
This job also batches. Both vendors take 50% off input and output for asynchronous work, so both totals halve and the gap keeps its shape. Batch is the largest single discount on either platform, and a nightly document pipeline can always use it.
Where Claude loses is the same tier logic as before. Field extraction against a fixed schema is exactly the work a small model does well, and input is 97% of the tokens here. Moving down one tier multiplies the OpenAI input rate by 0.1 and the Claude input rate by 0.5. Test the small model on 200 documents before you assume you need the bigger one, using the same evaluation you would run for picking the right Claude tier for a job.
Scenario three: an always-on coding agent
One developer running an agent on a VPS, roughly 900 model turns a month. Each turn carries about 60,000 input tokens of repository context, of which 80% is a cache hit, and produces about 1,800 tokens of edits and explanation. Price it on the frontier tier, because coding is where a capability gap costs real money.
Claude bills 116.10 against OpenAI's 124.20. Same input rate, same cache read rate, and Claude's lower output rate wins by about 7%.
That 7% sits inside the tokenizer error bar from earlier, so treat this scenario as a tie on rates. What is not a tie is the billing model. For one developer at this volume a subscription seat usually costs less than metered API calls, and the whole comparison changes once you include one. Work that through with the API against subscription cost comparison before you put an agent on metered billing. If you do meter it, learn where the tokens go first, because a coding agent's token usage is dominated by context re-sent on every turn rather than by the code it writes.
The multipliers that decide the bill
The headline rate is the smallest item on this list. Each one below moves a real bill by more than the difference between the two vendors at the same tier.
Cached input. Both vendors charge 10% of base input for a cache hit. Anthropic also charges to write the cache: 1.25 times base input for a five-minute entry and 2 times for a one-hour entry, and a later hit refreshes that entry at the read price. So a five-minute entry pays for itself after one read. A workload with long gaps between requests writes more often than it reads, and there caching costs more than it saves. Steady traffic caches well. Bursty traffic does not.
Batch discounts. 50% off input and output on both platforms, for asynchronous work only. If the job can wait, this halves the bill on either vendor, and it stacks with caching.
Output share. Claude charges 5 times its input rate for output. OpenAI charges 6 times. The more of your tokens are written rather than read, the better Claude looks at an equal input rate, and the reverse holds for input-dominated work.
Retries. A retry pays for the whole input again and returns nothing usable. If 6% of your calls fail schema validation and get retried, your input leg is 6% larger than your plan says. Log retries as a cost line, not as an error line. Teams find this multiplier last, and it is often bigger than the vendor gap they spent a week arguing about.
Which side loses, and where
Claude loses the small tier outright. gpt-5.6-luna charges 0.2 per million input tokens against Claude Haiku 4.5 at 1, with output at 1.2 against 5. High-volume classification and short extraction cost roughly four times more on Claude.
Claude loses the workhorse tier from 1 September 2026, when the introductory rate ends and Sonnet 5 moves to 3 and 15 against an unchanged gpt-5.6-terra. Claude wins the frontier tier on output rate, by a margin your own token counts can erase. Neither side wins input-dominated work in August 2026, because at 2 per million on both sides the input legs are the same number.
How to measure this on your own traffic
Read the usage object on every response and store four numbers per request: input tokens, output tokens, cache read tokens and cache write tokens. On the Claude API those arrive as input_tokens, output_tokens, cache_read_input_tokens and cache_creation_input_tokens. Sum them per day, multiply by the current rates, and compare your total to the invoice. A gap between the two is usually retries or a code path you forgot you shipped.
Run the comparison on one week of real traffic rather than on a sample prompt, and compare cost per completed task instead of cost per token. A model that answers in one attempt at twice the rate is cheaper than a model that needs three attempts at half. Cost per token is a rate. Cost per completed task is your bill.
Set a hard spend ceiling before you leave anything running. Both platforms expose spend limits in their consoles, and an agent stuck in a retry loop can spend a month of budget overnight. Wire that up the way you would for cost control on an always-on agent. If you are building the first version on a server you own, a first Claude API app on a VPS covers the key handling and the request loop this arithmetic sits on top of.
FAQ
Is the Claude API cheaper than the ChatGPT API?
Not consistently. In August 2026 the frontier and workhorse tiers charge the same per input token on both sides, and Claude charges less per output token, so Claude runs a few percent cheaper on output-heavy work. At the small tier OpenAI's gpt-5.6-luna costs one fifth of Claude Haiku 4.5 per input token, so high-volume classification is far cheaper on OpenAI. Compute your own figure from your own token mix, because a margin that small is decided by your workload rather than by the price list.
Why do the same words cost a different number of tokens on each API?
Because every model has its own tokenizer, and the token count is a property of the model. Anthropic documents that Claude 4.7 and later models produce about 30% more tokens for the same text than Claude Sonnet 4.6 and earlier. Send your own text to each vendor's token counting endpoint, divide one count by the other, then multiply that ratio into the published rate before you compare. A 20% token difference outweighs most published rate differences.
Does prompt caching ever make the bill bigger?
Yes, on Anthropic. A cache write costs 1.25 times the base input rate for a five-minute entry and 2 times for a one-hour entry, while a hit costs 0.1 times. If your traffic is bursty enough that most entries expire before anything reads them, you pay the write premium and collect no reads. Compare cache_creation_input_tokens against cache_read_input_tokens in your logs. A ratio near 1 means caching is costing you money, so lengthen the entry or drop it.
Should I run a coding agent on the API or on a subscription?
For one developer at ordinary volume a subscription seat usually costs less than metered API billing, because a coding agent re-sends a large context on every turn and that context is charged each time. Meter it for a week first, then compare the API total against the seat price. The API wins when usage is spiky, or when you need programmatic access that a seat does not give you.