Direct answer: There is no universal normal, and anyone quoting one dollar figure is usually selling it. Normal for your org is a baseline you build yourself, by measuring spend per engineer, per team, and per workflow, then watching those numbers move. The useful question is whether your spend is scaling with real work or with retries and runaway loops.
The most common question a finance partner brings to an engineering leader right now is some version of "what should we be spending on AI per engineer," and it almost always arrives with a benchmark attached. A report said forty dollars a head. A vendor said two hundred. A peer at a dinner said their team runs at fifty. Every one of those numbers is real for the org that produced it and worthless for yours, because AI spend per engineer depends on things that vary wildly between companies. What the engineers are building, which agents they run, how much of the work is automated versus interactive, and whether the workflows are tuned or leaking. A single benchmark flattens all of that into one figure and then sells you the figure.
So the frame I use is a baseline, not a benchmark. A benchmark is someone else's number that you measure yourself against. A baseline is your own number, established over a few months, that you measure your future self against. The whole value is in the trend and the breakdown, not the absolute figure, and this post is a method for building that baseline at three levels so you can tell healthy scaling apart from waste.
Why every quoted per-engineer number is wrong for you
A per-engineer AI spend figure is an average of an average, and both layers hide the truth. The first average smears together engineers who run agent loops all day and engineers who ask a model three questions a week. The second smears together workflows that succeed cheaply and workflows that fail expensively. By the time you have a single dollar-per-head number, you have averaged away every signal that would tell you whether the spend is good.
There is also a compounding reason the number cannot be universal. AI spend is dominated by how much automated, agent-driven work an org runs, and that varies by orders of magnitude between companies of the same headcount. An org where engineers use AI as an occasional assistant and an org where agents run continuously in CI both have engineers, and their per-engineer spend will differ by more than any benchmark's range. Comparing yourself to either tells you nothing, because the mix that produced their number is not your mix.
Build the baseline at three levels
Start with spend per engineer, but treat it as the coarsest of three lenses rather than the answer. To get it honestly you need spend attributed to people, which means capturing usage from every source your engineers touch, the coding agents like Claude Code and Cursor, the direct provider APIs, the internal tools, and routing it back to an identity. Attribution is the whole game here. A bill from Anthropic or OpenAI tells you the org total. It cannot tell you who or what spent it, and without that you have no baseline, only a sum.
The second level is spend per team, and this is where the number starts to mean something. Teams have coherent work, so a platform team, a product team, and a data team will each settle into a different steady state, and those steady states are the real baselines. A team's spend per engineer compared against its own past is a signal you can act on. The same team's spend compared against a stranger's team is noise. Once each team has a few months of its own history, you can see which teams are drifting up faster than their work justifies.
The third level is spend per workflow, and this is where waste actually becomes visible. A workflow is a repeated way of getting a task done with a model, and it is the smallest unit where spend and value line up. When you can see cost per workflow, you can ask the only question that matters for cost control, which is whether each workflow's cost is tracking the work it produces or climbing on its own. The per-engineer number can only raise an alarm. The per-workflow number tells you where the fire is.
Separate healthy scaling from runaway loops
With the three levels in place, most of the diagnosis reduces to one distinction. Spend that grows because engineers are attempting more ambitious work is healthy, and it shows up as rising cost alongside rising completed tasks and stable cost per successful task. Spend that grows because an agent is stuck is a runaway loop, and it shows up as rising cost with flat or falling completed work, often concentrated in one workflow or one automated job that retries forever.
Runaway loops have a fingerprint you can watch for. A single workflow's token volume climbs sharply while its first-try success does not, or an automated agent job runs the same tool call in a cycle without converging, or repeated context balloons because the loop resends the same growing history every turn. None of these are visible in a per-engineer average and all of them are obvious in per-workflow, real-time data. This is also why month-end billing is too slow for cost control. A loop that runs for two weeks before the statement arrives has already spent the money. The point of a baseline is to catch the deviation from it while you can still act.
One honesty rail to hold onto if you go looking for a comparison anyway. Any percentile you compute, the engineer at the ninetieth percentile of spend, the team above the median, is relative to your own population and nothing more. It is a way to find the outliers inside your org, not a verdict that anyone is spending too much against some external standard. And if you ever do want an illustrative figure to sanity-check tooling, treat it as illustration only. A range like twenty to a few hundred dollars per engineer per month exists in the wild, but the spread is so wide that the number teaches you nothing. Your baseline teaches you everything.
Oberhahn builds this baseline for you by attributing live AI spend to engineers, teams, and workflows from the sources you already run, so healthy scaling and runaway loops separate visibly instead of hiding in a month-end total, and you can explore it on a sample-data demo before connecting anything real.
Frequently Asked Questions
What is a normal AI spend per engineer?
There is no universal normal, and a single quoted figure usually reflects the org that produced it rather than yours. Normal for you is a baseline you build by measuring spend per engineer, per team, and per workflow over a few months. The question worth asking is whether the number is scaling with completed work or with retries and runaway loops, which only the per-workflow breakdown can show.
Why can't I just compare my per-engineer spend to an industry benchmark?
Because AI spend is dominated by how much automated, agent-driven work an org runs, and that varies by orders of magnitude between companies of the same size. A benchmark averages away the mix that produced it, so comparing your number to it tells you nothing about whether your spend is healthy.
How do I tell healthy AI spend growth from waste?
Healthy growth shows rising cost alongside rising completed tasks and stable cost per successful task. Waste, usually a runaway agent loop, shows rising cost with flat or falling completed work, often concentrated in one workflow that retries without converging or resends growing context every turn. You need per-workflow, real-time data to see the difference.
How should I use per-engineer or per-team percentiles?
Only to find outliers inside your own org. A percentile is relative to your own population, so the ninetieth-percentile engineer is simply the high end of your team, not someone overspending against an external standard. Use it to start a conversation, not to render a verdict.