# See what your coding agents cost, and what they shipped

> Agent Insights ties Claude Code, Codex and Cursor spend to tasks, project budgets and merged PRs, itemizes token waste by cause, and recommends fixes.

Source: https://entelligence.ai/blogs/coding-agent-analytics-agent-insights
Updated: 2026-11-05

- Author: Aditya Jha
- Published: 2026-11-05
- Tags: AI in Software Development, Insights

A CTO told Faros AI's CEO, as [TechCrunch reported](https://techcrunch.com/2026/06/05/the-token-bill-comes-due-inside-the-industry-scramble-to-manage-ais-runaway-costs/): "One of my engineers spent $40,000 on tokens last month, and I genuinely don't know whether I should stop him or should I go and tell everyone else to be like him."

That question has two halves. What did the $40,000 buy, and is the way that engineer works worth copying? An invoice answers neither. It lists tokens per account and per model. It has no idea which project the spend belonged to, whether the work shipped, or how much of it went on an agent re-reading context it saw an hour earlier.

The question is getting expensive to leave open. In the same TechCrunch piece, Uber "blew through its entire 2026 AI coding budget by April". [The Pragmatic Engineer](https://newsletter.pragmaticengineer.com/p/the-pulse-token-spend-breaks-budgets) talked to developers at 15 businesses and found token spend up about 10x in six months at two of them. Our own [Token Maxxing Report](https://research.entelligence.ai/), built on 1M+ pull requests across 2,444 engineering organizations, found that just 18 cents of every AI coding dollar becomes shipped product.

Agent Insights is how we answer both halves. It reads every Claude Code, Codex and Cursor session, splits it into tasks, and ties each task to a project budget, the tokens that did no work, and the pull request it led to. This post walks through how that pipeline works, what each number means, and how per-person data stays a coaching tool.

**The short version**

- Capture: Agent Insights reads session files from Claude Code, Codex and Cursor on the developer’s laptop. By default the transcript stays there.
- Tasks: every session splits into tasks. Every task gets a work type, a cost, behavior signals and a link to the pull request it fed.
- Budgets: every Linear or Jira project can carry a monthly budget with an email alert before it runs over. Spend rolls up by project, repo, model and person.
- Waste: token waste is itemized by cause, as compaction, interrupts, repeated edits and failed retries. Much of it comes from repo setup, so one fix helps the whole team.
- One graph: sessions land in the Entelligence world model next to pull requests, tickets, deploys and incidents, so Code Review, Model Router and Ask Ellie read the same records.

### What is coding agent analytics?

**Coding agent analytics** measures what AI coding agents such as Claude Code, Codex and Cursor cost, and what that spend produced. Usage dashboards count tokens per user and model. Coding agent analytics goes one level down: it splits each agent session into tasks and attributes every task’s cost to a project, a pull request and an outcome.

Four numbers come out of that unit: cost per task and per project, spend against a project budget, the share of tokens that did no work, and how much of the spend reached merged code. Agent Insights is the Entelligence product that produces them.

### What a provider bill can’t tell you

A tokens-per-engineer chart has the same gap as the invoice. An agent working through a nasty race condition and an agent running the same failing command for forty minutes burn the same tokens. The chart cannot tell them apart.

So Agent Insights answers four questions about every session, then rolls the answers up per project:

- **What was it trying to do?** The task and its work type.
- **What did it cost, and against which budget?** Dollars per task, project and repo.
- **What happened while it ran?** Behavior signals and the tokens that did no work.
- **Did the work land?** The pull request and ticket it fed, and whether it merged.

### Every session lands in the world model

Usage dashboards stop at the session. Agent Insights files each session into the Entelligence world model: one graph per organization of sessions, tasks, pull requests, tickets, deploys and incidents. Agent Insights writes the session, task and cost records. The other Entelligence products read them.

That graph is what makes the joins in this post possible. Linking a task to its pull request, tracing a review finding back to the task that wrote the file, and rolling spend up to a project are all queries on the same graph. Cost travels along the same edges, so “what did this project cost in agent spend, and what shipped?” is one question instead of a spreadsheet.

_Image: Diagram of the Entelligence world model at the center, a graph of sessions, tasks, pull requests, tickets, deploys and incidents, with Agent Insights writing to it and Code Review, Model Router, Ask Ellie and coding agents reading from it (Agent Insights writes sessions, tasks and cost into the world model. Code Review, Model Router, Ask Ellie and your coding agents read the same records.)_

### Capturing sessions where they run

Claude Code, Codex and Cursor all keep detailed session files on disk, so there is no proxy to route traffic through and no IDE plugin to install. The [Ellie CLI](/cli) reads those files:

```bash
curl -fsSL https://cli.entelligence.ai/install.sh | sh
ellie auth login
ellie insights sync
```

The first sync imports up to 30 days of history. After that it syncs daily. By default the parsing happens on the developer’s laptop, and what goes up is derived data per task: tool calls, token counts, cost, files touched and signals. The backend works from the shape of a session, not its contents.

_Image: Agent Insights pipeline in five steps: session files from Claude Code, Codex and Cursor, parsed by the Ellie CLI on the laptop, split into tasks with work types and signals, matched to a pull request and ticket, and classified as shipped, pending or non-productive (From session file to outcome. Everything downstream is keyed on the task.)_

### Budgets and spend, per project

Spend comes first, because it is the first question anyone outside engineering asks. The goal is an ROI number, not a token count.

Set a monthly budget on any Linear or Jira project. Agent Insights attributes every session to its project and repo, tracks the month against the budget, and emails the project owner at the threshold you pick, while there is still time to act. The Budget view leads with four numbers: total monthly budget, actual spend, projects over budget, and untracked spend. Untracked spend is the share no project claims, and it stays in the totals. Dropping it would make every ratio look better than it is.

_Image: Budget view with a $12,000 monthly budget across 8 projects, $8,421 spent, 2 projects over budget and $1,240 untracked spend; Payments API is at 143% of budget and Growth Web triggered a 75% threshold alert (The Budget view: spend per Linear and Jira project against its monthly budget, with a threshold alert. Sample data.)_

The same dollars regroup by project, repo, model or person. On our own workspace, 95.5% of usage attributes to a repo. Cost per merged PR sits next to spend, so a project that is over budget and shipping reads differently from one that is over budget and stuck.

_Image: Monitored usage by repository with 95.5% attribution, listing tokens and sessions per repo, next to monitored usage by Linear project (Usage by repository and by project on our own workspace, with the share of tokens attributed to a repo.)_

For teams on plans with a weekly usage window, Capacity shows who is on pace to run out before the reset, so a seat can be moved before someone gets blocked. For the planning side of this, see [how engineering teams can actually budget for AI usage](/blogs/how-engineering-teams-can-actually-budget-for-ai-usage).

### Splitting sessions into tasks

A session is a poor unit to compare. Someone opens Claude Code, fixes a bug, asks it to explain a module they have never touched, then rewrites a flaky test, all in one session. Someone else spreads one feature across three sessions because they hit a context reset or switched from Cursor to Claude Code after lunch.

So each session splits into tasks first. A task is one goal, with its own turns, tool calls, files and cost. Each task gets a work type:

| Work type | What lands here |
| --- | --- |
| Features | New behavior headed for a pull request |
| Fixes & rework | Bug fixes, plus changes to recently written code |
| Tests & reviews | Writing tests, responding to review, verification |
| Exploration & overhead | Investigation, spikes, questions, setup |

Exploration gets its own bucket so a spike does not count as a failed feature. Finding out that an approach will not work is useful even without a pull request. Sessions with no task at all, like a one-line question or an abandoned start, get an explicit “no task” verdict.

Because every task carries its own cost, spend splits by work type too, and that is where ROI shows up. On our own workspace last month, exploration and overhead was the biggest bucket: 1,433 of 2,886 agent tasks, or half. Features were 15%.

_Image: Outcome breakdown of 2,886 agent tasks: features created 420 (15%), fixes and rework 872 (30%), tests and reviews 161 (6%), exploration and overhead 1,433 (50%) (The Outcomes view on our own workspace, last month.)_

The Outcomes tab also tracks spend by work type over time, weighted by dollars rather than task count. Each task links to the pull request or ticket it fed, so you can see how much of the month’s spend reached shipped work, and whether that share is moving.

_Image: Spend by work type over time, weighted by spend, from September 28 to November 2: exploration and overhead falls from above 90% toward 45% while features created rises toward 30% (Spend by work type over time on our own workspace.)_

### Behavior signals: what happened while the agent ran

The Team driving style panel shows how a team uses its agents: reads before editing, files read per change, searches per change, steps per instruction, whole-file rewrites and retried failures. Each metric has a guideline range and reads as on track, below or above. The ranges are guidelines, not benchmarks to rank anyone against.

_Image: Team driving style panel: reads before editing 63%, files read per change 0.7, searches per change 0.1, steps per instruction 6.9, whole-file rewrites 22%, retried failures 3.1%, each against a guideline range (Team driving style on our own workspace.)_

Underneath sits a catalog of 23 detectors that runs on every task. Each one asks a yes or no question about the task’s tool calls, simple enough that an engineer can open the trace and check the answer. Five of them, with the thresholds counted inside a single task:

| Signal | Fires when | Usually means |
| --- | --- | --- |
| `blind_edit` | Edits a file it has not read | Stale context |
| `loop_no_progress` | 3+ errors in a row | Stuck repeating itself |
| `error_retry_sequence` | 5+ errored tool calls | Broken test command |
| `repeated_edit_waste` | 4+ edits to one file | Patch, test, re-patch |
| `many_edits_no_tests` | 5+ edits, no test run | Review does the testing |

The rest cover compaction, interrupts, permission prompts, tasks that read but never edit, and idle sessions. Codex logs less detail, so it sits out these comparisons. Its tokens still count toward spend and budgets.

One firing means nothing on its own. A big refactor trips `repeated_edit_waste`, and a normal TDD loop trips `error_retry_sequence`. A firing is a reason to open the trace. What matters is how often a signal fires across a repo, and whether that rate drops after a fix.

#### Why every threshold has a version

Our first cost-runaway detector fired at 100k prompt tokens per task. Then 1M-token context windows went mainstream and it fired on ordinary tasks. We raised it to 250k, then to 20M, where it picks out tasks that are genuinely deep. Every detector now carries a version number, so when a chart jumps we know whether behavior changed or the definition did.

We have also moved toward detectors that look for patterns over size. Three errors in a row means the same thing on any model. A token threshold goes stale with every new context window.

### Token waste, itemized by cause

Every turn resends the whole conversation to a stateless API, so most tokens in a long session are old context. We covered the mechanics in [where AI coding agents waste tokens](/blogs/where-ai-coding-agents-waste-tokens-and-why-it-matters). Most of that is unavoidable. Token waste by cause pulls out the part that is not:

| Cause | What it is | Typical fix |
| --- | --- | --- |
| Compaction | Context rebuilt after a full window | Smaller tasks, trimmed output |
| Interrupts | Stopped before it finished | Plan before execute |
| Repeated edits | Same file edited again | Read before edit |
| Failed retries | Calls repeated after an error | Fix the failing command |

None of this shows up on a provider bill, and a lot of it comes from the repo rather than the person. If the test command in the agent instructions points at the wrong directory, every engineer’s agent hits the same error until someone fixes that one line.

On our own workspace over the last 30 days, the view counted 3.9B wasted tokens. Compaction was 75% of them, repeated edits 15%, failed retries 8% and interrupts 1%.

_Image: Token waste by cause: 3.9B wasted tokens, of which compaction is 75.2%, repeated edits 15.2%, failed retries 8.4% and interrupts 1.2% (Token waste by cause on our own workspace, last 30 days.)_

The daily chart shows when it happened, which is usually the fastest way to find the session behind a spike. The AI Context Health card next to it tracks context pressure, duplicate reads per session and edit thrash per session. In the terminal, `ellie ledger` lists one row per session: what it worked on, what it cost, how much was avoidable, and the pull request it led to, or “no PR”.

_Image: Daily token waste by cause from October 4 to November 3, stacked by compaction, interrupts, repeated edits and failed retries, with a Suggest fixes button in the corner (Daily token waste on our own workspace. Suggest fixes, top right, turns the org’s own breakdown into recommendations.)_

### How we check that a signal predicts anything

A signal earns a place on the dashboard only if tasks that trip it go worse. To check, we use the world model to trace each [Code Review](/code-review) finding back to the agent task that edited the file, then compare how often tasks with and without each signal drew a finding. That ratio is the lift. This view runs on our own workspace today, as the test every detector has to pass; it is not in the customer product yet.

On our workspace from October 4 to November 3, 2026, tasks that tripped a signal called “Bash heavy” drew a finding 4.7% of the time (484 of 10,337), against 1.5% without it (60 of 4,022). That is a lift of 3.1x.

_Image: Review signal outcomes table: Bash heavy has a 3.1x lift across all repositories, 484 of 10,337 findings with the signal against 60 of 4,022 without, October 4 to November 3, 2026 (Review signal outcomes on our own workspace, October 4 to November 3, 2026.)_

Filter by repo and kind of finding. Small samples are hidden by default. Lift is a correlation, not a cause: a high lift shows where to look first in the agent setup, and a lift near 1x means the signal says nothing about that repo.

### From dashboard to fix

Dashboards say what happened. Three parts of Agent Insights point at what to change.

The Agents Summary states its findings in plain English. Detectors mine the graph for patterns like token concentration, cost outliers and workload skew. When we wrote this post, ours said:

**96%** of all tokens came from the top 5% of sessions (So cost reviews should start with the heavy sessions.)

On the daily waste chart, Suggest fixes reads the org’s own waste breakdown and proposes changes for admins to make. Most of them live in the repo rather than with a person: if five engineers’ agents trip `error_retry_sequence` on the same repo, that is one broken test command, not five people doing it wrong.

When the same kind of task keeps coming up, Agent Insights suggests a skill for it. On our workspace, nine engineers ran 30 tasks on dashboard and analytics debugging, so it suggests one skill for that work.

_Image: Skills suggested to improve AI usage, each card showing how many engineers and tasks it covers, led by dashboard and analytics debugging with 9 engineers and 30 tasks (Skill suggestions on our own workspace, based on tasks that keep repeating across the team.)_

Every fix stays in the graph, so you can check it worked. Add a context rule to a repo and the compaction band for that repo should shrink within a week. If it does not, the chart says so. Every panel has an Ask Ellie button for the follow-up question, such as why compaction doubled on web-app this week.

### Per-person metrics without a token leaderboard

High-velocity teams ask for agent metrics per person: who is getting leverage from agents, who is stuck, and what the people getting leverage do differently. The question is what those metrics are for.

Token count is the wrong answer. Jellyfish’s Nicholas Arcolano, [as WorkOS reported](https://workos.com/blog/nicholas-arcolano-jellyfish-token-maxing-diminishing-returns), found the top 10% of engineers by token use “about twice as productive as the median”, at roughly 69M tokens per pull request against about 7M at the median. A spend ranking puts them on top for the wrong reason and teaches everyone else to burn tokens. Meta found that out in April, when it [shut down an internal token dashboard](https://fortune.com/2026/04/09/meta-killed-employee-ai-token-dashboard).

That is the second half of the CTO’s question: the useful thing to copy from a heavy user is how they drive their agents, not how many tokens they burn. Per-person views in Agent Insights describe exactly that:

- **Capabilities in use.** Sub-agents, plan mode, skills and MCP tools. On our workspace, plan mode adoption is 43%.
- **Driving style and efficiency.** Reads before edits, retries, steps per instruction.
- **Spend next to pull requests merged.** In the Members view, alongside Capacity and budgets, never on its own.

Access is role based. We use these views to find unused seats and to see who is about to hit a usage limit. The authors of the [SPACE framework](https://queue.acm.org/detail.cfm?id=3454124) warn against using activity metrics in isolation to reward or penalize developers. Spend is an activity metric, so Agent Insights always shows it next to an outcome.

### Ask Ellie in Slack, for every team that touches the spend

Most people who care about agent spend never open a dashboard. Finance wants the monthly number. A manager wants to know which project is about to run over. On-call wants the session behind last night’s bad deploy. So [Ask Ellie](/ask-ellie) answers from the same graph in Slack, the web app and the terminal, and links each claim to the record it came from.

- **Managers:** which projects go over budget this month, and why?
- **Platform teams:** which repo’s agent setup costs us the most in retries?
- **Finance:** what did Payments API cost in October, and what shipped?
- **On-call:** which agent session wrote the pull request in last night’s deploy?

_Image: Slack channel where a manager asks Ellie which projects go over their agent budget; Ellie answers that Payments API is at 143% with most spend on fixes and rework, names a failing test command as the biggest avoidable cost, and later posts a spend spike alert for one looping session (Asking Ellie about budgets in a team channel, and a spend spike alert. Sample data.)_

Ellie also posts in Slack when spend spikes, with the session behind it and a link to replay it in [agentplay](/agentplay). Budget threshold alerts go out by email.

### How this differs from provider dashboards and LLM gateways

Most teams already have one of these. Each answers a narrower question, and the gap is the unit of analysis:

|  | Agent Insights | Provider dashboard | LLM gateway |
| --- | --- | --- | --- |
| Unit | Task and its PR | User and model | API key |
| Agents | Claude Code, Codex, Cursor | One vendor | Routed traffic |
| Budgets | Per Linear or Jira project | Per seat | Cap per key |
| Waste | Itemized by cause | Not shown | Not shown |
| Outcome | Shipped or not, per task | Not tied to a task | Not tracked |
| Setup | CLI reads local files | Built in | A proxy |

A gateway is the right tool to cap a key. A provider dashboard is the right tool to see seat usage. Neither knows which project a session belonged to or whether its work merged, and that is the question finance and engineering leaders are asking.

### One graph, every product

Agent Insights is one way into the world model. The rest of Entelligence reads the same records:

- [Code Review](/code-review) checks every pull request against your codebase, team rules and resolved incidents, and supplies the findings we use to test detectors.
- [Model Router](/model-router) sends each turn to the most efficient model that can handle it. Reading a file or re-running a test rarely needs a frontier model, and the Usage by models view shows where your sessions ran.
- [agentplay](/agentplay) replays one session as a map and a timeline when you want to see why a signal fired.
- [Ask Ellie](/ask-ellie) traces a bad deploy to its pull request and incident, and from the pull request back to the task that wrote it.

Connect a repo once and all of them read the same graph.

### Your first week with Agent Insights

Agent Insights is in beta. A first week that gets you to a first measurable fix:

1. Install the CLI, run `ellie auth login` and `ellie insights sync`. You get up to 30 days of history.
1. Set monthly budgets on your three most expensive Linear or Jira projects.
1. Open your busiest repo and find the signal that fires most.
1. Click Suggest fixes on the waste chart and apply the top one. It is usually one line in `CLAUDE.md` or `AGENTS.md`.
1. Check the waste chart a week later. The band for that cause should be smaller.
1. Add Ellie to the channel where spend questions already come up.

**See what your agents cost, and what they shipped** Claude Code, Codex and Cursor in one view. Up to 30 days of history imported on the first sync. [Set up Agent Insights](/agent-insights)

Want a walkthrough on your own sessions first? [Book a demo](https://calendly.com/aiswarya-qlnt/1-1-aiswarya-1) and we will go through your first sync together.

### Frequently asked questions

#### What is coding agent analytics?

Coding agent analytics measures what AI coding agents such as Claude Code, Codex and Cursor cost and what that spend produced. Agent Insights does it per task: each session is split into tasks, and each task gets a work type, a cost, behavior signals and a link to the pull request it fed.

#### Which coding agents does Agent Insights support?

Claude Code, Codex and Cursor. The Ellie CLI reads their local session files. The first sync imports up to 30 days of history, and sessions sync daily after that.

#### How do budgets work in Agent Insights?

Set a monthly budget on any Linear or Jira project. Agent Insights attributes each session’s spend to its project and repo, tracks the month against the budget, and emails the owner when spend crosses the threshold you choose. Spend no project claims shows up as untracked spend instead of disappearing.

#### How does Agent Insights define token waste?

As tokens that did no work, in four causes: compaction (context rebuilt after the window filled), interrupts (work stopped before the agent finished), repeated edits (the same files changed again and again) and failed retries (tool calls repeated after an error).

#### Do session transcripts leave the developer’s machine?

By default, no. The CLI parses sessions on the laptop and sends derived data per task: tool calls, token counts, cost, files touched and signals. The transcript itself stays local.

#### Does Agent Insights rank engineers by token usage?

No. Spend per person appears next to pull requests merged, Capacity and budgets, never on its own.

#### How is this different from a provider usage dashboard?

A provider dashboard shows tokens per user and model for one vendor’s tool. Agent Insights covers Claude Code, Codex and Cursor together, attributes spend to tasks, projects, repos and merged pull requests, itemizes waste by cause, tracks project budgets and recommends fixes.

#### Can I ask about agent spend in Slack?

Yes. Ask Ellie answers from the same graph in Slack, such as which projects will go over budget this month and why, and posts an alert when spend spikes, with the session behind it.

### Sources

1. Rebecca Bellan, [The token bill comes due: inside the industry scramble to manage AI’s runaway costs](https://techcrunch.com/2026/06/05/the-token-bill-comes-due-inside-the-industry-scramble-to-manage-ais-runaway-costs/), TechCrunch, June 5, 2026.
1. Gergely Orosz, [The Pulse: token spend breaks budgets, what next?](https://newsletter.pragmaticengineer.com/p/the-pulse-token-spend-breaks-budgets), The Pragmatic Engineer, April 30, 2026.
1. Entelligence Research, [The Token Maxxing Report](https://research.entelligence.ai/), May 2026. 1M+ pull requests across 2,444 engineering organizations.
1. [Nicholas Arcolano (Jellyfish) on token maxing and diminishing returns](https://workos.com/blog/nicholas-arcolano-jellyfish-token-maxing-diminishing-returns), WorkOS, August 5, 2026.
1. [Meta killed its employee AI token dashboard](https://fortune.com/2026/04/09/meta-killed-employee-ai-token-dashboard), Fortune, April 9, 2026.
1. Forsgren, Storey, Maddila, Zimmermann, Houck and Butler, [The SPACE of Developer Productivity](https://queue.acm.org/detail.cfm?id=3454124), ACM Queue, 2021.

More: [Blog](https://entelligence.ai/blogs)