Agent Economics: Pricing, Tokens, Caching, and Pods

Reading time ~18 min · Last reviewed Sep 2026 · Quiz at the end

Here is the industry's embarrassing secret, and if you've sat in a vendor pricing review in the last two years you've felt it: the same consulting firms that estimate a core-banking migration to two decimal places — story points, velocity charts, a Gantt chart with dependencies drawn to the day — cannot price an agent program within an order of magnitude. One vendor quotes $200,000 for a claims-triage agent. Another quotes $2.4 million for roughly the same scope. Both numbers came from a "proven estimation methodology." Neither vendor can tell you, with a straight face, why their number is right and the other is wrong.

This is not only a vendor competence problem. It is a category error: agent programs are priced with tools built for a different kind of work, and the mismatch produces numbers that are wrong in entirely predictable ways once you see the shape of the error.

Why phase-based estimation breaks for agents

Traditional software estimation — the kind that produces those two-decimal-place numbers — works because three things are usually true: requirements are stable enough to scope against, effort and delivered value correlate roughly linearly across thousands of prior projects, and the work proceeds through discrete milestones (design, build, test, deploy) marking real state changes. None of the three holds for a harness build the way they hold for a CRUD application or a data warehouse migration.

Requirements are not stable. You do not know how many edge cases your claims-adjudication eval set will surface until you build it, and it isn't stable until it's run against real production traffic for a few weeks — see lesson 18. A phase-gate that says "requirements sign-off, then build" assumes a scope you cannot pin down, because the real spec is discovered by running the system against messy inputs, not written down in advance.

Effort and value are weakly correlated. Two teams can spend the same three months on a support-ticket agent and produce wildly different outcomes — one resolves 40% of tickets end to end and is trusted by the org, the other is technically complete and trusted by no one because the eval bar was never defined. The delta wasn't hours worked; it was judgment about context, guardrails, and evals that a phase-based estimate has no line item for.

And the work is continuous, not milestone-delivered. A harness doesn't go from 0% to 100% done at a "go-live" milestone the way a migration does. It goes live at maybe 70% of its eventual reliability and improves every week through the loop in lesson 21 — new eval cases, retrieval fixes, guardrail tuning. Pricing this as a project that "completes" misrepresents what happens: the system keeps needing engineering attention indefinitely, at a lower but nonzero rate, for as long as it's in production.

Two paradigms, not one

The fix is not a better estimation formula. It's recognizing that agent work comes in two genuinely different economic shapes, and pricing each one on its own terms instead of forcing both through a single template.

PROJECT pricing treats the work as a scoped build with a defined outcome: build this agent, meeting this eval bar, integrated with these systems, for this price. Complexity — not hours — drives the estimate: how many integration points, how ambiguous the domain judgment is, how large the eval set needs to be to trust the result. The seller absorbs the effort risk. If it takes twice as long as estimated because the claims data was messier than anyone disclosed, that's the seller's margin problem, not the buyer's budget problem. This is the right shape for a bounded deliverable: a RAG-based knowledge assistant, a document-extraction pipeline, a first version of a triage agent.

CAPACITY pricing treats the work as a standing team — a pod — sold by composition, duration, and blended rate, not by deliverable. Team × seniority-blended rate × duration × an annual escalation factor. The buyer absorbs the scope risk: if priorities shift mid-engagement, or the eval bar turns out to require three times the guardrail work anyone expected, that's the buyer's call to make, because they're paying for capacity, not a fixed output. This is the right shape for anything that is genuinely ongoing: a multi-year platform build-out, an embedded team maintaining and extending a production harness, an agent program that will keep absorbing new workflows for years.

The doctrine here is simple and worth saying plainly: forcing a multi-year capacity engagement through a phase-based project template produces absurd numbers, and forcing a bounded three-month build through capacity pricing produces an open-ended bill for something that should have had a fixed price. Neither paradigm is superior. They answer different questions — "what will this cost to build" versus "what will it cost to staff" — and using the wrong one for the deal in front of you is where the order-of-magnitude pricing gaps come from.

A worked capacity example

Say a buyer needs a standing pod to build out and maintain an agent platform across claims, underwriting, and customer service over three years — new workflows keep getting added, so there's no fixed scope to price against. This is a textbook capacity deal. Here's how the math actually walks, using invented, round numbers for illustration.

Pod composition: 1 senior architect, 2 senior engineers, 7 mid-level engineers — 10 people total. Seniority-blended rate: the architect and seniors average $220/hour fully loaded, the mid-level engineers average $140/hour fully loaded. Blend across the pod: (3 × $220 + 7 × $140) / 10 = $164/hour blended average. At 1,800 billable hours per person per year (accounting for holidays, bench time, and non-billable overhead — a standard assumption, not a real timesheet), that's roughly $164 × 1,800 × 10 = $2.95M in year one before escalation.

Apply a 5% annual escalation — standard for a multi-year staffing commitment, covering wage inflation and retention costs — and the three years look like this:

Year 1: 10 people × 1,800 hrs × $164/hr blended           = $2,952,000
Year 2: same base × 1.05 escalation                        = $3,099,600
Year 3: same base × 1.05^2 escalation                       = $3,254,580
                                                    Total   ≈ $9,306,180

Depending on how you set the blended rate and utilization assumptions, a pod of this shape over three years lands in the $7M–$9M range — a wide but honest band, because it's driven by team composition and duration, not by a false precision about deliverables no one can specify three years out. That's the number a capacity-priced proposal should show, broken out by year, with the escalation assumption stated explicitly so the buyer can see exactly where the year-over-year growth comes from.

Now watch what happens if the same 10-person, 3-year ask gets run through a phase-based project template instead — what happens when procurement only knows how to evaluate "project" SOWs. The template decomposes the work into discovery (2 weeks), design (3 weeks), build (6 weeks), test (2 weeks), deploy (1 week), because that's the only shape it has. Someone estimates "build" at what a small team could plausibly ship in that window, and the whole exercise prices out at a 2-month, few-hundred-thousand-dollar engagement. Nobody lied. The template simply has no concept of a 10-person team sustained for 36 months — it assumes work terminates at a delivery milestone, and a standing pod has no such milestone by design. That's the absurdity the doctrine warns about: the wrong estimation tool applied to a shape of work it cannot represent.

Hybrid deals

Most real enterprise engagements aren't purely one paradigm. A common, sensible structure: a scoped RAG build — project-priced, fixed deliverable, tied to an eval gate — paired with a 4-person support pod, capacity-priced, that maintains and extends the system afterward. The project piece has a clear acceptance criterion (the eval suite from lesson 18 passes the readiness gate) and a fixed price the seller is accountable for. The support pod has no such gate, because "keep the system healthy and add workflows as the business needs them" isn't a deliverable you can fix a price to — it's the ongoing, discovery-driven work capacity pricing is built for.

Write these as two line items in one contract, not one blended number. Blending them recreates the confusion this lesson opened with: nobody can tell you what a single quarterly figure is actually paying for, because it smears a fixed-scope build and open-ended capacity into a number that answers neither "what will this cost to build" nor "what will it cost to staff."

The run-cost line

There's a third cost category that has nothing to do with labor and gets buried far too often: run-cost — the actual token spend of operating the agent, plus whatever caching infrastructure reduces it. Price this as its own line, separate from day rates or pod rates, for a reason buyers learn the hard way: per-conversation pricing compounds unpredictably. A vendor that quotes "$0.40 per resolved ticket" sounds precise, but that figure is a function of model-tier mix, prompt length, caching hit rate, and conversation length — all of which drift as scope grows and as the model provider changes pricing. A buyer who accepts per-conversation pricing as a simple abstraction should expect the bill to move in ways that don't map to volume, because it's really several variables moving at once, disguised as one number.

Separate the run-cost line and make its levers explicit:

• Token costs — input and output tokens, priced per the model vendor's current rate card, with an explicit assumption for average conversation length and how many turns require full context reassembly versus incremental additions.
• Caching strategy — prompt caching on stable context (system instructions, tool schemas, retrieved policy documents that don't change turn to turn) can cut effective input-token cost substantially. State the assumed cache hit rate and where it comes from — a stable system prompt and static retrieved context cache well; per-user personalized context does not. For agents, this is usually the biggest lever of all; see the caching section below.
• Model-tier mix — see below; the split between cheap and frontier model calls is the largest model-selection lever on run-cost (for agent workloads, caching can matter as much or more), and it should be stated as a percentage split with the assumptions that justify it.

Escalate run-cost separately from labor too. Labor escalates at wage inflation (5% a year is a defensible planning number). Token pricing has, if anything, trended down as providers compete and efficiency improves — so a run-cost line escalated at the same rate as labor is not just imprecise, it's pricing the wrong direction on one of your two biggest cost categories.

Model-tier mix as a cost lever

The same discipline from lesson 3 — models are commodities, choose by task, not brand loyalty — becomes a direct line item here. Route the high-volume, well-specified slice of the workload (classify this ticket, extract these five fields, draft a first-pass summary) to a cheap, fast model. Reserve frontier-tier calls for the failure modes that are expensive to get wrong: ambiguous intent, novel phrasing, or the "plausible but wrong" pattern where a cheaper model produces a confident, well-formatted, incorrect answer that passes a shallow review.

A rough illustrative split for a mature claims-triage harness: 70% of calls on a low-cost tier for routine extraction and classification; 25% on a mid-tier model for cases the router flags as ambiguous; 5% on a frontier tier for cases that fail a confidence check or touch a high-stakes decision (claim denial, large payout, regulatory-flagged category). That mix, not any single model's sticker price, determines your real per-conversation run-cost, and you tune it over the system's life as eval data shows where cheaper models are safe.

That the opportunity is real and large is now measurable rather than asserted. Databricks (2026) instrumented its internal AI gateway and found that about a quarter of its engineers' real agent tasks were low-complexity and roughly sixty percent medium-complexity — yet engineers defaulted to the most expensive models for nearly all of it. That is the concrete size of the tier-routing prize: some eighty-five percent of the workload was, by the organization's own telemetry, a candidate to run on cheaper tiers, and almost none of it did. When you set the percentage split in your run-cost line, this is the empirical warrant for pushing the low- and medium-complexity slices down aggressively rather than leaving them on the frontier default out of habit.

Per-task cost, not per-token cost

The most expensive mistake in a run-cost model is to estimate it from the vendor's per-token rate card, because per-token price is a poor predictor of per-task cost. The two come apart whenever a cheaper-per-token model compensates by reading more and working longer. Databricks (2026) gives the canonical illustration: Sonnet 5 is about 1.7x cheaper per token than Opus 4.8, but on their real tasks Sonnet cost $2.09 per task against Opus's $1.94 — more expensive per finished task, while scoring six points lower on quality (81% versus 87%) — because Sonnet worked longer and consumed 1.9x more tokens end to end. A run-cost line built by multiplying a per-token rate by an assumed conversation length would have predicted the opposite ranking. The only way to see the real number is to benchmark candidate models at the task level, on a sample of your own workload distribution, exactly as the eval suite from lesson 18 lets you do.

Go one step further and divide by success. The unit that matters is cost per successful task: total spend on a batch of tasks, including the failed and abandoned attempts, divided by the number that actually met the bar. A cheap run that fails is not cheap; it is pure waste plus the cost of whoever redoes the work. "Prompt-Induced Waste in Coding Agents" (2026) makes this the explicit efficiency metric and argues that token and cache counts are measurements of the trajectory, not targets to optimize on their own. Its controlled experiments show why the distinction matters. Prompt wording alone changed how much agents reasoned and re-verified without changing the task: instructions to consider multiple approaches multiplied reasoning tokens by 2.4 to 7.4 times across six open models with no credible gain in success. Runs with heavily redundant verification cost many times the clean-run median. The paper also found that prompt, effort, and harness interact, so an efficiency fix measured under one harness can shrink or grow under another. Track cost per successful task on your own workload, and re-measure it whenever the harness changes.

The harness is a run-cost lever too

Most cost models stop at model choice and tier mix, and in doing so they miss a lever that moves cost as hard as the model does: the harness itself. This is the run-cost analogue of the argument the rest of this course makes about capability — the harness, not just the model, determines the outcome. Databricks (2026) ran the same model at the same thinking effort through different harnesses and saw cost per task differ by more than 2x with quality unchanged. The driver was how much context each harness fed per turn: a leaner harness sent roughly 3x less context per turn, kept a tighter working set, and finished the tasks in fewer runs. Same model, same quality, half the bill — decided entirely by the scaffolding. When you audit a run-cost line, the tier mix is the first lever but not the last; how the harness manages context per turn belongs in the same conversation, because a wasteful harness can quietly double your token spend while the pricing page and the model choice both look correct.

Caching: the dominant run-cost lever for agents

If you remember one thing about agent run-cost, make it this: for most agent workloads, the price you pay for input tokens, and how many of them hit the cache, matters more than the model's output price or even its headline per-token rate. The reason is structural, and it follows from how the loop in lesson 4 works.

Why agents are input-heavy

A chatbot turn sends a prompt and gets a sizable answer back. An agent step sends the whole working context again: system prompt, tool definitions, the task, and every prior tool call and result, then receives a short reply, usually one tool call. The next step sends all of that again plus the latest result. Input grows with every step and is re-sent every step; output stays small. Manus reported an average input-to-output ratio of about 100:1 in its agent and called KV-cache hit rate "the single most important metric" for a production agent (Manus, 2025). Providers that support prompt caching bill a request's cached prefix at a steep discount to fresh input, so an agent re-sending an unchanged prefix thirty times pays full price once and the discounted rate after, provided the prefix really is unchanged.

Cache-hit rate as a KPI

That "provided" is where harnesses win or lose money. Put cache-hit rate (cached input tokens divided by total input tokens, per task and per day) on the run-cost dashboard next to cost per successful task. The two answer different questions. Cost per successful task tells you whether the system is worth running. Cache-hit rate tells you whether the harness is wasting money on a given workload, and it moves the moment someone ships a change that disturbs the prefix, often days before the invoice shows it. A sudden drop in hit rate after a harness release is a regression, and should be treated like one.

Harness choices that make or break hit rates

Prompt caches match on an exact prefix. Any change to an early token invalidates everything after it. That turns a handful of harness design choices into cost decisions (the mechanics are in lesson 6):

• Stable prefix. Nothing that changes per request goes near the top: no timestamps, request IDs, or per-user fields in the system prompt. Put volatile material at the end.
• Append-only history. Add new events at the end rather than editing, reordering, or re-summarizing earlier turns on every step. Compaction is sometimes necessary, but each compaction is a deliberate cache reset; do it rarely and on purpose, not as a side effect.
• Deterministic tool ordering and serialization. If the tool list or JSON key order shifts between requests, the prefix changes even though nothing meaningful did. The MCP 2026-07-28 revision now says servers should return tools/list in a deterministic order, explicitly to improve prompt-cache hit rates.
• Stable tool set. Adding or removing tools mid-session rewrites the tool block. Prefer keeping the set fixed and constraining which tools may be used.
• Cache lifetime. Cached prefixes expire after a period of inactivity. Long pauses, human approvals, and background waits can quietly turn every resume into a cold start. Know your provider's cache lifetime and whether writing to the cache costs extra.

A worked example (hypothetical prices)

The prices below are invented round numbers chosen to make the arithmetic clear. They are not any vendor's rates; substitute your provider's current pricing page. Assume fresh input at $2.00 per million tokens, cached input at $0.20 per million, and output at $10.00 per million. Take a 30-step coding task with a 12,000-token prefix (system prompt plus tools) where each step appends about 2,000 tokens of tool output and model reply, and the model emits about 500 output tokens per step.

HYPOTHETICAL prices: fresh input $2.00/M, cached input $0.20/M, output $10.00/M

Input sent over 30 steps  = sum(12,000 + 2,000*i for i in 0..29) = 1,230,000 tokens
Output over 30 steps      = 30 * 500                                  =    15,000 tokens
Input : output ratio      ~ 82 : 1

Best case, append-only: only the new tokens each step are uncached
  uncached = 12,000 + 29 * 2,000 = 70,000   -> hit rate ~94%

                      hit rate   input cost   output cost   per task   per success (80%)
No caching               0%        $2.46        $0.15        $2.61        $3.26
Churning prefix         70%        $0.91        $0.15        $1.06        $1.33
Append-only, stable     94%        $0.37        $0.15        $0.52        $0.65

Three things jump out. Output, the line most people look at on a price sheet, is a small part of the bill. Going from 70% to 94% hit rate halves cost per task with the same model, prompt, and success rate. And the gap between a harness that caches well and one that doesn't is bigger than the gap between many model tiers. Divide by success rate as well: if a cache-hostile change also makes the agent slower or more confused, cost per successful task gets worse on both counts.

Evidence that the harness drives cache variance

This isn't only arithmetic. Claw-SWE-Bench (2026) ran five agent harnesses on the same coding benchmark under fixed prompts and budgets and reported cache-hit rates alongside accuracy. With the GLM 5.1 model held constant, hit rates ranged from 66.8% to 96.5% depending on the harness; with Qwen 3.6-flash, from 63.9% to 97.6%. The authors conclude that systems with similar accuracy can differ substantially in total API cost, and that cost accounting should be a first-class axis of agent evaluation. Harness-level measurements of DeepSeek's API point the same way: community tests reported prefix-cache hit rates above 99.9% for a lean open harness on DeepSeek V4 Flash, per 36Kr's coverage (2026). Treat that figure as secondary and workload-specific. The mechanism, a harness built around an append-only log and a stable prefix, is covered in lesson 23.

Reasoning effort is a cost dial

Many current models expose a reasoning-effort setting, and it belongs in the run-cost model as a named variable, not a hidden default. DeepSeek's V4 general-availability release, for example, offers effort levels described as low for simple tasks, high for daily agent workflows, and max for complex ones (DeepSeek, 2026). Higher effort generally means more thinking tokens and more latency per step. Whether it buys enough extra success to pay for itself depends on the task: the waste study above found extra effort can help on hard tasks and add cost with no benefit on easy ones, and that the same effort control cut cost far more under one harness than under another.

The dial cuts both ways. Anthropic's April 2026 Claude Code postmortem describes lowering the default effort from high to medium to fix latency complaints; users then reported the product felt less intelligent, and the change was reverted about a month later. The same postmortem describes a context-clearing bug that also caused cache misses, burning through usage faster. The lesson for a cost model: effort and caching settings are product decisions with quality consequences. Set effort per task class (low for routing and extraction, higher for the ambiguous slice your tier mix already sends to stronger models), measure cost per successful task at each setting, and ship changes to defaults through the same eval gate as any other harness release.

Unit economics for the buyer

None of this pricing exercise matters if the buyer can't answer the only question that determines whether the program is worth running: cost per resolved ticket, or per processed claim, measured against the human baseline — not against zero.

A vendor proposal that says "$0.60 per ticket resolved by the agent" sounds cheap until you ask what it's compared to. If a human resolves the same ticket at a fully loaded cost of $4.50, the agent wins clearly even after the run-cost line, amortized pod cost, and residual human review. If the human baseline is actually $0.80 because the ticket type is already automated with simple rules, the agent program may not clear its own cost, no matter how elegant the harness.

Build this comparison into every proposal and every quarterly review. It's the only number that answers "was this worth it," and it forces the run-cost and pod-cost lines to be stated honestly, since they have to sum to something comparable against a real baseline instead of floating as an abstract cost center.

A buyer's checklist

Whatever the vendor's slide deck says, demand these five things be explicit in any agent proposal before you sign:

• Pricing paradigm named. Is this PROJECT (fixed deliverable, seller absorbs effort risk) or CAPACITY (team and duration, buyer absorbs scope risk)? If the proposal won't say, it's probably hiding a mismatch between the deal's real shape and its pricing structure.
• Run-cost separated. Token cost, caching assumptions, and model-tier mix broken out as their own line, with their own escalation assumption — not buried inside a day rate or a per-conversation number you can't audit.
• Eval gate defined. What specific, numeric bar (from lesson 18) does the system have to clear before it's considered "done" (for a project) or before scope expands (for a capacity engagement)?
• Rollback priced. What does it cost, in time and money, to disable the agent and revert to the human process if it fails to meet the eval bar in production? If the proposal has no answer, the vendor hasn't planned for failure, which means you're the one who'll improvise it.
• Telemetry ownership stated. Who owns the logs, the eval results, and the cost data after the engagement ends? If the vendor owns the telemetry, you cannot audit your own system's performance without going back to them — which is a lock-in risk dressed up as a convenience.