The strategist who owns agent FinOps at company scale is asked one question more than any other, by every CFO, every quarterly review, every board deck: "What does a run cost us?" The honest answer is not a single number. It is a decomposition. A customer-service agent run at one company costs $0.04 and at another $1.80 — same model family, same vendor, same conversation length. The difference is not magic; it is the five components nobody itemizes. This lesson decomposes cost-per-run into its actual constituent parts: model tokens, retrieval, tool latency, human review, and overhead. It then locates the lever that actually moves the number — usually one of those five dominates, and it is rarely the one the team is optimizing. By the end you will have a unit-economics worksheet you can run against any agent in your portfolio in 30 minutes, a defensible cost-per-run number to bring to budget season, and the discipline to stop accepting "about $0.10 per run, give or take" as an answer.

Why Strategists Need a Different Cost Model Than Builders

Builders think about cost per call. Strategists think about cost per resolved unit of business value. The difference is enormous. A call is one round-trip to a model API; a resolved unit might be 14 calls plus three tool invocations plus 90 seconds of human review. The builder's $0.012 per call becomes the strategist's $0.42 per resolved ticket. When the CFO asks "what does a run cost," the builder's answer is incomplete and the strategist's answer is the one that decides budget.

The unit you optimize is the unit you measure. A team that measures cost per call optimizes call cost — and ships an agent that calls the model 14 times because each call is cheap. A team that measures cost per resolved ticket optimizes for fewer calls per ticket. Same model, same vendor, very different bill. This is the FinOps insight applied to agents: the metric you publish is the metric you get.

The cost-per-run number that survives a budget meeting is decomposed, time-phased, and tied to a business outcome. The number that does not survive is the one labeled "about ten cents." CFOs do not approve programs on "about."

Strategist FinOps is not a spreadsheet exercise. It is an operating discipline. You publish the cost-per-run for each agent in your portfolio every month, with the same five-component breakdown, the same denominator definition, and the same confidence band. Drift in any component triggers a review. Surprises do not happen in November; they happen in February when the monthly number ticks 30% upward and somebody asks why.

The Five Components of Cost-per-Run

Every agent run, regardless of vendor or platform, decomposes into five components. The proportions change wildly; the components do not.

1. Model tokens. Input tokens (prompt, system, history) plus output tokens, priced per million. The line everyone obsesses about, often not the largest.
2. Retrieval. Vector database queries, embedding API calls, search infrastructure. Includes the cost of getting context into the prompt before the model sees it.
3. Tool latency. The cost of calling external APIs, waiting for them, paying for them. Stripe API calls, Salesforce reads, internal databases. Latency translates to cost because the LLM holds context while waiting.
4. Human review. The labor cost of any human-in-the-loop step: approval queues, edge-case escalations, quality sampling. Almost always larger than tokens at moderate volume.
5. Overhead. Observability, gateway fees, eval-as-judge, logging, security scanning, the proxy layer. The portion of fixed-platform cost amortized per run.

For a worked example, take a tier-1 customer service agent processing 200,000 tickets per month using Claude Sonnet 4.5 via a LiteLLM gateway with human review on 8% of outputs.

• Model tokens: 4,200 input + 600 output per ticket = ~$0.022/ticket at Sonnet 4.5 pricing
• Retrieval: 3 vector queries at $0.00012 each + embedding cost $0.0008 = $0.00116/ticket
• Tool latency: 2 Salesforce reads (free), 1 Zendesk write (free), but 4.2s average latency cost in held context = $0.005/ticket effective
• Human review: 8% sample x $1.20 per reviewed ticket = $0.096/ticket amortized
• Overhead: Helicone proxy + Datadog traces + LangSmith judge eval = $0.011/ticket amortized

Total: $0.135/ticket. Of which model tokens are 16%, human review is 71%, overhead is 8%, retrieval is under 1%, latency is 4%. The team has been spending six weeks optimizing token prompts (which is 16% of cost) while completely ignoring the human review step (which is 71% of cost). That is the lesson. Decomposition surfaces the lever.

Component One: Model Tokens — The Line Everyone Obsesses Over

Model tokens are the easiest line to model because vendors publish prices. As of May 2026 the relevant numbers on the strategist's wall:

• Claude Sonnet 4.5: $3 input / $15 output per million tokens (the workhorse for serious reasoning)
• Claude Haiku 4: $0.80 input / $4 output per million tokens (the cheap-fast tier)
• GPT-5: $5 input / $15 output per million tokens (frontier reasoning)
• GPT-4o-mini: $0.15 input / $0.60 output per million tokens (the routing tier)
• Gemini 2.5 Pro: $1.25 input / $10 output per million tokens (cost-competitive frontier)
• Gemini 2.5 Flash: $0.30 input / $2.50 output per million tokens (the high-context cheap option)

The strategist's question is not "which is cheapest" but "what is the input:output ratio for our workload?" Most agent runs are input-heavy: 4-8x more input than output tokens once you count system prompt, history, and retrieval. For an input-heavy workload, Gemini 2.5 Flash or Claude Haiku 4 are dramatically cheaper than their reasoning counterparts. For an output-heavy workload (code generation, long-form writing), the input:output gap matters less.

The three multipliers nobody models

• Retry overhead. Agents in real production retry. The model misformats output, the parser rejects it, the agent runs again. Empirically 20-40% of runs retry at least once on a non-trivial agent. Budget 1.3-1.5x the point-estimate token cost.
• Context bloat. Multi-turn conversations accumulate. The first turn is 4,000 tokens; the tenth turn is 11,000. If your agent supports sessions, multiply estimated tokens by 1.4-2.0x depending on average turn count.
• Model upgrade tax. Your team will move to the smarter, more expensive model in 12 months. Always. Plan for 25-40% per-call cost increase across the planning horizon as model SKUs evolve.

Component Two: Retrieval — The Line That Grows Quietly

Retrieval cost is the line that quietly grows from "negligible" to "the second biggest line item" as your knowledge base expands. The three sub-components.

• Embedding cost. Every retrieved chunk had to be embedded once (corpus indexing) and every query has to be embedded at runtime. OpenAI text-embedding-3-large at $0.13 per million tokens, Voyage 3 at $0.18, Cohere Embed 4 at $0.10. For a 100K-document corpus re-indexed quarterly: $200-$800 per re-index. For 200K queries/month: $30-$60/month query-embedding cost.
• Vector database queries. Pinecone at $0.0008 per query (serverless), Weaviate self-hosted at near-zero per query but $400-$1500/month infrastructure, Turbopuffer at $0.0001 per query (the 2026 cheap-tier winner). For 200K queries x 3 retrievals/query = 600K queries/month at $0.0001 = $60/month. At $0.0008 = $480/month.
• Reranking. A reranker (Cohere Rerank 3.5 at $2 per 1000 searches) running over 20 retrieved chunks adds $0.002 per query. Often skipped to save cost; sometimes critical for quality.

The retrieval line is small per-run but grows nonlinearly with corpus size. A 10x growth in corpus doesn't 10x the query cost (it stays roughly flat per query), but it 10x's the re-indexing cost and meaningfully extends query latency, which adds tool-latency cost downstream. Watch the corpus-growth rate, not just the per-query line.

Component Three: Tool Latency — The Line That's Actually Time

Tool latency is the line nobody puts in their spreadsheet because it doesn't have an invoice. There is no monthly bill for "Salesforce read latency." But it is a real cost, and at scale it dominates.

The mechanic: an agent calls a tool (Salesforce API, internal database, external pricing API). While that tool runs, the LLM is either (a) holding context open and paying for it on the running clock, or (b) being re-invoked with new context, paying the input tokens again, or (c) keeping a human waiting, which extends the human-review window. All three have cost. The third one — keeping the human waiting — is the largest at moderate volume because human time is the most expensive resource in the loop.

Modeling tool latency cost

For each tool call, estimate:

• Latency in seconds. P50 and P95. Salesforce reads typically 800ms P50, 3.5s P95. Internal database 200ms P50, 1.2s P95. External pricing API 1.4s P50, 8s P95. The P95 matters because agents wait for the slowest, not the average.
• Cost per second of latency. If the agent has a human in the loop, latency translates directly to human idle time at the loaded labor rate ($45-$90/hour = $0.012-$0.025 per second). If the agent runs unattended, latency is opportunity cost (throughput reduction) rather than direct cost.
• Calls per run. Agents typically make 2-8 tool calls per resolution. Multiply.

Worked: agent with 4 tool calls per run, P50 sum of 4.8s, with 8% human review at $0.018/second equivalent. Per-run latency cost = 4.8 * $0.018 * 0.08 amortized + opportunity cost on the 92% = roughly $0.005 amortized for direct cost plus throughput effects. The number looks small per run; multiplied across 200K runs/month at scale it is $1K direct and meaningful in throughput.

The lever here is not "make tools faster" — your enterprise systems are what they are. The lever is parallelizing tool calls, caching tool responses, and choosing tools with lower P95 latency. A single tool with 8-second P95 latency dominates the cost line. Replace or wrap it.

Component Four: Human Review — The Line That Actually Dominates

Human review is the line that dominates total cost-per-run for almost every regulated, customer-facing, or financially-material agent. It is also the line teams forget because the human is "already on payroll" and "doesn't show up in the OpenAI invoice."

The mechanics. Three review patterns each with different cost shapes.

Approval-queue review (every output goes to human)

Every agent output is reviewed by a human before action. The agent is a drafter; the human is the decider. Per-review time: 30 seconds to 4 minutes depending on complexity. At a loaded labor rate of $60/hour: $0.50-$4.00 per review. For an agent processing 50K items/month with full review: $25K-$200K/month in review labor. Often the dominant cost line.

Stratified-sample review (X% of outputs reviewed)

A representative sample (typically 5-15%) is reviewed by humans for quality monitoring. The other 85-95% go straight through. Per-run amortized cost = sample rate * per-review cost. At 8% sample x $1.20 = $0.096 amortized per run.

Escalation-trigger review (only flagged items reviewed)

The agent self-flags uncertain cases (confidence below threshold, novel input type, edge-case detector fires). Only flagged items go to humans. Typically 3-8% trigger rate at $1-$3 per review = $0.03-$0.24 per run amortized. The cheapest pattern but requires good uncertainty calibration.

The strategist question: which review pattern matches the blast radius and the audit requirement? For an HR or financial-decision agent, full approval is the answer regardless of cost. For a knowledge-base agent answering FAQs, escalation-trigger with 4% trigger is the answer. The cost of human review is whatever the risk profile demands; the lever is choosing the right pattern, not bargaining the cost down.

Component Five: Overhead — The Line That's Amortized

Overhead is the fixed-cost portion of your agent stack divided across runs. The components.

• Gateway/proxy: Helicone, LiteLLM, Portkey at $300-$5,000/month at moderate-to-high scale.
• Observability: LangSmith Pro at $1,000-$10,000/month, Langfuse Cloud at similar, Datadog APM allocation $500-$3,000.
• LLM-as-judge: Eval suite running continuously, scoring outputs. $200-$2,000/month token spend depending on judge model and sample rate.
• Logging and storage: Trace storage in S3, replay infrastructure. $200-$1,500/month.
• Security/compliance scanning: Prompt-injection detection (Lakera Guard, Promptfoo), PII redaction. $500-$3,000/month.

For a moderate-scale agent (200K runs/month): roughly $5,000/month overhead = $0.025/run amortized. At higher scale this number drops sharply per-run; at lower scale it dominates. A 5K-run/month agent with $4,000/month overhead is paying $0.80/run just in overhead. Volume matters.

Finding the Actual Lever

Once you have the five-component decomposition, the actual lever is the largest line. This sounds obvious; in practice teams optimize the wrong line constantly. The pattern:

• Team A's agent costs $0.135/run, of which 71% is human review. They spend 6 weeks shaving 18% off token cost (which moves the total by 3%). The lever was reducing review sample rate or improving uncertainty calibration to switch from stratified to escalation-trigger review.
• Team B's agent costs $0.42/run, of which 60% is tokens because they're calling Claude Sonnet 4.5 for every routing decision. They spend three months building a custom eval harness. The lever was tiering: route the 70% easy cases to Haiku 4 (3.75x cheaper) and reserve Sonnet for the hard 30%.
• Team C's agent costs $1.80/run for a low-volume internal research agent, of which 65% is overhead because they're paying for the same Helicone/Datadog/Langfuse stack at 4K runs/month that everyone else amortizes over 200K. The lever was either consolidating onto a shared platform or accepting that the agent is too low-volume to justify enterprise observability.

The decomposition tells you the lever. The lever is almost never the line the team has been working on. That is because cost shows up most where attention is least. Tokens get attention because they have an invoice; human review doesn't get attention because the reviewers are already on payroll. Overhead doesn't get attention because the proxy was set up two years ago and no one revisits it.

The 30-Minute Unit-Economics Worksheet

For each agent in your portfolio, fill this out. Should take 30 minutes if your gateway has decent reporting.

1. Define the unit. Cost per resolved ticket? Cost per generated draft? Cost per completed research query? Pick one. Write it down. Every other number is relative to this denominator.
2. Pull monthly volume. How many of the defined unit did this agent produce last month? From your gateway logs or platform analytics.
3. Pull monthly model spend. Total token cost from gateway (Helicone, LiteLLM dashboard, OpenAI usage page). Divide by volume.
4. Pull monthly retrieval spend. Vector DB bill + embedding API calls. Divide by volume.
5. Estimate monthly tool latency cost. Average tool calls per run x weighted latency x human-attended fraction x loaded labor rate. Or use throughput-cost proxy.
6. Pull monthly human review labor. Reviewer headcount x % of time on this agent x loaded labor rate. Or for sampled review: sample count x per-review minutes x loaded rate.
7. Allocate overhead. Total platform/gateway/observability/security spend in the period x this agent's share of total runs. Divide by volume.
8. Sum and decompose. The total is your cost-per-unit. The percentages tell you the lever.

Publish the worksheet monthly. Same agent, same denominator, same five components. Watch the components for drift. When a component moves more than 20% month-over-month, dig in.

The Cost-per-Run Numbers You Should Recognize

For sanity-checking your decomposition against industry baselines as of May 2026:

• Customer service agent (tier-1, automated resolution): $0.08-$0.18 per resolution. Tokens 15-30%, human review 50-70%, rest split.
• Knowledge/research agent (internal Q&A): $0.04-$0.12 per query. Tokens 35-50%, retrieval 15-25%, overhead 20-30% (low volume), human review 5-15%.
• Sales-enablement agent (draft + research): $0.25-$0.80 per artifact. Tokens 25-35%, retrieval 10-15%, human review 40-55%, overhead small.
• Code-generation agent (PR-level): $0.40-$2.50 per task. Tokens 60-80%, tool latency 10-15%, human review variable.
• Voice agent (per-minute): $0.06-$0.18 per minute fully loaded. Inference + STT + TTS dominate; review is async sampling.

If your number is dramatically different from these ranges, either you have found genuine efficiency or you are mismeasuring. Audit the denominator first.

When the Cost-per-Run Number Is the Wrong Metric

Cost-per-run is the right metric for agents with linear-to-volume cost shape. It is the wrong metric for two cases.

First: agents where the dominant cost is fixed (low-volume internal agents amortizing a fixed platform). For these, the relevant metric is total monthly cost compared to the value delivered, not cost-per-run. A research agent that costs $4,000/month and saves three analysts 8 hours/week is a clear win regardless of whether per-run cost is $0.80 or $8.

Second: agents where the cost is dominated by upstream-system constraints (a customer-service agent whose human-review cost is set by SLA, not by efficiency). For these, focus on the count of escalations, not cost per resolution. The cost moves when escalation rate moves, not when token prices move.

The strategist's job is to know which metric matches which agent. A portfolio dashboard that publishes cost-per-run for every agent — even where it's not the right primary metric — is information-poor. A dashboard that publishes the right metric for each agent class is what the CFO will trust.

Key Takeaways

• Builders measure cost per call; strategists measure cost per resolved unit of business value. Same agent, very different numbers — and the metric you publish is the metric you get.
• Every agent run decomposes into five components: model tokens, retrieval, tool latency, human review, and overhead. The proportions change wildly between agents; the components do not.
• For most regulated or customer-facing agents at moderate volume, human review is the dominant cost line — often 50-70% of total. Teams that obsess over the 15-25% token line are optimizing the wrong lever.
• Model tokens have three multipliers nobody models: retry overhead (1.3-1.5x), context bloat (1.4-2.0x on multi-turn), and the model upgrade tax (25-40% per-call increase in 12 months).
• Retrieval cost is small per-run but grows nonlinearly with corpus size and queries-per-run. Re-indexing cost dominates the embedding line; query cost is usually small.
• Tool latency is an invisible cost because it has no invoice. It shows up as human idle time or throughput reduction. Model it explicitly; the lever is parallelization, caching, and replacing high-P95 tools.
• Overhead is fixed-ish and amortized — dominant at low volume, negligible at scale. A 5K-run agent paying enterprise observability is paying $0.80/run in overhead alone.
• The decomposition surfaces the actual lever. The lever is almost never the line the team has been working on, because cost shows up most where attention is least.
• Industry baselines for sanity: $0.08-$0.18 per customer-service resolution, $0.04-$0.12 per research query, $0.25-$0.80 per sales artifact, $0.40-$2.50 per code task. Dramatic deviations mean either genuine efficiency or measurement error — audit the denominator first.
• Publish the worksheet monthly with the same five-component breakdown. Drift over 20% in any component triggers review. Surprises do not happen in budget season; they happen in the month nobody looked.