Inference Economics This Cycle — Pricing Convergence, the Effort Anomaly, and When Corrections Get Expensive

Juno —

A preregistered study (methods filed before the runs; revised September 10, 2026) ran Claude Opus 5 at maximum reasoning effort against hard coding tasks. It resolved fewer of them than the same model at low effort, at nearly five times the cost per success.

Hold that next to the other two things that moved this cycle. Provider pricing has converged on identical headline numbers while diverging on the conditions that set your actual bill. And correction cost now sorts cleanly by timing, which it didn't last cycle. Together these change what your inference-aware surfaces have to do.

I've organized all three around the variable they share: when in an agent's lifecycle you intervene determines both the dollar cost of the fix and what the product owes the user at that moment.

All pricing below reflects published provider documentation as of early October 2026 unless otherwise noted.

Identical headline prices, different bills

OpenAI's GPT-6.1 Sol and Anthropic's Sonnet 5.5 both publish $2 per million input tokens, $10 per million output tokens. Google's flagship reasoning model, Gemini 4 Argon, isn't on the public Gemini API yet; it launched through a restricted program, so I can't compare its production pricing directly. Google's publicly available reasoning model, Gemini 3.8 Flash, is in their API catalog, and Artificial Analysis measures its cost per task at $0.93–$1.24 depending on effort level. That puts it in a comparable range, though I'm working from measured cost-per-task rather than a published per-token rate. Together AI's recommended model, Kimi K3, runs $3/$15, fifty percent more on output.

Confidence: high on OpenAI and Anthropic. Moderate on Flash cost positioning (Artificial Analysis measurement, not provider-published per-token rate). Unresolved on Argon production pricing.

Three conditions pull that same headline price into very different bills for the same workflow.

Reasoning tokens bill as output and aren't visible before the call. When these models "think," working through a problem internally before producing a visible answer, they generate reasoning tokens. All major providers charge these at the output rate and don't expose the raw reasoning text by default. You get a token count after the response. A call that produces 200 visible output tokens might consume 3,000 reasoning tokens behind it. Your bill reflects 3,200. Both OpenAI and Anthropic offer effort-level controls (low through max at OpenAI, low through xhigh at Anthropic) that influence how many reasoning tokens get generated, but these are guidance, not caps. Both providers warn that extensive thinking can exhaust the output token limit before any visible answer arrives, which means you can pay in full for reasoning that never surfaces.

Batch discounts converge at 50%, eligibility doesn't. OpenAI and Anthropic both offer 50% batch discounts on their flagships, dropping effective cost to $1/$5. Google offers 50% for supported models. Together doesn't apply it to Kimi K3. So latency tolerance sets your unit cost. If a workflow can wait overnight, it runs at half price at two of the three providers and full price at the open-source endpoint.

Context-length pricing breaks differently. OpenAI doubles input cost and adds 50% to output cost once a GPT-6.1 Sol request exceeds 272,000 input tokens. Anthropic's Sonnet 5.5 runs its full million-token window at flat pricing. For long documents or multi-turn agent sessions, that surcharge compounds across the session.

What to do with this: any product surface showing users a cost indicator for inference is misleading unless it accounts for reasoning tokens, context length, and batch versus real-time. Same model, same prompt, same visible output — 2x to 5x difference in what you're billed. Design the signal to reflect the actual bill, or don't show one.

More reasoning makes hard tasks worse

In Issue 13 I wrote that medium effort should be the default and anything above it should earn its place. The new evidence is sharper than what I had then.

The preregistered study (revised September 10, 2026; not yet peer-reviewed) tested Claude Opus 5 and Claude Sonnet 5 at low, high, and xhigh effort on 25 hard tasks from SWE-bench Verified, a benchmark built from real GitHub issues with validated fixes.

At xhigh, both models cost more and resolved less than at high. The regressions included scope-expanding edits that broke previously passing tests, and timeouts that produced empty output. All six timeouts and all four empty patches in the study occurred at high or xhigh effort.

Separately, Artificial Analysis measured Gemini 3.8 Flash scoring 40 at medium effort and 41 at high on their composite index (Intelligence Index v4.3.2; measurement date not specified, published as current), while cost per task rose from $0.93 to $1.24. GPT-6 Astra plateaued similarly: 46 at low, 50 at medium, 51 at high, 52 at xhigh, 53 at max, with cost per task climbing from $0.82 to $3.26. Most of the gain arrives early. The last three effort levels cost progressively more per point.

Confidence: high that these specific samples contain plateaus and reversals. Moderate on generalization. The degradation evidence comes from a non-peer-reviewed preprint on coding tasks, and the Artificial Analysis data shows diminishing returns rather than outright degradation.

What to do with this: default to medium. Make escalation a deliberate act with a visible cost signal attached. The user's intuition that harder thinking produces better results is empirically wrong on hard tasks. A settings dropdown that runs to max without surfacing the cost-quality tradeoff is a design failure with dollar consequences. The effort-selection surface I spec'd in Issue 13's build queue, where route rows combine model, effort, latency, cost, and verification burden, is where this constraint gets resolved.

Correction cost scales with timing

What it costs to fix what an agent got wrong depends on when you catch it. The pricing data and the effort anomaly both come to bear here, because the timing of a correction determines whether you're paying cents for a re-run or thousands in labor for damage control.

Before planning: cheap

Effort selection, prompt design, and model routing happen here. The preregistered study found that prompt wording alone changed reasoning volume by a factor of 2.4 to 7.4. Choosing the wrong effort level before the model starts costs you the difference between a wasted call and a correctly configured one, which is cents to single-digit dollars. Batch pricing creates a structural advantage at this stage: work that doesn't need a real-time response runs at half cost at OpenAI and Anthropic, so a failed batch job can be re-run inside the same 24-hour window at $1/$5 rather than $2/$10. The batch pathway carries correction budget that real-time doesn't. The design surface is pre-call configuration, and good defaults make most corrections here free.

During execution: moderate and rising

Once the model is mid-reasoning or mid-tool-call, correcting it means interrupting and restarting. The study documented what that looks like: xhigh runs stretching 23 to 30 turns before timing out or producing empty patches. Wasted inference plus wasted wall-clock time. The reasoning-token invisibility problem compounds this. A model that has burned 15,000 reasoning tokens with nothing visible is a different interruption decision than one 200 tokens in, and the interface shows the same spinner for both. If the agent has already made tool calls that read from external systems, those calls may have consumed rate limits, triggered logging, or altered state in ways a re-run won't cleanly replicate. A 24-hour batch job that fails at hour 18 costs the full day plus the re-run. The design surface here is interruptibility and progress visibility: can the user see what the agent is doing and stop it before the cost compounds?

After external effects: expensive to impossible

Once an agent has sent an email, written to a database, called a payment API, or posted to an external service, correction stops being an inference problem and becomes a compensating-action problem. As I covered in Issue 12's claims ledger spec, the boundary between Authorized and Committed is where an operator can no longer reverse the action alone. Past it you need domain-specific recovery: an engineer investigating a bad database write (speculative: $200–$1,000 in labor before downstream effects), a support team managing fallout from an incorrect email, a finance team unwinding a payment that shouldn't have cleared. Recovery can fail, and it often produces a new state rather than restoring the old one. A sent email stays sent; a cleared payment comes back only as a second transaction. The distance between inference cost (dollars) and post-effect recovery cost (hundreds to thousands in labor, plus relationship damage nobody can price) is the economic argument for confirmation gates before commitment.

Confidence: high on the inference-cost mechanics at the first two stages. Speculative on the post-effect dollar ranges, which are order-of-magnitude estimates from operational patterns rather than a published cost study. High on the structural claim that post-effect correction costs sit in a different category than inference costs.

What the product owes at each stage follows from that. Before planning: good defaults and a visible cost signal. During execution: interruptibility and progress legibility, including reasoning-token consumption. After external effects: confirmation gates that hold commitment until the user has seen evidence sufficient to warrant it. This is the status-claims problem from Issue 12 with prices attached. An interface that reports "Done" when it means "Committed" has hidden the correction cost at the point where it stops being measured in tokens.

Domain ranking this cycle

Ranked by urgency given the economics above.

1. Inference-Aware UX. Still first, and the case got stronger. Reasoning-token billing is invisible by default, effort escalation degrades outcomes on hard tasks, and batch eligibility varies by provider and model. The effort anomaly on its own demands a designed effort-selection surface with cost feedback: the user sees what medium costs, what xhigh costs, and what quality difference to expect, before choosing.

2. Agent Infrastructure as UX. Up from third. The correction-cost timing axis gives this domain the organizing principle it lacked last cycle. The gap between a cancellation request and confirmed termination of effects, which I covered in Issue 9, is where the highest-cost corrections live. Products that expose agent action without exposing the commitment boundary accumulate design debt with every external effect.

3. Intent-Based Interaction. Down from second. Effort selection is an intent-expression problem, but this cycle's economics make the infrastructure layer more urgent. "Think harder about this" is now measurably decoupled from the outcome it's meant to buy, and the intent surface can't be designed soundly until the inference-aware layer underneath it exists.

4. Human-Agent System Design. Still fourth. Mandate maintenance and return conditions remain relevant but sit downstream. Until the product can tell a user what a correction costs at each stage of the lifecycle, the system-design questions have no economic grounding to argue from.

The change from Issue 13 is Agent Infrastructure moving up. It moves because the correction-cost evidence now has enough structure to design against — stages with distinct cost profiles and distinct product obligations at each.