The Consumption Forecast: Warning Stakeholders Before the First Invoice

A realistic SLA tells a stakeholder what latency and quality to expect. It's a separate, equally important commitment to tell them what the *bill* will look like -- and this is a place where architects who are otherwise careful about expectation-setting still routinely drop the ball, because the cost conversation that happened during discovery and design was almost always priced against pilot-scale numbers, not production-scale ones.

The Core Guidance: Forecast at Production Volume, Not Pilot Volume

Architects should proactively give stakeholders a projected spend figure calculated at the production traffic level they'll actually run at -- not pilot or proof-of-concept volume -- before the first invoice arrives. This has to happen proactively, meaning before the bill lands in someone's inbox, not as a reactive explanation after a stakeholder is already alarmed by a number they weren't expecting.

Why Pilot-Scale Costs Are a Trap

Production volume is rarely a gentle step up from pilot volume -- it's common to see traffic land at 50x, 100x, or more of whatever the pilot exercised, not a modest multiple of it. A pilot that ran 50 requests a day and cost $30 a month is not a system that will cost $3,000 a month at 5,000 requests a day just by linear scaling -- it might cost far more, or in some cases proportionally less, depending on how costs actually scale with volume in the specific architecture. The number that matters is the number at the volume the system will actually run at once it's live, not the number a small pilot happened to produce. A stakeholder who approved a design based on pilot-scale costs, and who then sees the real production bill, experiences that gap as a broken promise -- even if the architect never actually promised the pilot number would hold at scale, because nobody ever said otherwise out loud.

Why the Shock Damages Trust Regardless of Technical Soundness

This is the sharpest part of the lesson: the damage from an unforecasted cost shock happens regardless of whether the technical design was sound. An architecture can be exactly the right choice -- correctly scoped, well-architected, delivering exactly the quality and latency it was supposed to -- and still produce a moment where the stakeholder's trust in the architect collapses, purely because the bill arrived as a surprise. Cost is one of the business-value pillars (alongside latency, quality, and risk) that a stakeholder weighs a decision against, from Lesson 6.2's audience-anchoring framework; a surprise on that pillar undoes trust just as thoroughly as a surprise on an unmet SLA would, even when every other dimension of the system performed exactly as promised.

An Original Worked Example: The Fixed Per-Session Overhead Trap

Suppose a pilot tests a customer-support drafting assistant at 50 requests a day for three weeks. The pilot's bill comes in around $30 for the month, and the stakeholder mentally files the system as "cheap to run" -- a reasonable inference from the only number they've seen. Production rollout expands usage to 4,000 requests a day, roughly an 80x increase in volume. If cost scaled purely linearly with request count, the stakeholder might brace for something like $2,400 a month and be pleasantly surprised or unsurprised either way.

But the actual architecture has a per-session context-loading step: each new customer session requires loading and formatting a substantial chunk of that customer's account history and prior ticket context into the prompt before the first request in the session can be answered, and that loading cost is fixed per session regardless of how many requests happen within the session. At pilot volume, sessions were long (many requests per session, since testers ran extended conversations), so the fixed per-session overhead was amortized across many requests and barely visible in the per-request average. At production volume, real customer sessions are short -- often just one or two requests before the ticket resolves -- so the fixed per-session overhead is paid over and over, on nearly every request, instead of being spread thin. The per-request cost at production volume isn't the same number scaled up; it's a meaningfully higher per-request number, because the mix of session lengths changed the economics. The result: an $800 a month bill instead of something in the $2,000–2,500 range the stakeholder might have braced for from linear scaling, or the far smaller number they'd unconsciously anchored on from the $30 pilot -- either way, a number nobody forecasted for them in advance, surfacing for the first time on an actual invoice.

The fix isn't a different architecture -- the per-session context loading may well be the right design choice, delivering real quality benefits from having full account context available. The fix is that the $800 figure, or something close to it, should have been forecasted and communicated *before* the production rollout, using production-volume assumptions and the actual session-length distribution expected in real usage, not the pilot's atypical long-session pattern.

How This Connects to SLA-Setting and the Broader Lifecycle

This is the same discipline as grounding an SLA in measured capability rather than aspiration, applied to the cost dimension instead of the latency dimension: just as an SLA has to be grounded in what the chosen model tier and pipeline steps can actually deliver, a cost forecast has to be grounded in what the chosen architecture will actually cost *at the volume it will actually run at*, not at whatever volume happened to be convenient or available during the pilot. And it connects to feedback loops and proactive re-alignment: if a scaling event is coming, the right move -- as with a model version change or a data shift -- is to communicate what it means before the stakeholder discovers the gap themselves, not after.

Common exam traps

• Extrapolating pilot costs linearly and presenting that extrapolation as the forecast, without accounting for non-linear cost drivers (fixed per-session overhead, cache-hit-rate changes at different traffic patterns, tiered pricing thresholds) that can make production costs diverge sharply from a linear projection.
• Treating cost communication as a one-time discovery-phase question ("what's your budget?") rather than an ongoing forecast that has to be updated and re-communicated as the volume assumptions become concrete before launch.
• Assuming a technically sound, well-performing system is immune to a trust breakdown over cost. It isn't -- an unforecasted cost shock damages trust independent of whether the underlying architecture was the right one.