Inference Economics as a Design Surface

Inference-Aware UX moves to the top of the Build Queue this cycle. If you read three lines: independent benchmark data now shows where paying more for AI reasoning stops producing output a user can tell apart from the cheaper version; three shipping products expose reasoning-effort controls to end users while hiding the tradeoff those controls make; and the same query can cost anywhere from $0.55 to $5.98 depending on how it is configured. Something picks a point in that range for every request your product sends. In most products that something is a default inside an API call, set without design review.

What changed

Until recently a call to a frontier model carried one price attached to one model. You called it, you paid the rate. That is no longer how any of the three major providers sell inference. Anthropic, OpenAI, and Google now expose reasoning effort (how much internal computation the model spends before it answers) alongside speed tiers, caching, batch processing, and context-length pricing, each adjustable independently of the others. Stripe's pending acquisition of OpenRouter treats routing across 400+ models as an optimization problem with four named variables: task complexity, price, speed, reliability.

These are infrastructure developments with interaction consequences. Once reasoning depth and cost are per-request parameters, whoever sets them is shaping the experience as directly as whoever wrote the empty state. Most teams file this under backend configuration, which means the defaults land with whoever writes the API call, and the quality-cost tradeoff the user actually experiences never reaches a designer.

Three tensions in the current evidence, then the queue.

Tension 1: The diminishing-returns curve is now measurable

Does paying more produce a result the user can distinguish from the cheaper one? You can answer that with published numbers now instead of intuition.

Artificial Analysis, an independent evaluation shop, publishes composite quality scores across reasoning-effort levels for the three major frontier models. Their Intelligence Index (v4.3.2) averages agent, coding, scientific reasoning, and general capability evaluations. The shape is consistent across providers.

GPT-6 Astra scores 46 at low effort, 50 at medium, 53 at max. The first step, low to medium, carries four of the seven total points. Each level after that adds about one. Cost over the same range runs $0.82 to $3.26, so you pay 4x for a gain that mostly arrived in the cheapest increment.

Gemini 3.8 Flash is sharper. Low to medium: six points. Medium to high: one. The price difference between medium and high is small ($0.93 to $1.24), but so is the quality difference, and for most tasks it sits inside noise.

Claude Opus 5.5 has the widest spread, 42 at low to 58 at max, and the steepest cost curve, $0.55 to $5.98 per task. Gains stay real across the full range. That makes Opus the model where effort selection matters most and where choosing wrong is most expensive.

High confidence on the figures. Moderate confidence on the design implication. Artificial Analysis is reliable for relative ordering across models and effort levels and weak as a predictor for any one task. Their index is an average; your product's task mix is not that average, and a summarization workload almost certainly bends at a different point than a multi-step coding workload. The aggregate shape is still clear enough to act on. Treat medium as the default and make anything above it earn its place.

A product that routes every query at the same effort is overspending on the easy ones and possibly underspending on the hard ones. The gap between low and medium is large enough that users would notice it. The gap between high and max is small enough that most would not. If you know roughly where the knee of the curve sits for your task distribution, routing decisions can improve cost and perceived quality at the same time.

Tension 2: Who decides how much intelligence to spend

Three shipping products currently put some version of this decision in front of users.

• Perplexity offers Light, Standard, High, and Ultra effort modes.
• Cursor exposes Cost, Balance, and Intelligence routing modes plus real-time usage tracking.
• Replit offers Lite, Economy, and Power, with a Turbo option inside Power flagged in orange because it can cost up to 6x a regular Power request.

So the claim that these controls have to stay invisible is already disproven. What the three of them actually surface, though, is an abstraction layer. Light versus Ultra. Cost versus Intelligence. The user picks a tier. They do not see the estimated cost of this particular request, the model being routed to, the reasoning depth applied, or why the task was classified the way it was. In Cursor's Balance mode, which model produced the output can be hidden, and hiding is the documented default.

The abstraction simplifies a decision most users have no interest in reasoning about. It also obscures the tradeoff in ways that may serve the platform's margin as much as the user's outcome. I can document the gap; I cannot confirm from public evidence whether any specific product's routing defaults optimize for user quality or platform cost, because none of them publishes an optimization objective in those terms. Moderate confidence on the alignment concern. The structural incentive, though, is plain: when the platform pays for inference and the user cannot see the bill, the platform has a reason to route cheaper than an informed user would choose.

OpenRouter's Auto Router shows the mechanics. It classifies prompts into roughly 30 task types, then ranks candidate models using aggregate community spending over the trailing seven days. When a developer specifies no cost tier, the default behavior is approximately the low tier. That default is a design decision with user-experience consequences, and it optimizes toward the platform's cost floor rather than the user's quality ceiling.

Developers can override it: cost tiers from low through max, model allow and exclude lists, data-retention constraints, provider price caps. Provider routing separately applies inverse-square weighting by price among stable endpoints, favoring cheaper providers while keeping fallbacks in reserve. All of these controls are developer-facing. The end user of a product built on OpenRouter sees none of it unless a designer decides to surface it.

Stripe's acquisition means the task classifier, the cost-tier defaults, and the provider weighting are becoming infrastructure inside a company that processes payments for millions of businesses. Model selection and inference-cost optimization move from something a developer configures once into something that runs continuously in production.

That 30-task-type classifier is also the closest thing to intent-based effort routing currently documented anywhere in production. It reads the prompt, assigns a category, and uses the category to pick a model and an effort level. All of it happens on the platform side. The person who typed the query never sees the task label, the effort level it triggered, or the reasoning behind the match. The products that do expose controls ask users to pick a tier before the query, when they have the least information about what it will require. So the gap sits between two partial answers: a system that asks users to pre-select an effort level they cannot calibrate, and a system that infers the right level and never says what it chose. Neither gives the user what they would need to evaluate a spending decision task by task.

In issue 9 I argued that model fallback and routing can change capability, failure modes, and data handling without changing the user's authorization. The OpenRouter documentation confirms the mechanism. A substitution happens, the output arrives, and unless the product surfaces model identity the user cannot know this answer came from somewhere different than the last one. Whether that is a performance optimization the user does not need to see or an authority change they should consent to has no consensus answer right now.

Tension 3: Pricing thresholds create design problems

Past effort levels, the pricing structures themselves force decisions that land in the interface.

OpenAI charges 2x input and 1.5x output rates when a GPT-6 Astra request exceeds 272,000 input tokens. It is a cliff, not a ramp. Cross it by one token and the whole request reprices. If your product lets users attach long documents, you have to decide whether to warn before the crossing, truncate silently, or absorb the difference. Each of those answers costs you something in trust.

Anthropic's fast mode for Opus 5.5 doubles the per-token price ($8/$40 against $4/$20) for a claimed 2.5x speed improvement. No independent benchmark has validated the speed claim or tested whether fast mode changes output quality. It is a research preview, unavailable through partner clouds, incompatible with batch processing. Choosing it for a latency-sensitive interaction is a bet on an unverified provider claim at twice the price.

Gemini 3.8 Flash pricing doubles on January 1, 2027. The introductory $0.75/$3.75 becomes $1.50/$7.50. Anything you build on Flash's current economics has three months. Budget planning is the easy part of that. The harder part is whether the quality-cost tradeoffs you designed around still hold once the floor price doubles.

High confidence on all pricing figures, checked against provider pages as of September 27, 2026. These are offered prices, not realized spend, which depends on caching behavior, batch eligibility, and prompt construction.

Build Queue: what to build first

In issue 8 I proposed an inference-aware interaction surface built on three user-level constraints: cost ceiling, acceptable delay, minimum reliability. The user specifies consequences, the system handles parameters. That was a position without evidence under it. The evidence exists now: a measurable quality-cost curve, documented routing mechanics on the platform side, and three products that expose a control while withholding what it costs.

The four forward-looking artifact domains, ranked by current urgency:

1. Inference-Aware UX. Build first. Almost everything above belongs to this domain. I ranked it below Agent Infrastructure last cycle on thinner evidence. An artifact showing how a product makes inference tradeoffs legible, as a decision surface that tells users when spending more matters and when it does not, addresses a gap no shipping product currently fills.

2. Intent-Based Interaction. Prepare. The gap in Tension 2, between tier-picking and intent-inference, is the design problem at the center of this domain. A system that reads intent accurately can route to the right effort without asking the user to calibrate something they cannot see. The artifact depends on having the inference-aware layer specified first.

3. Agent Infrastructure as UX. Monitor. Last cycle's priority. The Claims Ledger specification from issue 12 handled the status-claim problem. Inference economics add a cost dimension: an agent spending $5.98 per reasoning step across a ten-step workflow produces a $60 task that might have cost $13.40 at medium effort on the same model with marginal quality loss, or under $10 on a different model if the task tolerates the switch. But the infrastructure artifact work is already further along than the inference-aware layer.

4. Human-Agent System Design. Hold. These findings feed it eventually. A human-agent system where the human controls the spending envelope is a different system than one where the agent decides. The interaction surface for that decision lives in the first two layers, so build those.