System One inference costs and Jevons effects

At 17:40 on the last business day of a quarter, a platform team sees an inference dashboard moving in the wrong direction. The model provider has reduced the effective price of the small, fast model used for classification, extraction, and short drafting. The original forecast assumed the same requests would now cost less. Instead, daily spend has climbed. A support triage feature that once ran only on submitted tickets now summarizes whole conversations. The sales application drafts follow-ups after every account event. Internal search adds query rewriting, result compression, and answer verification. None of these calls existed in the old baseline.

The immediate failure is not arithmetic. The team treated inference as a fixed workload whose unit price changed, while the product organization treated cheaper inference as permission to make more decisions, at more points in more workflows. The relevant question is therefore not whether a request is cheaper. It is whether the fall in cost changes the number, shape, and economic threshold of requests. System One models make that question acute because their low latency and relatively low cost let inference move from a visible feature invocation into the control path of ordinary software.

The baseline assumes demand is fixed

For a fixed workload, inference spend is simple: total spend equals the effective price per input and output token, plus any request-level charges, multiplied by volume. Lowering the unit price lowers the bill. That model is useful for batch jobs with a fixed corpus, contractual throughput, and a stable prompt template. It is also the model behind many procurement calculations: substitute one serving endpoint for another, hold requests constant, and report savings. The calculation becomes false when the lower price changes which calls are economically admissible.

System One models are especially likely to cross that threshold. The term here denotes models positioned for frequent, bounded decisions: routing, extraction, classification, lightweight generation, tool selection, policy checks, and similar tasks that sit near interaction loops. Their value is often not in replacing a single expensive expert answer. It is in making many small judgments cheap enough to distribute through an application. This is why a cost reduction can alter architecture rather than merely optimize it: functions that were manually coded, skipped, sampled, or deferred become model-mediated.

Jevons effects require an elastic workload

A Jevons effect occurs when efficiency lowers the effective cost of using a resource enough that total resource consumption rises. For inference, the resource may be tokens, requests, accelerator time, reserved capacity, or the all-in charge attached to a model call. A rebound is partial when volume rises but the total bill still falls. It is backfire when volume rises enough to more than offset the lower unit cost. The distinction matters because teams often observe a cheaper model and declare savings before measuring demand created by the new operating point.

Elasticity is not a property of a model alone. It belongs to the workload and the organization around it. A compliance pipeline processing every required document has limited room to expand unless the document universe changes. A customer product with optional assistance has much more room: a lower cost can remove quotas, extend eligibility to lower-value accounts, increase response frequency, or support features previously excluded from the roadmap. Which is what breaks when spend is reported only as cost per million tokens. That metric describes the price of an input, not the amount of product behavior the input enables.

Cheap calls create new surfaces

The first source of expansion is extensive margin: more places in the system make a model call at all. A model that was used only for a final response can become a preprocessor for every user action. Search gains intent normalization and reranking. Forms gain extraction and validation. Support gains classification before assignment and summarization after resolution. Developers add evaluation calls in continuous integration and generated tests in review workflows. Each feature can be locally rational because it consumes a small amount of inference while improving conversion, completion, safety, or operator throughput.

The second source is intensive margin: existing surfaces call the model more often or with more context. A product can remove a daily cap, summarize longer histories, regenerate on edits, perform multiple candidate generations, or include retrieval results that were previously excluded for cost reasons. The cost decrease may also shift a model from asynchronous processing into an interactive path, where repeated user corrections create more turns. This is why total usage does not track active users cleanly. A stable user count can still produce a rising bill when each session becomes more instrumented with inference.

Agents turn demand into feedback

Single-turn features create a relatively legible rebound: calls per active user increase, then product adoption may follow. Agentic systems add another mechanism because the model is not merely producing a result; it selects tools, observes outputs, and decides whether to continue. Lower inference cost makes planners willing to explore more candidates, critique intermediate results, repair failed tool calls, and run verification before returning an answer. The cost of one user-visible task becomes a distribution rather than a fixed request count, with long tails driven by difficult cases and unstable environments.

That leaves a control problem. A controller that treats a cheap model call as negligible can generate large aggregate work through recursive delegation and retries. Tool failures, ambiguous observations, and partial success are all opportunities for another turn. Even when token price falls, external actions may remain expensive: database reads, search queries, browser sessions, third-party APIs, and human review queues can dominate the cost or create operational risk. A lower model bill can therefore expose a different bottleneck while increasing total system spend. The Jevons effect is not confined to the model-provider invoice.

Unit economics must include the induced work

The useful accounting unit is not cost per call but contribution per completed outcome. That requires separating calls that replace existing work from calls that create new work. A routing call that replaces a manual queue decision has one economic shape. A generated follow-up that increases customer engagement has another. A verification pass that prevents costly errors may justify multiple model calls even when it raises gross inference spend. Conversely, an auto-generated summary that no downstream actor reads is pure induced load, regardless of how cheap it is per token.

Attribution is difficult because the benefits and costs appear in different systems. The application team sees improved completion. The platform team sees token growth. Finance sees a larger vendor commitment. Operations sees more tool traffic and review exceptions. This is why a price decrease can look like a failed optimization from one vantage point and a profitable expansion from another. The accounting question must preserve both statements: did unit efficiency improve, and did total resource use increase? Treating those as mutually exclusive obscures the mechanism.

Capacity changes the shape of the rebound

Price is not the only effective constraint. A System One model may be cheap in nominal terms yet unavailable at the concurrency required for widespread embedding in a product. Queueing delay, rate limits, regional capacity, and tail latency can keep demand from materializing, or push teams toward smaller prompts and fewer sequential calls. In self-hosted settings, the equivalent constraints are accelerator inventory, memory bandwidth, batching behavior, and the opportunity cost of serving one workload instead of another. A cheaper model can increase demand until latency becomes the new price.

This matters because latency also governs product design. A background enrichment job can tolerate a multi-stage workflow; an interactive editor may permit only one bounded call. Agentic plans that look economical at average cost can fail at tail latency, where retries and serial tool use delay the user-visible outcome. Capacity management therefore cannot be separated from Jevons reasoning. If capacity is provisioned in anticipation of new demand, the system can admit more expansion. If it remains hard-capped, spending may not rise, but waiting time, rejected work, or feature degradation will reveal the same underlying demand pressure.

Budgets work when they encode policy

A global monthly budget is a weak control because it reacts after heterogeneous workloads have competed for the same pool. Better controls attach a policy to the unit that creates demand: a per-task inference allowance, a maximum agent step count, a tool-call budget, a context limit, a retry policy, and a required confidence or expected-value threshold for escalation. These controls do not deny the rebound; they decide where it is allowed. They make explicit that a low-value classification should not consume the same open-ended execution budget as a high-value operational decision.

Evaluation has a role here beyond model selection. It can measure whether additional calls improve the relevant outcome enough to justify their marginal cost and latency. The key comparison is often not model A against model B, but one pass against two, a short context against a retrieved context, or a bounded workflow against a self-directed loop. This is why token caps alone are insufficient. They prevent runaway usage, but they can also cut off the calls with the highest marginal value while allowing a large population of low-value calls to continue unchanged.

What remains contested

The unresolved question is not whether rebound exists; it plainly can. The contested question is whether a given expansion is wasteful consumption or valuable output that a fixed-workload budget would have suppressed. Reasonable engineers disagree because the counterfactual is hard to observe. A wider assistant may raise support costs while preventing churn that is only partially measurable. An agent may spend more on verification while reducing rare but expensive failures. An internal productivity feature may redistribute work rather than eliminate it, making both its savings and its induced demand difficult to attribute.

There is also a genuine design disagreement about where to constrain the system. Some teams prefer strict centralized quotas because they bound financial exposure and force prioritization. Others prefer local outcome budgets because central caps can freeze useful experimentation and reward workloads that happened to arrive first. Neither position removes the underlying trade-off. System One inference becomes cheaper, applications discover more places to apply it, and total spend can rise even as efficiency improves. The durable engineering task is to make that expansion visible, value-sensitive, and bounded by the constraints that actually matter.