FinOps for coding agents: allocate, report, cap

Coding agents are the first AI spend most companies meet on a payroll line rather than a cloud bill: a developer's laptop, a key or a seat, and an invoice that says one number a month. The FinOps Foundation's three capabilities for it are the ones you already run on the cloud: allocate the cost to who caused it, report it where decisions are made, and stop the anomaly before the overage. This page applies each to Claude Code, Codex and the agents on Bedrock, in the Foundation's words, with one developer's measured month as the worked example.

FinOps for AI, applied to coding agents

The Foundation's Framework, read 30 October 2026: "FinOps is an operational framework and cultural practice which maximizes the business value of technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams." Its AI page: "FinOps for AI focuses on addressing the cost complexity, faster development cycle, spend unpredictability, and the need for a greater degree of policy and governance to support innovation through allocation, forecasting, and optimization decisions that align consumption, investment, and business value." And on the meter: "One of the primary cost meters for AI usage is tokens."

Three of its capabilities carry the work for a coding agent. Each is quoted from its own page, read the same day:

• Allocation. "Define strategies to assign and share cost and usage using accounts, tags, labels, and other metadata, creating accountability among teams and projects within an organization." The strategy exists "in order to do showback to various teams, chargeback to finance, or allocation to cost centers".
• Reporting & Analytics. "Reporting & Analytics is the ability to gain insights into data by creating reporting mechanisms to serve the needs of the organization’s various persona groups."
• Anomaly Management. "Detect, identify, alert and manage unexpected or unforecasted technology cost and usage irregularities in a timely manner to lower risk and ensure cost-effective operations." Its AI KPI: "Measures the frequency and cost impact of anomalies in AI spending, such as sudden cost spikes or unexpected usage patterns." Budgeting is the control beside it: "Strategic and ongoing process for setting limits, monitoring, and managing technology spending, aligned with business objectives, to ensure accountability and predictable financial outcomes for IT systems."

A coding agent has no account, tag or label. It has a developer, a laptop, a directory the session ran in and the pull request it produced. The invoice knows the first; the ledger on the machine knows the rest.

Allocate: the unit is a pull request on a laptop

The Foundation's own caveat for AI, from the same page: "Allocation of costs may be more complex, particularly if many projects at once are using the same types of services". Every coding agent on a team uses the same model from the same vendor; the work differs by repository. What each payment route lets you allocate, from the vendors' pages:

• An API key. The Claude Console bills a workspace. "Claude Code mints a per-user API key in this workspace at sign-in." So the Console allocates to a person, and "It is the only workspace that supports per-user monthly spend limits." Nothing on the key says which repository.
• A seat. Team and Enterprise bill per person, with usage inside the seat: "Usage inside the seat allowance isn't metered in dollars." Past it, usage credits are metered and the spend report lists them per user and per model. Seats, minimums and what is not public: Claude Enterprise pricing.
• Bedrock, Vertex or Foundry. Your cloud bill, by account, inference profile and tag: "Claude Code does not send metrics from your cloud back to Anthropic, so the analytics dashboards and the Claude Code Analytics API do not cover this usage." The setup and where the dollars land: Claude Code on Bedrock.
• An expensed Max plan. A receipt per person, a flat amount, and no usage line at all.

Each route stops at the person. The pull request is in the repository; the cost is in the session files on the developer's machine, which record the directory each session ran in. Caprock reads those files, prices each turn at list from a dated table, sums each repository and divides by the pull requests merged in the window. 29 September to 28 October 2026, my Mac, read from its database on 28 October 2026:

$5,699 / 722

= $7.89 a merged pull request, dspv/caprock

$589 / 194

= $3.04 a merged pull request, cybrixcc/caprock-web

Two repositories, 2.6× apart on the same developer and the same models. That is the allocation the invoice cannot make: it would have shown one key, one number. A directory is the tag a coding agent already carries.

Report: one line, or thirty days

The month, as the invoice shows it and as the machine recorded it:

$7,409

the thirty days, at list price, as one line

$669.90

the dearest day, 14 October

$21.45

the lightest, 29 September

Spread evenly, that line is $247 a day. The median day was $217.76; 3 of the thirty days ran past twice that. A monthly line hides every one of them until the invoice arrives; a daily reading names the day while the session that caused it is still open. The same chart, with the month as one bar beside the thirty, is on Caprock for Teams.

A list-price estimate is not an invoice. Anthropic's own page says so of Claude Code's figures: "By default, Claude Code computes every cost figure it shows developers at list price, so if your organization pays contracted rates, the figures in /usage, the status line, and OpenTelemetry don't match your bill." Caprock's figures are list price too: a session on a seat is priced at what its tokens would cost on an API key, a session on Bedrock at Anthropic's first-party list, and a contracted discount is not applied. Report it beside the invoice, named for what it is: the allocation of the invoice's one number by repository, at list. How the estimate is made and checked: the method; the figures it produced over a longer window: the numbers.

An earlier reading, for the trend: in the week to 16 October 2026, the same machine merged 45 pull requests on dspv/caprock for $343.78 of agent time, $7.64 a merged pull request, read off the running app by Caprock v0.126.0. The thirty-day figure for the same repository is $7.89: two windows, two readings, each dated.

Cap the loop, not the work

The heaviest session in the thirty days:

$3,465

one session, 47% of the month

373 h

its length; $9.29 an hour

64,039

tool calls

It was long work, not a loop. Checked against the same database on 30 October 2026: the loop detector's own signature, the same command and input five times in three minutes with read-only calls excluded, never fired; the densest work on one file inside any 3 minutes was 18 Edits, each a different change. A monthly cap low enough to catch it would have stopped the session mid-task, and every other session on the key with it; a cap high enough to let it finish catches nothing. The Foundation's Budgeting page asks for the distinction: "Live execution thresholds are enforced against the budget; spend approaching a budget line triggers a defined response, such as an alert, approval gate, or throttle, before the overage happens", and "Where a workload needs a spending limit, users should document the separate approval, throttling or shutdown control, including service-impact checks and who can authorize it, including testing the response before relying on it."

What each vendor's limit is set on, from its page:

• Claude Console. "Cap monthly spending for a workspace." On the Workspaces page, "click Spend limits to cap monthly spending and configure alerts when spending reaches certain thresholds". "You cannot set spend limits on the Default Workspace." "Organization-wide limits always apply, even if workspace limits add up to more."
• Claude Team and Enterprise. "the seat allowance is the default ceiling. To let members continue past it, turn on usage credits and set spend limits at the organization, group, or individual member level." At the limit the developer reads "You've hit your individual spend limit", "org's monthly spend limit" or "team's shared budget": the developer's request would be billed to usage credits, and those credits have reached a spend limit you set.
• Codex. Business: "monthly credit usage limits by seat type and per-user overrides", and "By default, all seats and users have no limits specified." Enterprise: "Usage limits control each person's usage through workspace defaults, group defaults, and individual overrides. The amounts are in credits or USD, depending on your billing model." Of both: "They don’t cover all Codex usage or govern OpenAI API Platform billing." A developer on an API key is on the Platform bill.
• Cursor. "Spend limits cap how much paid additional usage you're willing to pay for in a period." "When a limit is reached, additional usage stops for that user until the limit is increased or the next period starts." "On Teams, admins set one limit for the whole team, either a fixed amount or an amount per seat." Enterprise adds member overrides, group overrides and a team general spend limit; "When a user has limits from multiple sources, Cursor applies the highest applicable limit." And: "Enforcement is not instant, so usage can briefly exceed your spend limit."

Every one of them is a month on a key, a seat or a workspace: the Foundation's "shutdown control", reached after the work it stops. None names a session.

Caprock's cap is a day, on the machine, and it has a limit of its own. cap_usd_per_day is off until chosen; the suggested figure is twice the median day, rounded, offered as a click and never prefilled, because a number nobody chose stops work. On my thirty days that would be $436. Checked after each turn is priced, not on a timer, its four rules are only owned sessions, paused, not killed, once a day and fails open: the session is paused with SIGSTOP so its conversation and context survive a resume, a session resumed by hand is not re-paused that day, and an unreadable spend pauses nothing. What it does not stop: a session started in a terminal. Caprock never signals a process it did not start, so the cap pauses only the sessions Caprock started. On my machine in these thirty days 1,737 of 2,363 sessions were started in a terminal, and those were $790 of the $7,409; the 626 Caprock started were $6,619, so the cap reached most of the spend but not most of the sessions. For the rest, and for every session, the loop alert is the control: the same command run five times in three minutes, read-only calls excluded, on the Now screen and the session page, with the session's total named for what it is.

What to do with the number next week

Three moves for the FinOps owner, each from a figure above:

• Allocate by repository, not by person. Put cost per merged pull request beside each repository's line in the report, at list, dated. Two repositories on one developer were 2.6× apart; a per-seat figure averages that away.
• Report the thirty days beside the invoice. The invoice's $7,409 is the total; the 3 days past twice the median are the finding. Name the estimate as list price and show the invoice as the bill.
• Alert on the loop, cap the day. Keep the vendor's monthly cap as the backstop it is, set a daily cap at twice the median day where sessions are started from Caprock, and route the loop alert to whoever can answer the session: the Foundation's "alert, approval gate, or throttle, before the overage happens".

Beside the invoice: the ledger across machines

Caprock for Teams is the ledger for the three capabilities across a team: every coding agent on every machine, each session priced the same way at list, summed per repository, pull request and release on a server you run, however the work was paid for. Each machine sends aggregates by work unit, with no field for a prompt, a reply or a command's output; the person is a switch, off by default, so the allocation is to the work until someone with the authority turns the person on. The invoice stays the bill; the ledger is the line under it that says where the month went. Buying Caprock is one flat price for the team.