What an AI agent actually costs per task

Your agent bill tripled last month and the invoice is one line. A total, a date, and no way to tell whether it went on the checkout rewrite or on an agent that spent nine hours renaming labels.

Spend is easy to see; attribution is the hard part, and attribution is what finance asks for. You can pull July's numbers for Claude Code, Cursor and Copilot out of three consoles in ten minutes and still not say what you got.

Bias first: I work on Taskfolk, and attaching spend to work is the part it does. A session of agent work is anchored to an issue key, so cost rolls up per agent and per ticket with no tagging scheme to invent. It cannot see your provider bill, and I will say where that hurts. What a vendor charges for its own AI is a different post. This is what your own agent spends.

What a task is supposed to cost

Get an outside number first, or you have nothing to judge your own against.

Anthropic publishes deployment figures for Claude Code: around $13 per developer per active day and $150 to $250 per developer per month, with 90% of users staying under $30 on an active day (checked 26 July 2026). The same page notes that its own /usage total is computed locally from list prices and "may differ from your actual bill". Agent teams change the shape: each teammate runs its own context window, so tokens scale with team size.

Those are per developer figures, and turning them into per task figures is not division. Eight tickets closed in a week at $13 a day is not $8 a ticket if three of them were the same ticket, attempted three times.

Cost per task is meaningless without a denominator

Divide spend by attempts and you get a flattering number, because failures cost money too.

The formula is not ours: the field settled on cost per run divided by success rate, and it is right. What makes it bite is Artificial Analysis's AA-Briefcase benchmark, 91 private long horizon knowledge tasks, reported by LangWatch in July 2026: the leading model costs about $31 a task and meets every rubric criterion on 3% of them, which puts its cost per fully correct result near $1,000. Cost per task spans more than 800x across the models tested.

Teams guess their success rate, and guess generously. LinearB's 2026 benchmarks, published in March from 8.1 million pull requests across 4,800 teams in 42 countries, found 32.7% of AI assisted PRs merged within 30 days against 84.5% of human authored ones. Those PRs ran past 400 lines at the 75th percentile against 157, and waited about 5.25 times longer for a first review. Fully agentic PRs came in near 290 lines, with no separate merge rate published, so measure your own.

If your real merge rate is a third, dividing by attempts understates the number threefold.

Sessions give you three buckets, not two. The middle one is where the arguments happen.

flowchart TD
  A["Agent session ends"] --> B{"Terminal state"}
  B -->|"done or review"| C{"PR link, comment or activity row"}
  B -->|"failed or cancelled"| E["Bucket 3: cost, no outcome"]
  C -->|"yes"| D["Bucket 1: cost with a trace"]
  C -->|"no"| F["Bucket 2: flagged unverified"]
  D --> G["Denominator: completed tasks"]
  E --> H["Numerator only"]
  F --> H

Taskfolk flags a review or done session anchored to an issue that carries no external link and left no activity row or comment from that agent on that issue while it was open. Three things defeat it: a comment, the PR URL, or work the tracker never sees. Treat bucket two as a review queue, not a verdict. Managing a team of agents goes further into the states.

Every figure here is agent reported

The agent spends on its own provider account. Taskfolk never runs the model, so it cannot read your invoice and cannot stop a run that is burning money. Every dollar figure is one an agent reported about itself, and the interface says so wherever it shows one.

The vendor's own tooling has the same shape. Claude Code computes its session total locally from list prices, so it "doesn't reflect promotional pricing or contracted discounts and may differ from your actual bill". The company running the model is estimating from a price list too.

Where you look	What it tells you	What it cannot tell you
Provider console (Anthropic, OpenAI)	Billed dollars, per key or per user	Which ticket, which project
An LLM gateway (Helicone, LiteLLM, Portkey)	Spend for every request routed through it	Anything that never routes through it
DX AI cost management	Vendor billing across Claude, Cursor and Copilot, by team, with an estimated cost per PR	The ticket. Its unit is the pull request, not the issue
Taskfolk agent sessions	Agent reported dollars anchored to an issue key, per agent and per session	Your actual provider bill

If you need vendor billing reconciled across three tools and mapped onto teams, DX does that on an enterprise contract and Taskfolk does not. If you want a dollar figure next to WEB-39 on a $3 per seat tracker, the trade runs the other way.

Wiring the reporting, and the null you should want

Reporting is one POST per turn, and every call is a delta on the session total. Send cost_usd when your SDK hands it to you, tokens plus a model string when it does not.

curl -X POST https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions/ses_9f21/usage \
  -H "Authorization: Bearer tfk_live_a1b2..." \
  -H "Content-Type: application/json" \
  -d '{"tokens_in": 84210, "tokens_out": 6180, "cached_tokens": 512000,
       "cost_usd": 0.4137, "model": "claude-sonnet-4-6"}'

await fetch(
  "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions/ses_9f21/usage",
  {
    method: "POST",
    headers: {
      Authorization: "Bearer tfk_live_a1b2...",
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      tokens_in: 84210,
      tokens_out: 6180,
      cost_usd: 0.4137,
      model: "claude-sonnet-4-6",
    }),
  },
);

import requests

requests.post(
    "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions/ses_9f21/usage",
    headers={"Authorization": "Bearer tfk_live_a1b2..."},
    json={
        "tokens_in": 84210,
        "tokens_out": 6180,
        "cost_usd": 0.4137,
        "model": "claude-sonnet-4-6",
    },
)

{
  "id": "ses_9f21",
  "issue_key": "WEB-39",
  "model": "claude-sonnet-4-6",
  "tokens_in": 84210,
  "cost_usd": 0.4137,
  "usage_reports": 1
}

A model string on its own is refused: at least one of tokens_in, tokens_out, cached_tokens or cost_usd has to be present.

flowchart TD
  R["Usage report arrives"] --> C{"cost_usd present"}
  C -->|"yes"| V["Stored verbatim, source reported"]
  C -->|"no"| M{"Model string in the rate table"}
  M -->|"yes"| E["Estimated from tokens"]
  M -->|"no"| N["Tokens recorded, cost stays null"]

A reported cost_usd of zero or more always wins and is stored exactly as sent. Otherwise the dollars come from a built in table keyed on the exact model string, with cached input priced at a tenth of the input rate.

Model string the agent reports	Input per 1M	Output per 1M
claude-haiku-4-5	$1	$5
claude-sonnet-4-6	$3	$15
claude-opus-4-8	$5	$25
claude-fable-5	$10	$50
gpt-4o	$2.50	$10
gpt-4o-mini	$0.15	$0.60
o3	$2	$8
o4-mini	$1.10	$4.40

The gaps say more than the entries. The provider catalogue covers nine kinds, Gemini CLI, DeepSeek, Kimi, Codex and Cursor among them; the price table covers two vendors. Report tokens with a model outside it and Taskfolk keeps the tokens and leaves cost null, because reading $0 when the truth is unknown is worse than reading nothing. One line in your run loop settles it: send cost_usd yourself, since your SDK already returns usage on every response.

From sessions to a per ticket number

Anchor the session to an issue when you start it and the join is one query.

curl -s "https://taskfolk.ai/api/v1/workspaces/acme/agent-sessions?issue_key=WEB-39" \
  -H "Authorization: Bearer tfk_live_a1b2..." \
  | jq '[.data[].cost_usd] | add'

Say WEB-39 took three sessions: two failed at $0.41 and $0.88, one finished with a PR link at $2.10. The ticket cost $3.39, not $2.10. On the issue each session carries a cost badge with a burn rate per minute beside it, and its tooltip holds the tokens and model behind the number.

Now the sprint. Forty sessions across twenty two tickets, $61.40 reported, fourteen tickets done with a trace and a PR link. Per attempt that is $1.54. Per completed ticket it is $4.39, nearly three times higher, and the second number is the one you quote.

Set that against a person. Use your own loaded rate; call it $85 an hour, a $136,000 base at 1.3 loading over 2,080 hours. At that rate $4.39 buys three minutes of engineer time, so almost any ticket looks like a bargain.

It is not, and this is the part token math posts leave out. A merged agent PR still has to be reviewed, and those PRs run long and sit waiting. Forty minutes of a senior engineer turns the ticket into $4.39 of tokens and about $57 of review. Shaving the $4.39 while leaving the $57 alone is the wrong lever by an order of magnitude, which is why the ticket shapes the bill more than the model does. There is a whole post on writing tickets an agent can actually finish, and once you have the cost side, whether your agents actually saved time is the other half of the answer.

When one agent costs three times the others

Three causes, in the order worth checking.

Model choice first. The 800x spread is not a typo, and the cost by model panel settles it in seconds. An agent left on a frontier model to tidy labels is the usual culprit.

Context size second. TrueFoundry documented a fifty engineer org that cut monthly agent spend from $8,400 to under $800 after tracing 92% of pipeline cost to one step, a 50,000 token security manual injected into every pull request, then putting a semantic cache in front of it. A per developer average hides that. It surfaces when you group spend by the thing doing the spending.

The ticket third. Vague scope produces exploration, exploration produces retries, and retries are pure numerator. A running session with no heartbeat for thirty minutes renders as stalled, usually a paid agent going nowhere; how to tell when an agent is stuck covers that signal.

One caveat on the rollup page. The per day series and the cost by model breakdown come from the analytics store and go empty if it is unreachable; cost by agent comes from the session rows and always renders. The page says which is which rather than showing a blank chart.

A cap that alerts and stops nothing

Each agent can carry a spend cap, set from its menu by the agent's owner or a workspace admin and readable on the API as spend_cap_usd. When cumulative reported cost crosses it the owner gets an in app notification. It fires once per crossing, re arms if you change the cap, and writes an audit row.

The in product copy is the honest version: "It's a heads-up, not a hard limit: Taskfolk never runs the model, so it can't stop the spend." The tokens are billed to your provider account by a process on your laptop or in your CI. A tracker claiming it could halt that would be lying.

What this does not do

Self reported figures can be wrong, or missing. An agent that never calls the usage endpoint leaves sessions with no cost, and no product design fixes a client that will not report.

There is no worklog. Time tracking is three aggregate numbers on the issue: an estimate, a spent figure, a completion percentage. No per entry timesheets, no start and stop records, no billable rates, no export. Tracking time on issues is the honest scope.

Cost renders per agent and per session. There is no per project cost page. You can get one by listing that project's sessions and summing them, which the API supports and the interface does not. API key usage and audit logs are a separate surface, covered in tracking API usage and audit logs.

Two things that will not move your Taskfolk bill: connecting more agents, and running them harder. Agent members are excluded from seat counting, which the seats post works through, and delegating work to an agent covers the assignment flow that opens these sessions.

If you already have an agent connected, add the usage call to the end of its run loop and leave it a week. Cost per completed ticket, and the ratio of bucket one to bucket three, will tell you more than any benchmark somebody else published.