The Margin Trap of "We'll Just Pass Through Model Costs"

Table of Contents

• The Sentence That Sounds Safe
• What "Pass-Through" Actually Means in Practice
• The Costs That Don't Show Up on the Model Bill
• Why a Markup on Tokens Caps Your Margin
• The Volatility Problem You Just Inherited
• What Pass-Through Trains Your Buyer to Believe
• A Better Frame: Price the Outcome, Manage the COGS
• A Worked Example
• Insights Most People Overlook
• References

The Sentence That Sounds Safe

Sit in enough early-stage GaaS pitch meetings and you'll hear it almost verbatim: "Pricing is easy, we'll just pass the model costs through to the customer and charge a margin on top." Everyone nods. It feels conservative, even responsible. How could you lose money if the people consuming the inference are the ones paying for it?

The reasoning is seductive because it borrows the logic of a healthy reseller business. A distributor buys at $7, sells at $10, pockets $3, and the more units move the more dollars they make. Clean. The problem is that an agent company is not a distributor, model tokens are not a stable wholesale good, and the inference bill is a small and shrinking slice of what it actually costs to run a reliable autonomous agent. "Pass through and mark up" answers the wrong question. It tells you how to avoid one specific loss, paying for someone's tokens out of pocket, while ignoring every other way the economics can go sideways.

I want to be precise about the claim here, because cost pass-through isn't always wrong. There are contexts (high-volume, sophisticated buyers, true commodity workloads) where transparent metered pricing is exactly right. The trap is treating it as the default mental model for an agent business, and especially treating the model bill as if it were your cost of goods sold. It isn't. Not even close.

What "Pass-Through" Actually Means in Practice

When a founder says "pass through model costs," they usually mean one of three things, and they're rarely clear about which:

1. Literal metered resale. You expose token consumption to the customer and bill it at provider cost plus X percent. The customer effectively sees your OpenAI or Anthropic bill with a surcharge.
2. Cost-plus bundling. You estimate model cost per task, add a markup, and quote a per-task price that's really cost-plus underneath even if the customer never sees tokens.
3. A pricing-floor heuristic. You don't actually bill this way, but you reassure yourself that "at least model cost is covered" when you set prices.

All three share a fatal assumption: that the model bill is the dominant variable cost and a reliable anchor for price. For a thin wrapper that does one model call and returns the output, maybe. For an actual agent, something that plans, calls tools, retries on failure, verifies its own work, and sometimes spawns sub-agents, the model bill is one line item among many, and frequently not the largest one. The moment your product becomes worth paying for, pass-through stops describing your cost structure.

The Costs That Don't Show Up on the Model Bill

Here's the part the "just pass through" crowd skips. Run the full accounting of what it costs to complete one task reliably and the model tokens are often 30 to 60 percent of true variable cost, sometimes less. The rest is invisible to your provider invoice:

• Retries and re-planning. A task that fails its first attempt and gets retried doesn't cost 1x, it costs 2x, 3x, or in pathological cases 50x. We've written a whole node of this cluster on the hidden cost of retries, but the short version: your advertised per-task cost and your blended per-task cost diverge the instant reliability enters the picture.
• Orchestration and tool calls. Every external API the agent hits, search, a CRM write, a code sandbox, a vector lookup, carries its own cost and latency. These stack and compound across a workflow and never appear on the model bill.
• Evaluation and guardrails. Running an LLM-as-judge to grade the agent's output, content filters, schema validators, retry-decision logic. This is often a second model call per task, sometimes a more expensive one.
• Idle and warm-pool cost. Long-running agents and low-latency SLAs mean you're paying for capacity that sits idle between tasks, a cost vendors are notoriously good at hiding from their own dashboards.
• Human-in-the-loop. Every task that escalates to a human reviewer carries a labor cost that dwarfs any token spend. If 8 percent of tasks need a human and that human costs $0.40 of loaded time per touch, that's $0.032 amortized across every task, frequently more than the inference.
• Support, onboarding, and the long tail. Debugging why the agent did something weird for a single customer can eat an engineer-afternoon. None of it shows up when you "pass through model costs."

If you price on the model bill plus a markup, you have implicitly decided that all of the above comes out of your margin. McKinsey's work on capturing value from generative AI makes the same point in different language: the model is increasingly a commodity input, and the durable economics live in the orchestration, data, and reliability layers around it. Price the commodity and you've handed away the part with margin.

Why a Markup on Tokens Caps Your Margin

Cost-plus pricing has a structural ceiling that founders rarely think through. When your price is anchored to your cost, your revenue can only grow as fast as your costs grow. That's backwards from what you want. The whole point of building software leverage is that value delivered should decouple from cost incurred.

Consider what happens when you get better at running the agent. You improve your prompts, add caching, route easy tasks to a cheaper model, and your model cost per task drops 40 percent. Under cost-plus, you just cut your own revenue by roughly 40 percent on every task. You're penalized for engineering efficiency, the exact thing that should expand margin gets passed straight to the customer because your price is tethered to your cost. Andreessen Horowitz has written about how the economics of AI applications hinge on exactly this decoupling: the winners price on value created, not compute consumed, precisely so that efficiency gains accrue to them.

There's a second ceiling. A markup-on-cost model tells the customer your margin out loud. If they see you're charging cost plus 30 percent, every procurement conversation becomes a negotiation over that 30, because it's framed as your cut, not as the value of the work. You've turned a value sale into a margin audit. Value-based pricing hides the cost basis on purpose, not to deceive, but because the cost basis is irrelevant to what the outcome is worth to the buyer. A sales-development agent that books a qualified meeting is worth a slice of the deal it sources, whether that meeting took $0.11 or $1.40 of inference to produce.

The Volatility Problem You Just Inherited

Pass-through pricing quietly transfers a risk you may not want: you're now long on model-price stability. Token prices don't just fall, they move, providers deprecate the cheap model you built on, rate limits change, a reasoning model you didn't plan for becomes necessary for quality and triples your per-task spend overnight.

If you've committed to fixed per-task pricing underneath a cost-plus calculation, a mid-quarter price or behavior change from your provider can flip a task from profitable to underwater with no lever to pull. If you've committed to literal metered pass-through, you've solved your margin risk but handed the customer a bill that swings week to week, and finance teams, as anyone who's sold consumption pricing knows, hate a line item they can't forecast. Either way, anchoring price to model cost means inheriting model-cost volatility on one side of your business. The token-volatility problem doesn't go away because you passed it through; it just lands on whoever you passed it to, and they remember.

The deeper issue is that falling token prices, the thing pass-through advocates assume will help them, haven't actually lowered agent bills in practice. Cheaper tokens get spent on more reasoning, longer context, more tool calls, and more verification, the quality bar rises to consume the savings. So the "we'll get cheaper over time" comfort baked into pass-through thinking rarely materializes as margin. It materializes as a better product at roughly the same cost.

What Pass-Through Trains Your Buyer to Believe

Pricing is pedagogy. However you charge teaches the customer what kind of thing they're buying. Meter your tokens and surface the model bill, and you've taught them that your agent is a metered utility whose worth equals its compute. That's a terrible frame to be stuck in, because it invites three buyer behaviors that all compress your business:

First, substitution anxiety. If the value is the model and you're a markup on it, the buyer reasonably wonders why they don't just call the model themselves. You've advertised your own replaceability.

Second, usage suppression. When customers watch a meter, they ration. They cap autonomy, run fewer tasks, batch things to "save tokens." That's directly at odds with the expansion you need, usage-based products only work if usage expands rather than collapses, and a visible meter is a usage-collapse machine.

Third, commodity benchmarking. Once you're priced as cost-plus tokens, the buyer can compare you to any other wrapper on price-per-token, and the conversation never gets to reliability, integration depth, or outcome quality, the things you actually want to compete on.

Outcome and task-based pricing teach the opposite lesson: you're buying work done, and the price reflects what the work is worth. That frame protects the parts of your business, reliability, orchestration, domain expertise, that pass-through pricing gives away for free.

A Better Frame: Price the Outcome, Manage the COGS

The fix isn't "never look at model costs." It's to put model cost back where it belongs, in your COGS, as something you manage, not something you publish. The cloud industry learned this two decades ago: AWS doesn't bill you its electricity and rack-depreciation costs plus a markup. It prices the service and treats infrastructure cost as a margin lever to be optimized relentlessly behind the curtain. GaaS should steal that playbook.

Concretely, that means three moves:

1. Choose a pricing unit tied to value, not compute. A completed task, a verified outcome, a booked meeting, a resolved ticket. The unit should be something the customer already assigns dollar value to. Then your job is to deliver that unit for less than its price, by any cost structure you can engineer.
2. Build the unit-economics muscle internally. Know your blended cost per completed task, including retries, tools, eval, idle, and human-in-the-loop, even though the customer never sees it. This is the core unit of the category, and you cannot manage a margin you don't measure.
3. Treat model cost as a lever, not a pass-through. Caching, prompt compression, model routing, open-weight vs. frontier choices, these are how you widen the spread between price and cost. Under pass-through, every one of those optimizations leaks to the customer. Under outcome pricing, every one of them is yours to keep or to reinvest in quality.

The uncomfortable corollary: outcome pricing means you're on the hook for the cost volatility you'd otherwise pass through. That's not a bug. Absorbing and managing that risk is the business. A company that can reliably deliver an outcome at a stable price while inference costs lurch around underneath has built something genuinely valuable. A company that just adds 30 percent to whatever the model bill happens to be has built a calculator.

A Worked Example

Take a customer-support agent that resolves tickets. Naive pass-through accounting says: average ticket burns $0.18 of model tokens, add 40 percent, charge $0.25. Feels safe, every ticket is "profitable."

Now run the real numbers. The model spend is $0.18, but the agent also makes three tool calls (knowledge-base lookup, CRM read, ticket-system write) at $0.04 combined. An LLM-judge verifies the answer before sending: another $0.06. Fourteen percent of tickets fail verification and retry, adding $0.12 amortized across all tickets. Nine percent escalate to a human at $0.45 of loaded labor, or $0.04 per ticket amortized. Idle warm-pool capacity to hit the latency SLA adds $0.03. True blended cost per resolved ticket: roughly $0.47, nearly triple the $0.18 the pass-through math saw.

At a $0.25 price, that agent loses money on every ticket while its dashboard insists it's making 40 percent margin. The model bill told a comforting lie. Price the resolved ticket at, say, $1.10, anchored to the $6 to $15 it costs the company to resolve that ticket with a human, and now you have a real business with room to absorb a bad week of token prices, room to invest in cutting that retry rate, and a value story the buyer actually understands. Same agent. The only thing that changed was refusing to anchor price to the model bill.

Insights Most People Overlook

• Pass-through is most dangerous precisely when your agent is good. A thin wrapper's costs really are mostly tokens, so pass-through roughly works, and lulls founders into keeping it as the product matures and the non-token costs balloon. The pricing model that was harmless at the prototype stage becomes a margin tourniquet at scale, and the transition is invisible because no single day looks bad.

• Efficiency gains are a liability under cost-plus. This inverts normal intuition. In most businesses, getting cheaper to operate is unambiguously good. Under model-cost pass-through, every efficiency win you engineer automatically lowers your own revenue, because price is chained to cost. You are paying engineers to shrink your top line.

• The "we're just being transparent" defense is a trap dressed as a virtue. Founders justify pass-through as honest and customer-friendly. But surfacing your cost basis doesn't build trust, it relocates the entire negotiation onto your markup and teaches the buyer to optimize against your margin. Transparency about outcomes and reliability builds trust; transparency about your token bill builds a procurement adversary.

• Pass-through quietly makes you a reseller of your most replaceable input. The model is the one component of your stack the customer could plausibly buy directly. By pricing on it, you put a spotlight on the exact part of your value chain where you add the least defensible value, and you hide the orchestration and reliability work where you add the most.

• The risk you "pass through" doesn't disappear, it lands on the buyer and costs you trust later. Metered pass-through doesn't eliminate token-price volatility; it converts it into an unpredictable customer invoice. When that invoice spikes because a provider changed pricing, the customer doesn't blame the provider. They blame you, and they start looking for a vendor who'll just quote a number.

References

• The state of AI: Capturing value from generative AI, McKinsey & Company
• The Economic Case for Generative AI, Andreessen Horowitz (a16z)