Agent Cost Governance: What State of FinOps 2026 Says About Your Token Bill

On February 19, 2026, the FinOps Foundation released its sixth annual State of FinOps survey: 1,192 practitioners representing more than 83 billion dollars in annual cloud spend, of whom 98 percent said they now manage AI spend. That figure was 63 percent in 2025 and just 31 percent in 2024, and the same survey names AI cost management the most in-demand skill in the discipline (FinOps Foundation, February 19, 2026). Going from under a third to nearly everyone in two years tells you what kind of problem this is. AI spend stopped being a technical line item and became a governance one. Meanwhile something else is happening: per-token prices keep falling, and agent invoices keep climbing.

Bill by decision, not by token

1. Why Cheaper Tokens Cost More

The answer is in the multiplication: your bill is roughly price per token multiplied by tokens per decision. The first factor really has been falling. The second has exploded because of architecture. A conversational request might consume a few thousand tokens. A coding agent fixing one bug reads the repository, explores failure paths, and iterates on a patch, which can mean hundreds of thousands of input tokens - most of which already appeared in the previous turn. That is why successful price negotiations coexist with doubled monthly bills. To control the number, change the unit of account from tokens to decisions.

# ledger.py - bill by decision, not by token
def record(decision_id, task, model, usage, usd):
    return {
        "decision_id": decision_id,          # one business decision
        "task_family": task,                 # bug_fix | triage | research
        "model": model,
        "input_tokens": usage.input_tokens,
        "cached_input_tokens": usage.cache_read_input_tokens,
        "output_tokens": usage.output_tokens,
        "cost_usd": round(usd, 6),
        "cost_per_decision": None,           # filled at decision close
    }

# "Tokens per month" cannot be argued with in a review meeting.
# "7.4 cents per triaged ticket" can.

Cache the stable prefix, not the question

2. Put the Caps at the Gateway

In its September 2, 2026 press release, Boomi describes cost governance and governance side by side: per-agent rate limits and financial caps, real-time tracking of usage, performance, and token consumption for all active agents, so teams can identify high-performing workloads, flag agents consuming excess tokens without results, and reallocate budget before unmonitored calls cause financial surprises. The engineering reading is blunt: caps have to fire before the call, not after the invoice. A per-call ceiling, a per-agent daily budget, and a per-minute call limit cover most of the exposure.

# assembly.py - cache the stable prefix, never the question
STABLE_SYSTEM = load("prompts/system.md")        # tens of thousands of tokens
TOOLS = load("prompts/tools.json")

def build(question: str):
    return {
        "model": MODEL,
        "cache_control": {"type": "ephemeral"},   # automatic caching
        "system": [{"type": "text", "text": STABLE_SYSTEM,
                    "cache_control": {"type": "ephemeral"}}],
        "tools": TOOLS,
        "messages": [{"role": "user", "content": question}],
    }

# Order matters. Cache breakpoints go on stable prefixes; put volatile
# content (today's ticket, fresh search results) after them.
# Changing tools, images, or thinking settings invalidates the cache.

Three numbers, every week

3. Caching Is the One Lever That Changes Magnitude

Anthropic's prompt caching documentation lays out the pricing structure clearly: 5-minute cache writes cost 25 percent more than base input tokens, 1-hour cache writes cost twice base input, and cache hits are billed at a fraction of base input. You can define up to 4 cache breakpoints, and cached prefixes expire after a minimum of 5 minutes of inactivity (Anthropic docs, Prompt caching). Order is the whole trick: put the stable system prompt, tool definitions, and standards documents first with breakpoints attached, and volatile content after them. The same documentation notes that changing thinking parameters, images, or tool-use settings invalidates the cache - which is why many teams enable caching and still save nothing.

-- cache_hit.sql - is caching actually working?
SELECT date_trunc('day', ts)                                  AS day,
       model,
       SUM(cache_read_input_tokens)                           AS cached_in,
       SUM(input_tokens)                                      AS fresh_in,
       ROUND(100 * SUM(cache_read_input_tokens)
             / NULLIF(SUM(input_tokens + cache_read_input_tokens), 0), 1)
                                                              AS cache_hit_pct,
       SUM(cost_usd)                                          AS spend
FROM llm_calls
GROUP BY 1, 2
ORDER BY 1 DESC;

-- Watch two things: the hit percentage, and whether spend fell when it rose.
-- A rising hit rate with flat spend means your volatile prefix is wrong.

4. Observability: Three Numbers You Must Watch

The first is cache hit rate, computable from cache_read_input_tokens and cache_creation_input_tokens in the response. Track only totals and you will see the bill move without knowing why. The second is cost per decision, grouped by task family, because a monthly lump sum cannot be attributed to any team. The third is decisions that produced no artifact: calls that consumed budget and left behind nothing reusable. Those are usually not failures but prompt or tool design problems. Together the three turn a vague complaint about expensive AI into a specific statement about which kind of decision is expensive and why.

# guard.py - the controls that actually stop a runaway agent
LIMITS = {
    "per_call_max_usd": 0.50,        # a single call should never be large
    "per_agent_day_usd": 75.00,      # hard financial cap per agent
    "per_agent_day_tokens": 2_000_000,
    "per_agent_calls_per_min": 60,
}

def preflight(agent, estimate):
    if estimate > LIMITS["per_call_max_usd"]:
        return {"decision": "reject", "reason": "estimate over per-call cap"}
    if spend_today(agent) + estimate > LIMITS["per_agent_day_usd"]:
        return {"decision": "halt", "reason": "daily cap reached"}
    if rate_ok(agent) is False:
        return {"decision": "throttle", "reason": "rate limited"}
    return {"decision": "allow"}

# Caps, quotas, and throttles. Boring infra; the reason a large agent
# programme does not become a large surprise.

5. Five Snippets You Can Ship This Week

First, a decision-level ledger that records model, input and output tokens, cached input tokens, and cost per call, then fills in cost per decision when the decision closes (code 1). Second, prompt assembly that marks the stable prefix for caching and puts volatile content after it (code 2). Third, a cache hit rate query (code 3). Fourth, gateway guardrails: per-call ceiling, daily budget, rate limit (code 4). Fifth, the weekly review query that reports decisions, spend, cost per decision, and cache hit rate by task family (code 5). It is under a hundred lines of code, and it decides whether next month's invoice is explainable.

-- weekly_finops.sql - the review, in one query
WITH base AS (
  SELECT task_family,
         COUNT(*)                       AS decisions,
         SUM(cost_usd)                  AS spend,
         SUM(cost_usd) / COUNT(*)       AS cost_per_decision,
         SUM(cache_read_input_tokens)
           / NULLIF(SUM(input_tokens + cache_read_input_tokens), 0) AS cache_hit_pct
  FROM agent_decisions
  WHERE decided_at >= CURRENT_DATE - INTERVAL '7 days'
  GROUP BY 1
)
SELECT task_family,
       decisions,
       ROUND(spend, 2)                     AS spend_usd,
       ROUND(cost_per_decision, 4)         AS usd_per_decision,
       ROUND(100 * cache_hit_pct, 1)       AS cache_hit_pct
FROM base
ORDER BY spend_usd DESC;

-- Bring three things to the meeting: cost_per_decision by family,
-- cache hit rate, and the list of decisions that produced no artifact.

6. Three Numbers for the Weekly Review

Bring three numbers to the meeting: cost per decision by task family, cache hit rate, and the list of zero-artifact decisions. Then ask three questions. Which task family's unit cost is rising, and is it because prompts grew or retrieval widened? Where did the hit rate fall, and who added volatile content ahead of the stable prefix? Which task types dominate zero-artifact decisions, and should those be fixed with better prompts, better tools, or switched off entirely? None of this requires procurement. It requires instrumentation and one accountable owner. Cost governance without an owner always degrades into end-of-month surprise.