AI Usage Cost Governance

AI usage cost governance controls spend on Cursor, Claude Code, and Codex through each tool’s own telemetry, dashboards, and budget limits rather than a custom platform. Three variables drive the bill — model choice, context size, and agentic loop length — so governance means making them visible, attributing spend to teams, routing tasks to the cheapest adequate model, and reporting output metrics finance can evaluate.

Finance pings you on the first of the month: the AI tooling line went from a rounding error to five figures. Engineering says they need it; finance says prove it. You pull up the dashboard and realize you cannot say which teams are using what, whether the flagship model is being used for trivial tasks, or whether half the seats are even active.

You do not have a spending problem yet — you have a visibility problem. Tokens are metered, not seat-priced, so a single engineer running a 200K-token agentic refactor on a flagship model can cost more in an afternoon than another engineer does all month. Cost governance is not about restricting AI usage; it is about making every dollar visible, attributable, and defensible. This guide does that with each tool’s real, documented controls — not a bespoke governance platform you would have to build.

What this cost-governance setup gives you

A working cost-visibility setup for each tool: Claude Code OpenTelemetry metrics, the Cursor team usage dashboard, and Codex usage reporting
A real OTEL_RESOURCE_ATTRIBUTES configuration that attributes spend to team and cost center, plus a cost-center and alert-threshold cadence
A model-selection policy that defaults to cheaper models and escalates only when the task justifies it, encoded in each tool’s own rules file
Copy-paste prompts for a monthly spend audit, a model-routing review, a context plan, and a batched change that costs one session instead of ten
An ROI method that reports output metrics rather than token counts, so the budget conversation has evidence in it
Concrete failure modes (silent telemetry, managed-settings overrides, budget alerts that never fire) and how to recover

Where the money actually goes

Before you instrument anything, get the mental model right. Three variables drive the bill, in order of impact:

Model choice. The gap between a flagship and a mid-tier model is roughly 1.5-5x per token. Defaulting every task to the most expensive model is the single biggest source of waste.
Context size. You pay for input tokens too. Loading an entire repo into context for a one-file change is silently expensive, and cache reads only partly offset it.
Agentic loops. Autonomous multi-step runs (large refactors, test-fix loops, deep research) multiply token usage. They are often worth it — but they need to be a deliberate choice, not an accident.

Underneath those variables sits the plan structure, which differs per tool. Re-verify against the official pricing pages before locking a budget; vendors revise plans frequently.

Component	Cursor	Claude Max	Codex
Per-seat license	Standard $32/seat/mo, Premium $96/seat/mo (annual)	$100-200/month	Included in ChatGPT Plus/Pro
Model usage	Included (with per-seat pools)	Generous token allocation	Cloud task credits
Overages	Additional usage packs	API fallback at per-token rates	Additional cloud minutes
Admin features	Team dashboard	Via Anthropic Console	Via OpenAI Platform

And the bill is not the whole cost. A defensible budget conversation accounts for direct costs (subscriptions, API usage, overages), indirect costs (training time, workflow disruption during adoption, support overhead), opportunity costs (what developers would be doing instead of learning new tools), and savings (reduced development time, fewer production bugs, lower QA burden).

Governance is mostly about making the three variables visible and putting light, non-blocking guardrails on the expensive paths. You do not need a custom MCP “cost gateway” or an invented YAML framework. Every tool ships the primitives.

Step 1: turn on cost visibility

You cannot govern what you cannot see. Each tool exposes usage differently — CLI telemetry for Claude Code, an admin dashboard for Cursor, and org usage reporting for Codex. Set up all three; the workflows genuinely differ here.

Cursor is IDE-first, so its cost controls live in the team admin dashboard (cursor.com/dashboard), not in config files. As a team admin you get:

Usage by member, split into two included pools per seat: Composer + Auto (first-party models) and Third-Party API (BYO-key model usage). This immediately surfaces your heavy users and your inactive seats.
Team-wide monthly spending limits that cap overage before it runs away.
Smart alerts on dollar thresholds, delivered to Slack or email before a billing surprise lands.
Seat-type recommendations — Cursor flags when a member’s usage fits a Standard versus a Premium seat, so you are not overpaying for light users.

There is nothing to install: the visibility is built into the Business/Teams plan dashboard. Your job is to turn the spending limit and alerts on, then review the per-member breakdown monthly.

Claude Code is CLI-first and exports the richest cost telemetry of the three via OpenTelemetry. Enable it with environment variables (verified against the official monitoring docs):

# Enable telemetry and pick exporters
export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp        # otlp | prometheus | console
export OTEL_LOGS_EXPORTER=otlp

# Point at your collector (Grafana/Prometheus, Honeycomb, Datadog, etc.)
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.company.com:4317
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer ${OTEL_TOKEN}"

The metrics you care about for cost work are real and documented: claude_code.cost.usage (USD, tagged by model), claude_code.token.usage (tagged by type: input/output/cacheRead/cacheCreation and model), claude_code.session.count, and claude_code.active_time.total. That cost.usage metric is the whole ballgame — sum it, group by model and team, and you have per-team spend without building anything.

For org-wide rollout, push the same vars through the managed settings file so every developer reports automatically and cannot silently disable it.

Step 2: attribute spend to teams

Aggregate spend is a number to panic about; attributed spend is a number to act on. For Claude Code, attribution is a one-line change. The OTEL_RESOURCE_ATTRIBUTES variable tags every metric with whatever dimensions you set — and it follows the W3C Baggage spec, which means no spaces in values (a common gotcha):

# Correct: comma-separated key=value, no spaces, underscores instead
export OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=platform,cost_center=eng-123"

# Wrong: spaces are invalid and silently break the attribute
# export OTEL_RESOURCE_ATTRIBUTES="cost_center=Eng Platform"

Now claude_code.cost.usage is queryable by team.id and cost_center in your backend. Cursor handles this for you — the dashboard is already per-member and per-team. Codex attribution is by workspace or project, so put each team in its own ChatGPT workspace or API project if you need clean per-team numbers.

With the dimensions in place, the operating cadence is what turns them into governance:

Define cost centers by team. Each team gets a monthly AI tooling budget sized to team size and project complexity, not split evenly.
Watch the distribution, not the individuals. Per-member usage tells you where the power users and the inactive seats are; that is a reallocation signal, not a performance review.
Set two alert thresholds. Notify team leads at 75% of budget and engineering management at 90%, so a conversation happens before a cap does.
Review monthly, adjust quarterly. Compare actual against budgeted spend each month; revise the allocation only when a quarter of data says to.
Assess ROI quarterly. Put the cost next to the output metrics from the last section of this guide, and let that drive the next allocation.

Step 3: set a model-selection policy

This is where most of the savings come from. The principle is simple: default to the cheapest model that does the job, escalate deliberately, and front-load expensive thinking where it prevents costly rework. Here is a sane default policy for the current lineup (June 2026):

Task	Default model	Escalate to	When to escalate
Syntax fixes, renames, import cleanup	Haiku 4.5 / Auto	-	Never
Everyday feature work, code review	Sonnet 5	Opus 5	Security-sensitive or architectural change
Complex debugging (race conditions, perf)	Sonnet 5	Opus 5	Reproduction is non-obvious after one pass
Architecture design, large refactors	Opus 5	Fable 5	When complexity warrants peak intelligence and budget is secondary
Building from scratch, cross-repo refactors, long-running tasks	Fable 5	-	Use when velocity and quality matter more than token cost; subagents inherit the configured/default model unless you explicitly pin a different model, so budget that work rather than assuming an automatic downgrade

A policy nobody can find is not a policy. Encode it where the tool will read it:

The model picker makes routing a per-request decision — start on Auto/Sonnet 5 and bump to Opus 5 only when a task stalls. Write the team guideline into the rules file so the default is visible without asking:

MODEL USAGE POLICY:
- Claude Fable 5: Complex multi-file refactoring, building features from scratch, security audits where peak intelligence justifies 2x cost
- Claude Opus 5 / GPT-5.6 Sol: Architecture decisions, complex debugging, cross-service work
- Claude Sonnet 5: Feature development, code review, refactoring, documentation
- Fast models (auto-complete): Tab completion, simple edits, formatting

Default to Sonnet 5 for everyday work.
Switch to Opus 5 when you need deep reasoning across many files.
Reserve Fable 5 for the hardest tasks where velocity and quality matter more than cost.
Use Background Agent (Sonnet 5) for long-running tasks.

Set the default model in settings, switch in-session with /model, or pick per invocation:

# Daily development - cost-effective
claude --model sonnet "Add input validation to the signup form"

# Complex architecture - worth the cost
claude --model opus "Redesign the caching layer to support multi-region deployment.
Consider consistency models, invalidation strategies, and failover."

# CI/CD automation - optimize for speed and cost
claude -p --model sonnet "Review this diff for security issues: $(git diff)"

Encode the routing in your CLAUDE.md so it survives the person who wrote it:

Cost policy: Default to Sonnet 5 for implementation tasks.
Use Opus 5 for: architecture changes, security audits,
cross-service refactoring, and debugging production incidents.
Use Fable 5 (/model fable) when budget matters less than quality:
complex multi-file refactoring, building from scratch, long-running
tasks demanding peak intelligence. Subagents inherit the configured
model unless you pin a cheaper one explicitly, so a Fable orchestrator
means Fable-priced subagents unless you say otherwise.

Route the GPT-5.6 tier by role and plan: Terra for balanced work, Luna for high-volume jobs, and Sol for the hardest tasks. Do not run every prompt at maximum effort. The other Codex lever is surface rather than model, so put that in AGENTS.md:

COST OPTIMIZATION:
- Use CLI for quick edits and local tasks (lower cost)
- Reserve cloud tasks for: large refactoring, multi-file changes, PR creation
- Batch similar tasks into single cloud sessions to reduce overhead
- Use IDE integration for inline completions during active development

Cloud tasks give clear per-task cost visibility, which makes them the easy unit to budget against.

Here is last month's AI usage data (cost by model and by team). Act as a FinOps reviewer.
1. Which teams are running flagship-tier models (Fable 5 / Opus 5 / max-effort
   GPT-5.6 Sol) for tasks that a mid-tier model (Sonnet 5) would handle?
   Quantify the spend on those tasks.
2. Where is cache-read token usage low relative to input tokens, suggesting
   context is being reloaded instead of reused?
3. Recommend three specific routing changes, each with an estimated monthly
   dollar saving and the quality risk of making it.
Be concrete and show your arithmetic. Do not recommend changes that would slow
down incident response.

Step 4: put light guardrails on the expensive paths

Hard blocks breed shadow IT and resentment. Favor transparency and nudges over approval gates:

Cap the runaway cases, not the routine ones. Set Cursor’s team-wide monthly spend limit and Codex’s platform budget limit as a backstop against accidents (a forgotten loop, a misconfigured automation), not as a daily leash. Set the threshold where a genuine surprise lives — 150-200% of a normal month — so it only fires on anomalies.
Alert before you block. Wire Cursor’s smart alerts to Slack at the 75% and 90% thresholds above, and alert on claude_code.cost.usage crossing a rolling threshold in Grafana or your backend. People self-correct when they can see the meter.
Make context discipline a habit, not a rule. The cheapest token is the one you do not send. Encourage scoping context to the files in play and using each tool’s compaction (Claude Code’s /compact, starting fresh sessions for unrelated work) rather than dragging a bloated context across tasks.
Batch what repeats. Ten near-identical changes asked ten times pay the context cost ten times. One session with the pattern established once is dramatically cheaper and usually more consistent.
Review monthly, adjust quarterly. Pull the per-team breakdown once a month, run the routing-review prompt above, and only revise budgets and policy when the data says to.

The prompts below are the habit made concrete. The first sets the cost contract for a whole session; the second is a narrower context plan for one method; the third is the batching move.

Before we start: this is a [bug fix / refactor / feature] in [area]. Optimize
for cost without hurting quality.
1. Propose the minimal set of files you actually need in context for this task,
   and tell me which ones you'd skip.
2. Recommend a model: default to the cheaper tier unless you can justify the
   flagship for this specific task in one sentence.
3. If you hit a point where escalating the model or widening context would
   clearly pay off, stop and ask me first instead of doing it silently.

I need to modify the UserService.updateProfile method.
Before we start, give me a focused context plan:
1. Which files do you absolutely need to read? (minimum set)
2. Which files would be nice-to-have but not essential?
3. What information can you infer from type signatures alone?

Let's read only the essential files to minimize token usage.

I need to add input validation to 8 API endpoints. They all follow the same pattern.
Here's the pattern for POST /api/users (implement this one as the template):
- Parse request body with Zod schema
- Return 400 with validation errors if parsing fails
- Pass validated data to the service layer

Now apply this same pattern to these endpoints:
1. POST /api/orders
2. PUT /api/orders/:id
3. POST /api/products
4. PUT /api/products/:id
5. POST /api/reviews
6. PUT /api/users/:id/settings
7. POST /api/payments

Use the existing Zod schemas in /src/schemas/ for each endpoint.

A third habit costs nothing to adopt: build reusable architectural context documents so a session does not re-read the same files to relearn the same things.

Proving the value to finance

The budget conversation goes badly when you bring input metrics. Tokens used and sessions created mean nothing to a CFO. Output metrics — PRs merged per week, bug escape rate, cycle time, developer satisfaction — are what the investment is actually being judged on.

The arithmetic finance recognizes is straightforward:

Monthly ROI = (Hours Saved x Avg Developer Cost/Hour) - AI Tool Costs

Every term on the right is something you must measure rather than assume. Hours saved comes from your own developer surveys and PR cycle-time data, not from a vendor’s headline; the loaded hourly cost comes from finance. Run the numbers with your figures, and present the range your data supports rather than the best case.

Analyze our AI tooling costs and generate a monthly report:
1. Total spend by tool (Cursor, Claude Code, Codex API)
2. Per-developer average cost and usage frequency
3. Cost per model tier (Opus vs. Sonnet vs. fast models)
4. Identify inactive seats (< 5 uses per month) - recommend reallocation
5. Identify high-cost developers (> 2x average) - check if justified by output
6. Calculate cost-per-PR-merged as a productivity proxy
7. Project next month's costs based on current trends

Format as an executive summary suitable for engineering leadership and finance review.

When AI cost controls break down

Real failure modes from rolling this out across teams — and how to recover.

Metrics never arrive in your backend. Almost always a wrong endpoint or protocol mismatch. Confirm OTEL_EXPORTER_OTLP_ENDPOINT points at a port your collector actually listens on (gRPC defaults to :4317, HTTP to :4318), and that OTEL_EXPORTER_OTLP_PROTOCOL matches (grpc vs http/protobuf). Debug locally first with export OTEL_METRICS_EXPORTER=console and OTEL_METRIC_EXPORT_INTERVAL=1000 to see metrics print to the terminal within a second.
Telemetry is silently disabled. If CLAUDE_CODE_ENABLE_TELEMETRY is not set (or a managed settings file overrides your shell export), no metrics flow and your dashboards stay empty while spend continues. Managed settings win over user environment variables by design — check the settings precedence if org config and local config disagree.
Attribution comes back blank or garbled. Spaces in OTEL_RESOURCE_ATTRIBUTES violate the W3C Baggage spec and break the value. Quotes do not escape spaces — org.name="My Team" stores the literal quotes. Use underscores or camelCase.
“We cannot track per-developer usage at all.” Most enterprise plans provide admin dashboards with usage data. For API-based usage, wrapper scripts that log before forwarding to the service give you the same picture. Even rough estimates from monthly billing beat no tracking.
Budget alerts that never fire. A spend limit with no alert below it is just a wall you hit at full speed. Always set an alert threshold under any hard cap, and test it by temporarily lowering the threshold below current spend to confirm the Slack or email path actually delivers.
Developers use the flagship model for everything. This is a training problem, not a tooling problem. Run a session showing the quality difference on routine tasks (usually minimal) next to the cost difference (significant). Most developers switch voluntarily once they see the data — and the same logic applies one tier up: Fable 5 is the right choice for the hardest tasks and the wrong default for routine work.
Model names drift in your policy doc. A routing policy pinned to last cycle’s models silently routes work to deprecated or pricier-than-necessary models. Re-verify the current lineup and pricing each quarter — the model landscape moves fast, and “default to Opus 5 / Sonnet 5” today will not be the right string in six months.
Some teams get far more value than others. This is expected, not a failure. Teams on complex, high-context work get more from these tools than teams doing straightforward CRUD. Adjust budgets to match rather than applying a uniform per-head allocation.
MCP gateway auth failures. If you do front cost reporting with an MCP server, a 401/403 on its endpoint means the whole reporting path goes dark without erroring loudly in your dashboards. Treat MCP reporting servers as best-effort enrichment, never as your primary system of record — keep the tool-native telemetry as the source of truth.

Where to go next with cost governance

Team Adoption Strategies Get a whole team productive on these tools before you optimize their spend.

Security Standards and Compliance The access controls and audit trails that pair with cost governance.

Context Cost Optimization The deeper version of the context-discipline tactics above.

Cloud Cost Optimization Extend the same discipline to cloud infrastructure spend.

Introduction to Model Context Protocol How the identical MCP config works across all three tools.