LLM Cost Optimization &Token Economics in 2026

This article is written for whoever owns the budget line. That person keeps being handed cost models built from numbers that were true eighteen months ago, and the gap between those numbers and today is not a rounding error — it is frequently a factor of three or more, in both directions.

So the first rule of this whole discipline: never write a model price from memory. Provider pricing moves monthly. Everything below was taken from official pricing pages and is stated as of August 2026. Before any of it enters a spreadsheet that survives a quarter, re-verify it against the source.

Anthropic first. All figures USD per million tokens, from the official pricing page, as of August 2026.

Anthropic Claude pricing, USD per million tokens, as of August 2026. Retired on first-party API and available only through Bedrock and Google Cloud: Opus 4.1 and Opus 4 at $15/$75, Haiku 3.5 at $0.80/$4, Sonnet 4 at $3/$15.

Note the Sonnet 5 row, because it has a date attached. Introductory pricing of $2 / $10 runs through August 31, 2026, then moves to $3 / $15. That is a 50% increase on a known date. Any Sonnet 5 budget written this month against the intro rate is wrong from September 1, and it is the kind of thing that shows up as an unexplained variance in a Q4 review.

OpenAI next, from the published pricing page. The GPT-5.6 family carries a 1.05M-token context window with 128K maximum output, and a knowledge cutoff of February 16, 2026. Batch is roughly 50% off; prompt caching is roughly 10% of standard input, which is the same order as Anthropic's 0.1× cache read.

OpenAI API pricing, USD per million tokens, as of August 2026. One planning note for a different article: OpenAI is winding down its fine-tuning platform and it is closed to new users.

Google Gemini, from the Gemini API pricing page. Google runs four service tiers — Standard, Batch at 50% off, Flex at the same rate as Batch, and Priority at roughly 1.8× standard. The Pro rows are the ones that change architecture, and the next section is about why.

Google Gemini pricing, USD per million tokens, as of August 2026. Gemini context-window token limits were not verified against Google's documentation for this article, so they are omitted rather than guessed — the 200,000-token pricing threshold is the number that actually moves the bill.

Finally the open-weight and low-cost end, where the spread is widest and the numbers are least stable.

Open-weight and low-cost model pricing, USD per million tokens, as of August 2026. First-party Qwen pricing was not verified; model IDs are confirmed on Alibaba Cloud but the rates were not obtainable.

One structural observation before moving on. DeepSeek V4 Pro costs $0.435 per million input tokens first-party and $1.74 on Together AI — the same weights, roughly 4× apart. That gap is the cost of hosting, and it is a useful reminder that "open weights" is a licensing property, not a price. Self-hosting moves the cost from a per-token line to a fixed capacity line; it does not remove it.

This is the most under-discussed pricing fact in the industry right now, and it quietly determines which designs are affordable on which provider.

Anthropic charges no long-context premium. Claude 4.6 and later include the full one-million-token window at standard rates. A 900,000-token request is billed at the same per-token rate as a 9,000-token request, and caching and batch discounts apply across the whole window.

Google charges one. Gemini Pro models double the input price above 200,000 tokens, and double output too. Gemini 3.1 Pro in preview goes from $2.00 to $4.00 on input and $12.00 to $18.00 on output at that threshold. Gemini 2.5 Pro goes from $1.25 to $2.50 and $10.00 to $15.00.

OpenAI is unresolved and should not be asserted either way.The GPT-5.6 models page states no long-context threshold, while the pricing page carries a generic note that extended context doubles pricing on select models. Which models those are could not be determined for this article. If you are running long-context workloads on OpenAI, the correct move is to check your own invoice against your own token distribution rather than trusting anyone's summary, including this one.

There is also a quality argument that runs alongside the cost argument and points the same way. Anthropic's context engineering guidance describes context rot — accuracy degrading as context grows, well before the window is full — and frames the window as an attention budget rather than a storage budget. Filling a million-token window because it is priced flat is a cost decision that can cost you accuracy. The discipline the same guidance recommends is the smallest set of high-signal tokens that gets the outcome, which happens to be the cheapest option as well.

Price the context strategy before you build it. On a provider with no long-context premium, a stuffed window is a quality risk. On a provider that doubles input above 200k tokens, it is a quality risk with a 2× multiplier attached.

— Frenchy Digital architecture principle

If you read one section of this article, read this one. Prompt caching is the highest ratio of savings to engineering effort available in 2026, and it is also where the most expensive silent failure lives.

The mechanics are exact and worth memorizing. Writing to the cache costs 1.25× base input for the five-minute TTL and 2× base input for the one-hour TTL. Reading from it costs 0.1× base input. You get a maximum of four cache breakpoints per request.

Anthropic prompt-caching multipliers and break-even points, as of August 2026. The fourth column instantiates them at the Opus tier's $5/MTok input price.

The break-evens fall out of the arithmetic cleanly. For the five-minute TTL: two uncached requests cost 2.0× the prefix; a write plus one read costs 1.25× + 0.1× = 1.35×. So one read pays for the write. For the one-hour TTL: two uncached requests cost 2.0× and a write plus one read costs 2.0× + 0.1× = 2.1×, which is still behind. Three uncached requests cost 3.0× and a write plus two reads costs 2.2×, which is ahead. So two reads pay for the one-hour write.

Now the case that gets skipped. A cache write with zero reads costs 1.25× — you paid 25% more than if you had never enabled caching. That is exactly what happens to a sparse workload: if your requests arrive more than five minutes apart, every single one is a write and none of them is ever a read. Caching on a low-traffic endpoint is a cost increase disguised as an optimization.

And then the trap that catches the most teams, because it produces no error and no log line.

Minimum cacheable prefix by model, as of August 2026. The practical consequence: a prefix that caches correctly on Opus 5 can stop caching entirely when the same workload is routed to Haiku 4.5 to save money.

The detection method is simple and almost nobody does it: log the cache-read and cache-write token counts from the API response on every request, and alert when the cache-read count is zero on a path that is supposed to be cached. Latency will not tell you — a cache miss on a 3,000-token prefix is not noticeably slower. Only the token accounting will.

Two more caching rules worth stating. First, order the prompt so the stable content comes first: cached prefixes are prefixes, so a single changing token near the top invalidates everything after it. Tool definitions and system instructions go at the front; the user turn goes at the back. Second, four breakpoints is the ceiling, which in practice means you get about four tiers of stability — system, tools, retrieved corpus, conversation — and you should assign them deliberately rather than letting a framework place them for you.

Then stack the batch discount on top. The Batch API is 50% off both input and output, and it stacks with caching. Anything that does not have a human waiting on it — evaluation runs, backfills, document enrichment, classification sweeps, nightly reporting — should be running through batch. This is usually a pipeline-shape change rather than a code change, and it is the second-cheapest 50% anyone will ever offer you.

Long-running agents accumulate context. Every tool call appends a result, every thinking block appends tokens, and by turn forty the input is dominated by material that is no longer load-bearing. Two mechanisms address this, and they interact with caching in a way that determines whether either one saves money.

Context editing, available behind the beta header context-management-2025-06-27, clears stale tool results and thinking blocks out of the context window. Anthropic's documented example takes a request from 70,000 input tokens down to 25,000 — a 64% reduction. On the Opus tier at $5/MTok that is $0.35 to $0.125 per request, and on a long agent loop it repeats every turn.

Compaction is the other mechanism, and Anthropic recommends it as the primary strategy rather than context editing. Compaction summarizes the conversation so far and continues from the summary. Their broader context engineering guidance describes what a good compaction preserves: architectural decisions and unresolved bugs survive, while superseded tool output and resolved detail does not. It also recommends structured note-taking to external files as durable memory across resets, just-in-time retrieval over preloading, and sub-agent isolation where a subagent holds detailed search context privately and returns a condensed summary of roughly 1,000 to 2,000 tokens to the lead.

Read that last pattern as a cost mechanism as well as a quality one. A subagent that searches across fifty documents and returns 1,500 tokens has kept 48,500 tokens out of the lead agent's context — which is out of every subsequent turn's input, not just this one. In a long loop, the saving compounds.

The sequencing we recommend: compaction first because it is the primary recommendation and it plays well with caching (a compacted history becomes a new stable prefix), context editing second and tuned with clear_at_least, sub-agent isolation third where the work genuinely parallelizes. Then measure. Every one of these is a token-accounting change, and every one of them should be visible in your cache-read and input-token metrics within a day.

This section covers the most concrete and least-covered cost mechanics in production right now. All four traps share a property that makes them dangerous: they add spend to code that did not change.

Start with the fact everything else hangs off. Reasoning tokens bill as output tokens on both OpenAI and Anthropic.That is the expensive side of the ledger. On a model with a 5× spread between input and output — the Opus tier at $5/$25, gpt-5.6-terra at $2/$12 — a token spent thinking costs five or six times what the same token costs sitting in the context window. Any mental model that treats reasoning as "a bit more compute" is off by most of an order of magnitude.

Reasoning-token cost traps as of August 2026, with the mechanism and the fix for each.

The OpenAI one deserves restating because of how quietly it compounds. GPT-5.6 defaults reasoning.context to all_turns, where earlier models defaulted to current_turn. Earlier turns' reasoning is rendered into every subsequent request. In a five-turn conversation that is a modest increase. In a forty-turn agent session it is not, and the growth is superlinear in a way that a per-session cost average will not show you. OpenAI exposes the number in output_tokens_details.reasoning_tokens; read it per turn. Their effort levels run none, minimal, low, medium, high, xhigh, max, defaulting to medium, and their guidance is to reserve at least 25,000 tokens for reasoning plus output.

The Anthropic one is a migration hazard specifically. On Claude Opus 5, omitting the thinking parameter now runs adaptive thinking. The identical request on Opus 4.8 and Opus 4.7 ran with no thinking at all. So code that was written against 4.7, tested against 4.7, and had its budget modelled against 4.7 gains thinking spend the moment the model ID changes — and because max_tokens is a single cap covering thinking plus response text, an unchanged max_tokens can now truncate the visible answer mid-sentence. The failure presents as a quality regression and bills as a cost regression. Set thinking explicitly on every path after a migration, and raise max_tokens to cover both.

One more, smaller: on Anthropic models the effort control does not reliably shorten visible output. If you lowered effort expecting a smaller output bill, verify with output-token counts rather than assuming. Effort is a reasoning-depth control, not a length control.

Here is the part where most articles produce a confident number. This one will not, because the evidence does not support one, and saying so is more useful than the alternative.

With that framing, the numbers. Anthropic's multi-agent research system write-up states that agents typically use about 4× more tokens than chat interactions, and multi-agent systems about 15× more tokens than chats. The same post reports that on BrowseComp, token usage alone explained 80% of performance variance — which is the most important sentence in the piece for a budget owner, because it says the thing you are buying is, to first order, tokens.

Published agent token multipliers and worked examples, as of August 2026. All rows are vendor-published; treat the multipliers as directional.

The Opus 5 coding-session example is worth checking by hand, because it demonstrates the caching lever on real numbers. 50,000 input tokens at $5/MTok is $0.25; 15,000 output tokens at $25/MTok is $0.375; session runtime at $0.08 per session-hour brings the total to $0.705. Now serve 40,000 of that input as cache reads: 10,000 fresh input at $5/MTok is $0.05, 40,000 cache reads at $0.50/MTok is $0.02, output is unchanged at $0.375, runtime is $0.08 — total $0.525. A 26% cut from one change, and note where the remaining cost sits: output is now 71% of the bill.

That last observation generalizes. Once caching is working, most agent workloads become output-dominated, and at that point the levers change. Caching more input stops mattering. What matters is how much the model generates — which puts reasoning configuration, retry policy and model choice back at the top of the list, and makes the reasoning-token section above a cost-control section rather than a curiosity.

For context on how much of this is actually happening at scale: McKinsey's 2026 State of AI found only about 23% of organizations scaling an agentic system anywhere, with a ceiling of around 10% in any single function, and roughly 5.5% reporting more than 5% of EBIT attributable to AI. Stanford's AI Index 2026 reports 88% of organizations using AI in at least one function but fewer than 10% having fully scaled it in any single one, and only 29% reporting significant ROI. Those are adoption and return figures, not cost figures — the AI Index publishes no inference-cost numbers and should not be cited for them.

Every one of these is documented, every one is small individually, and collectively they are the reason a carefully modelled forecast comes in 20% high. They also share a failure mode: each is switched on for a reason that made sense at the time, by someone who was not the person who later has to explain the invoice.

Anthropic platform surcharges and server-tool costs, as of August 2026.

Two of these deserve extra attention. Fast mode on Opus 5 and Opus 4.8 prices at $10 input and $50 output per million tokens — exactly double the standard Opus rate on both sides. It is a legitimate latency tool and a catastrophic default. If a latency experiment shipped and nobody reverted the flag, you are paying Fable-tier prices for Opus-tier capability.

Web search at $10 per 1,000 searches is the one that scales with agent autonomy rather than with token volume, which means it does not appear in a token-based forecast at all. Three searches per task is $0.03 per task in search fees alone. At 100,000 tasks a month that is $3,000 that no token model predicted. Web fetch, by contrast, is free — so an architecture that resolves known URLs directly rather than searching for them is materially cheaper, and usually more reliable too.

The engineering practice here is unglamorous: reconcile the invoice against your own telemetry monthly. Not the dashboard — the invoice. Every line you cannot explain from your own token counts is either a surcharge you forgot about or a code path you did not know existed, and both are worth finding.

There is exactly one established framework here worth building on: the FinOps Foundation's FinOps for AI work. It organizes AI cost management on the same Crawl / Walk / Run maturity model the foundation uses elsewhere, and it defines ten KPIs — among them cost per inference, cost per API call, and token consumption.

The most interesting of the ten is the LM Model Choice Quality Score, which compares the capability a workload actually requires against the capability of the model deployed to it. That is a formalization of the single largest source of waste we see in production: every step of a pipeline running on the strongest model because that is what the prototype used, and nobody ever went back to ask which steps needed it. As of August 2026 the Opus tier is 5× Haiku 4.5 in both directions, so a pipeline where three of five steps could run on Haiku is leaving a large multiple on the table.

Below the framework sit the platform-native controls, and their semantics matter far more than their names. Two teams can both say "we have budgets configured" and mean completely different things.

Cost-guardrail semantics as of August 2026. Verified against Anthropic platform documentation.

The distinction to internalize: session budgets are a pre-request gate that pauses, and task budgets are an advisory ceiling the model sees as a countdown. The first is enforcement — the session stops making requests at budget_reached and resumes if you raise or remove the budget, which means your orchestration needs to handle a paused state that is neither success nor failure. The second is persuasion — it changes how the model paces itself, and it is explicitly not a hard cap. The hard cap on generation is max_tokens, which bounds output and, on Anthropic, thinking-plus-output together — and bounds input not at all.

A cost control you cannot describe in one sentence — what it gates, when it fires, and what state it leaves the system in — is not a control. It is a setting.

— Frenchy Digital FinOps principle

Everything above this section is arithmetic. This section is the one that changes decisions, and it is where the order-of-magnitude differences actually live.

The problem with cost per call is that it rewards the wrong thing. A cheaper model that fails 30% of the time and gets retried is not cheaper; it is more expensive with a better-looking dashboard. The only metric that makes model choice, reasoning effort, retry policy and scaffold design comparable on one axis is cost per successful task.

Princeton's Holistic Agent Leaderboard is the best public work on this, and it is deliberately cost-controlled. The underlying study ran 21,730 rollouts across nine models and nine benchmarks at a cost of roughly $40,000, releasing 2.5 billion tokens of logs. Two findings should reshape how you budget.

The second finding is the leaderboard's own summary: agents can be 100× more expensive while only 1% better. Its SWE-bench Verified Mini row has Sonnet 4.5 at high effort scoring 72.0% for $463.90. On GAIA, Claude Sonnet 4.5 scores 74.5% at $178.20. The point is not the specific models — those move — it is that the cost axis separates configurations that the accuracy axis alone makes look identical.

The same pattern predates the current generation. Kapoor and Narayanan's AI Agents That Matter found that on HumanEval, the LATS scaffold cost more than 50× a trivial retry baseline with no accuracy advantage. Complexity in the scaffold is a cost multiplier that has to earn its place empirically.

Published per-task cost figures are still rare, so here are the ones that exist, gathered in one place. They are useful less as absolutes than as a demonstration of how wide the cost spread is at similar accuracy.

Published cost-per-task figures from cost-controlled leaderboards, as of August 2026. The SWE-rebench rows are the most decision-relevant: three times the cost for seven-tenths of a point.

The practice this implies is straightforward and almost nobody runs it. Take 20 to 50 tasks drawn from real failures. Run each one isolated from a clean environment. Grade the outcome, not the path. Record tokens and dollars alongside pass or fail, and report cost per successful task. Then run it in CI on every model change, prompt change and scaffold change — because a model upgrade is a cost event as much as a quality event, and the reasoning-token traps in this article are exactly the kind of thing such a suite catches on the day it happens rather than at the end of the month.

Worth noting how uncommon this still is. LangChain's State of Agent Engineering survey (n=1,340, fielded November to December 2025) found 89% of respondents had some observability but only 52.4% ran offline evals and 29.5% ran none at all — and that is a vendor-run, self-selected sample biased toward eval adoption. If nearly a third of a favorably-biased sample runs no evaluation, the share running cost-aware evaluation is small enough to be a genuine competitive advantage.

The strategic question behind every one of these tactics is whether to optimize hard now or wait for prices to fall. The best available evidence says prices for a given capability fall fast — but the evidence is older than it should be, and quoting it as current is a mistake.

Epoch AI found that prices for a fixed capability level fell between 9× and 900× per year depending on the benchmark, with GPT-4-level performance on GPQA Diamond falling roughly 40× per year. That is an enormous range, and the range is the finding: the rate depends entirely on which capability you hold constant.

The planning consequence is narrower than the headline suggests. If you need frontier capability, waiting does not help — frontier prices are set by frontier economics, and Fable 5 at $10/$50 is above the Opus tier, not below it. If you need today'scapability in twelve months, waiting probably does help, and the corollary is not to sign long capacity commitments at today's prices for capability that will get cheaper. It also argues against over-investing in exotic optimization for a workload that will be commodity-priced before the optimization pays back.

For market context rather than price: Menlo Venturesput enterprise AI spend at $1.7B in 2023 rising to $37B in 2025, with foundation-model APIs at $12.5B of it. That report is dated December 2025 and no 2026 edition exists. Spend is growing much faster than unit prices are falling, which is the real answer to "won't this get cheaper?" — yes, per token, and your bill will still go up, because falling unit prices are what makes the next workload viable.

Ordered by return per hour of engineering, highest first. Most teams can complete the first three in a week and see the effect on the next invoice.

Frenchy Digital cost-reduction checklist for LLM agents, ordered by payback — as of August 2026.

Two sequencing notes. First, do not start at line eight. Cost-per-successful-task evaluation is the highest-ceiling lever and the slowest, and running it before you have done the arithmetic means you are measuring an unoptimized system very precisely. Second, instrument before you optimize: if you cannot see input tokens, output tokens, cache reads, cache writes and reasoning tokens broken out per workflow, you will not be able to tell which of these changes worked.

• The minimum telemetry: Per request: model ID, input tokens, output tokens, cache-read tokens, cache-write tokens, reasoning tokens, tool calls, latency, and a workflow tag. Everything in this article is diagnosable from those nine fields, and almost nothing is diagnosable without them.
• Alert on cache-read rate: A cached path where the cache-read count drops to zero is the silent minimum-prefix failure. It will not show up in latency and it will not throw. It only shows up in tokens.
• Alert on reasoning-token share: Reasoning as a percentage of output tokens, per workflow, per model version. A step change after a deploy is the all_turns or adaptive-thinking trap firing.
• Reconcile invoice to telemetry monthly: Not the dashboard — the invoice. Unexplained delta means a surcharge, a code path you did not know about, or a model you did not know was being called.
• Re-verify prices quarterly at minimum: Prices move monthly. The Sonnet 5 intro rate ending August 31, 2026 is a scheduled example; the unscheduled ones are the problem.
• Tag spend by workflow and tenant from day one: Retrofitting attribution onto an existing system is a project. Adding a tag field at the start is a line of code, and it is the prerequisite for every conversation about which feature is worth its inference bill.

Every one of these has appeared in a real cost model we have reviewed. None are hypothetical, and most of them cost real money for months before anyone noticed.

The Frenchy Digital red-flag list for LLM cost models, as of August 2026.

If a cost model does not carry the date each price was verified, it is not a model — it is a snapshot with an unknown expiry. Put the verification date in the cell next to the number.

— Frenchy Digital cost principle

These are the bands Frenchy Digital uses to scope AI agent engagements in 2026. Cost engineering is in scope at every tier rather than sold separately, because the decisions that determine inference spend — model routing, cache structure, context strategy, reasoning configuration — are architecture decisions made in week two, not optimizations applied in month six.

Frenchy Digital cost bands for AI agent engagements, 2026.

Senior-led delivery runs $150 to $225 per hour, and ongoing retainers run $2,500 to $9,500 per month covering model and dependency upgrades, eval expansion, incident response, and a quarterly technical review — which, on this topic, is mostly a price re-verification and a look at where the token distribution has drifted. Every engagement carries a 30-day post-launch warranty, and you receive a written scope with a fixed-price phased proposal within 5 business days of the discovery call.

One budgeting note. The cost work is largely front-loaded and then reused. The first agent pays for the telemetry, the cache design, the routing layer and the eval harness. The fourth agent inherits all of it. Teams that sequence their agents get considerably better unit economics than teams that run four disconnected pilots in parallel, each with its own untagged spend.

What this article cannot tell you, and where its numbers stop being reliable.

• Every price here expires: All figures are as of August 2026, taken from official pricing pages. Provider pricing moves monthly. The Sonnet 5 introductory rate is scheduled to end August 31, 2026 — the unscheduled changes are the ones that will break your model.
• The agent token multipliers are vendor-published: No independent, non-vendor case study with real token-per-task numbers was available when this was written. The 4× and 15× multipliers, and both worked examples, come from Anthropic. They are internally consistent and they are the best available; they are not audited.
• The price-trend data is dated: Epoch AI's 9×–900× per year finding was published March 12, 2025 with no verified 2026 update. Artificial Analysis's cost-per-task figures were not extractable. Stanford's AI Index 2026 publishes no inference-cost figures — do not cite it for them.
• OpenAI's long-context surcharge is unresolved: The models page states no threshold; the pricing page carries a generic note about extended context doubling pricing on select models. Which models could not be determined. Verify against your own invoice rather than any secondary summary.
• Several prices could not be verified at all: Mistral Medium 3.5, Small and OCR 4 pricing was not published on the page. First-party Qwen pricing was not obtainable — the model IDs are confirmed on Alibaba Cloud but the rates were not. Gemini context-window token limits were not verified. Those gaps are stated rather than filled.
• The FinOps framework stops short of the hard part: The FinOps Foundation publishes no model-routing specification and no token-attribution methodology. Routing policy and shared-prefix attribution are engineering you will do yourself, and there is no standard to point at when someone asks how you decided.
• A cheaper model can be more expensive: Every routing decision in this article is a hypothesis until you measure cost per successful task. Princeton HAL's finding that higher reasoning effort reduced accuracy in the majority of runs is the clearest warning that intuition is unreliable here in both directions.
• Cost caps are not a security control: A budget ceiling limits what a compromised or misdirected agent can spend. It does nothing about what that agent does with the calls it can afford. Prompt injection remains unsolved; the correct framing is defense-in-depth and blast-radius reduction, and a dollar cap is one small piece of blast-radius reduction — not a safety property.
• Optimization has an opportunity cost: An engineer-week spent shaving 15% off a $400 monthly bill is a bad trade, and we have watched teams make it. Size the spend before you size the effort. Below roughly $2,000 a month, do the first three checklist items and stop.

None of this argues against cost engineering. It argues for doing the arithmetic first, dating every number, measuring cost per successful task rather than cost per call, and re-verifying before anything here reaches a board deck. The teams that control inference spend are not the ones with the cleverest optimizations — they are the ones who can see their token flow and know when a price last changed.