When people hear "one million token context window" the first thing they imagine is dropping their entire codebase into a prompt and asking Claude to refactor it. The second thing they imagine, usually about three seconds later, is a horrifying bill.
Both reactions are roughly correct, and roughly wrong, depending on what you actually do with it.
I have been running Claude Opus as my primary coding model for nine months. I have used the 1M context window heavily, deliberately, and sometimes by accident. I pay these bills myself, not through an employer with a budget. Here is what 1M context actually costs, where the hidden charges live, what I do to bring the bills down, and when I stop caring about the cost entirely because the value is obvious.
This is the working version. Not the pricing page version, the real one.
the headline numbers ..
Opus 4.6 and Opus 4.7 both ship at the same headline rates: $5 per million input tokens, $25 per million output tokens. The 1M context window is included at that rate, no premium tier, no surcharge for going long. This was confirmed when Anthropic moved 1M to general availability in March 2026 and dropped the earlier long context premium.
So a single one million token input request to Opus is, mechanically, $5 plus whatever the output costs. If the model writes you 5,000 tokens back, that is $5.125 for the call. Not catastrophic.
Now the part where the simple math falls apart.
If you do that exact call a hundred times in a day,, say youre using it as the back end of an internal docs tool, you are looking at $500 a day in input cost alone, $15,000 a month at that pace. Some of the louder cost case studies in 2026 quote $27,000 a month for shops doing roughly that volume on raw, uncached, full window calls. Those numbers are real. They are also almost entirely avoidable, which is the actually useful thing nobody tells you.
the four hidden costs that bite ..
There are four things that inflate Opus bills beyond what the pricing page suggests. I have hit all four.
The first is the tokenizer change. Opus 4.7 uses a new tokenizer that for many inputs produces 1.0 to 1.35 times as many tokens for the exact same text. Code with lots of symbols, multilingual content, and long technical strings get hit hardest. So if you ran a workflow on Opus 4.6 last quarter and you switched to 4.7 expecting the same bill, your bill is silently 15 to 30 percent higher because each request packs more billable tokens. The per token rate did not change. The tokens per request did.
The second is the invisible thinking tax. Opus models do internal reasoning that you do not see in the visible output but that does get billed. Independent measurements in 2026 have shown this overhead runs around 15 to 17 percent above what you would estimate from visible output alone. So if you assume "Claude wrote me 5,000 tokens of code, ill pay for 5,000 output tokens" you are short by about 800. It is not huge per call. It adds up across a month.
The third is tool definitions and system prompts. Every time Claude Code invokes a tool, the tool definition is in the prompt. Every MCP server you have configured contributes its tool schemas to the system prompt. If you have ten MCP servers connected, each with twenty tools, that is a substantial chunk of every input token count you never explicitly wrote. Web search and similar add ons may also bill per call on top of the token cost. This is the cost most people forget exists.
The fourth, and the most surprising one, is cache writes. We will get to caching in detail in a moment, but the headline is this: cache reads are cheap (0.1x the input rate, so $0.50 per million tokens read from cache) but cache writes are expensive (community measurements put them around $6.25 per million tokens written, which is 1.25 times the regular input rate). So the first time you populate a cache, you pay a premium. If you then do not reuse that cache much, you have just spent more than you would have without caching at all.
real receipts from my own setup ..
Here are actual numbers from my own workflow, not invented examples.
A heavy debugging session on Throughline last month. 170 conversation turns over about four hours, all on Opus 4.6, working on a complex video diff feature where the model needed to see the same six source files repeatedly. With prompt caching enabled, that session billed $20.97. The same session pattern measured without cache would have been around $168, an 88 percent saving. The cache hit rate on that session was 99.6 percent, which is what made the math work. The model was rereading mostly the same prefix every turn, which is exactly the workload caching was designed for.
A normal day of using Claude Code across three projects, no particularly long contexts, maybe 60 to 80 turns total. That runs me roughly $6 to $9 in a working day with caching on, somewhere between $25 and $40 without. So the cache is paying for itself by a factor of about 4 in normal use, and by a factor of 8 in heavy single project sessions.
A "full codebase as context" experiment I ran in March. Loaded all of Throughline (about 180,000 tokens of source) into a single prompt, asked Opus 4.7 to find architecture inconsistencies. One shot, no caching applicable because it was a one off, single output of about 3,000 tokens. Total: $1.97. Useful output: maybe $30 worth of senior engineer time saved. Easy decision.
A "1M context just to see what happens" experiment I ran the same week. Loaded a huge mixed bag of source files, design docs, transcripts, and prior chat history into a single one million token prompt. Asked Opus 4.7 to summarize what i was working on across all of it. Total cost: $6.40. Quality of output: noticeably degraded compared to the focused 180k version. Useful for very little. Not a great use of money, but informative.
So my own pattern across nine months: i routinely spend $4 to $10 a day on Claude Code, occasionally $15 to $20 on a heavy build day. The biggest single bill i have had was $32 in one day, building a complex feature where i was unwilling to wait for batch turnaround. The 1M window is in my plan but i hit it maybe twice a month at full extent. Most days i operate in the 50k to 200k range and never think about cost.
when 1M context is actually worth the money ..
The honest filter: 1M context is worth it when the alternative is worse. That sounds tautological but the alternative most people forget is "break the task up and run smaller calls". For about 80 percent of what people throw at long contexts, that is the better option.
Where 1M genuinely earns its place:
- A single logical operation that requires more than 200k tokens of unique context that cannot be broken into retrievable chunks. Reading an entire codebase to find a non local inconsistency is the canonical example. RAG cant do this because you dont know what to retrieve.
- Long horizon agent loops where the state would have to be re injected every turn anyway. Putting the state once at the top, caching it, and letting the agent operate on top of it for 50 turns is cheaper than re injecting per turn.
- Working with media that does not chunk well, long meeting transcripts being the obvious one. You can break them up but you lose the through line and the model gets confused about whos saying what.
Where 1M is a waste:
- Document analysis where retrieval works fine. Throw it in a vector DB, retrieve 8k of relevant chunks, run a smaller model. Cost difference is roughly 50x in your favor.
- Codebase questions where the relevant code is a known directory. Stop loading the whole repo. Load the directory.
- Anything you can do with Sonnet at 200k. Sonnet is cheaper and faster and for many tasks just as good.
There is also the quality degradation question. Multiple bench analyses in 2026 have shown that for many models, effective performance starts to degrade past about 200k tokens of context even though the window technically holds more. Opus is among the better performers at long context but it is not magic. So beyond a certain point you are paying more money for slightly worse output.
the caching playbook in two paragraphs ..
If you do nothing else with cost optimization, do this. Identify the parts of your prompts that repeat. The system prompt, the long file you reference every turn, the project context, the conversation history up to whatever turn you are on. Mark those for caching. The first call will cost a little extra because of the write. Every subsequent call will cost 90 percent less on that cached portion. The cache stays warm for five minutes between calls.
The trap is that you have to actually call it again within those five minutes for the cache to be useful. If you cache something and then go to lunch,, the cache evaporates and you paid the write cost for nothing. So caching is mainly valuable in active conversations, agent loops, and tools where you know calls will be frequent. Its not a cost optimization for "i ask Claude something once a day". For that, the cache costs you money instead of saving it.
Add the batch API on top when latency does not matter. That is a 50 percent discount on both input and output, and it works for any workload where "tonight" works instead of "now". I use it for end of week reports, sitemap generation, and any "process this folder of stuff" task.
the simple version ..
If you forget everything in this post, remember three things.
1M context is included at the regular rate. The window is not the cost driver. Volume and reuse patterns are.
The biggest unforced cost mistakes are not paying attention to tokenizer changes, leaving MCP servers connected you do not use, and writing caches you never read back from.
For most things you would reach for 1M for, smaller chunked calls with a good retrieval setup will cost a third as much and produce comparable output. Reach for 1M when the task genuinely cannot be decomposed. Then enjoy it without guilt, because the receipts say it is fine.
I have been doing this for nine months. The bills are reasonable. The output has shipped four products that earn revenue. The maths works.
The pricing page is honest. The pricing reality is more interesting.