The pattern repeats almost word for word. A team ships an AI feature, everyone loves it, adoption climbs - and four months later the finance lead forwards an invoice with a subject line containing the word "urgent". Nothing broke. The feature simply worked, and nobody had modelled what working would cost.
Why AI spend breaks classic FinOps
Traditional cloud FinOps assumes cost tracks provisioned capacity: instances, storage, egress. You can see it, cap it, and reserve it. Model spend behaves differently in three ways that break those instincts.
- It is demand-driven, not capacity-driven. Cost scales with user behaviour and prompt length, not with anything you provisioned last quarter.
- It is non-deterministic. The same request can cost 3x more on Tuesday because the model chose a longer answer or an agent took two extra tool calls.
- It hides behind a single API key. One key, one invoice, no idea which feature, customer or team caused what.
Agentic workloads make all three worse. An agent that retries, reflects and calls tools in a loop can consume fifty times the tokens of a single chat completion for the same user action - and it does so silently.
You do not have an AI cost problem. You have an AI attribution problem that becomes a cost problem the moment usage grows.
Start with cost per successful outcome
Cost per token is a vanity metric. It tells you nothing about whether the feature earns its keep. The number that matters is cost per successful outcome: per resolved support ticket, per drafted proposal, per qualified lead, per reconciled invoice.
Compute it honestly. Take total model spend for a feature over a month, divide by the number of outcomes the business actually accepted - not the number of requests. If your support assistant resolves 60% of conversations and the rest escalate, the escalated ones still cost money, and they belong in the denominator's numerator, so to speak. Most teams discover their real cost per outcome is two to four times what the naive calculation suggested.
Then set a target. A support deflection worth $9 of human handling time can justify perhaps $0.40 of model spend. A sales email draft that saves four minutes justifies far less. Writing that number down changes engineering behaviour more than any dashboard.
Tagging, attribution and the telemetry you need
Route every model call through one internal gateway. Not because the gateway is clever, but because it is the only place you can capture consistent metadata. Direct SDK calls scattered across services guarantee you will never attribute anything.
Every call should emit, at minimum:
- Feature and environment identifiers, plus the deploy or prompt version.
- Tenant or customer ID, so you can see which accounts are unprofitable.
- Input tokens, output tokens, cached tokens, model name and latency.
- For agents: trace ID, step count, tool calls and whether the run terminated successfully.
- An outcome flag written back once the business result is known.
That last one is the piece almost everyone skips, and it is what turns a cost dashboard into a profitability dashboard. It also feeds the evaluation logging described in our AI governance control stack, so you build the audit trail and the cost model with one piece of plumbing.
The seven levers that actually cut cost
- 01Prompt cachingMove static instructions, schemas and retrieved context to the cached prefix. On repetitive workloads this alone routinely removes 40-70% of input token cost with zero quality change.
- 02Context disciplineStop stuffing entire documents in. Retrieve narrower chunks, cap history, and summarise long conversations. Shorter context also improves accuracy, which is the rare optimisation that helps twice.
- 03Output caps and structured outputForce JSON schemas and set max output tokens. Free-form prose is the most expensive way to return a field value.
- 04Batching and asyncAnything not user-facing - enrichment, classification, nightly summarisation - belongs on the batch tier at a fraction of the interactive price.
- 05Semantic and exact-match cachingA surprising share of production traffic is near-duplicate. Cache at the answer layer, with a short TTL and a tenant-scoped key.
- 06Small models for narrow jobsClassification, routing, extraction and reranking rarely need a frontier model. This is usually the single biggest saving available.
- 07Agent step budgetsCap steps, tool calls and total tokens per run. An agent without a budget is an unbounded loop with a credit card.
In the engagements we run, caching plus right-sized models typically removes 50-70% of spend before anyone touches architecture. The remaining savings come from context discipline and agent budgets, and those need engineering time.
Model routing and the quality floor
Routing means sending each request to the cheapest model that clears a defined quality bar. It is powerful and it is where teams get burned, because "cheapest that works" is meaningless without a measurement of "works".
Build the evaluation set first: 100-300 real, labelled examples per feature, refreshed quarterly. Then route with confidence. A common production shape is a small model handling the bulk of traffic, a mid-tier model for complex cases identified by a cheap classifier, and a frontier model behind an explicit escalation path. Log which tier served each request so a quality regression can be traced to a routing change rather than blamed on the model provider.
Never let routing change silently in production. Treat prompt and routing configuration as versioned code with the same review discipline your AI-native development workflow applies to everything else.
Budgets, quotas and runaway-agent protection
Dashboards report yesterday's disaster. Guardrails prevent tomorrow's. Every AI workload we put into production ships with four controls: a hard monthly budget per feature that degrades to a cheaper model rather than failing, per-tenant rate and token quotas, a per-run token ceiling for agents, and an anomaly alert on cost-per-hour rather than cost-per-month.
The degradation path matters. Cutting a customer off mid-workflow to save $40 is a worse outcome than serving a slightly weaker answer. Decide that policy before the incident, not during it.
The monthly operating loop
AI FinOps is a habit, not a project. The loop we hand over runs monthly and takes about ninety minutes: review cost per outcome by feature and by tenant, identify the top three cost drivers, check the quality evaluation scores against the previous month, approve or revert routing changes, and re-set budgets for the coming month.
Finance, engineering and the product owner all attend. That combination is what keeps the conversation about margin rather than about tokens - and it is the same forum where you decide whether an unprofitable feature should be repriced, re-scoped or retired.
Where RanWebs fits
We run AI FinOps as a four-week engagement for teams already in production across the US, UK, EU and APAC: instrument the gateway, build the cost-per-outcome model, implement caching and routing, and hand over the budgets, alerts and monthly loop to your team. It sits alongside our cloud practice and AI agent development work, so the same team that builds the feature owns its unit economics.
Want the short version applied to your stack? Email info@ranwebs.com or use the contact page. First call is free and goes to a senior consultant.

