---
title: 'Cost control, reframed: "AI spend is the new headcount"'
description: >-
  AI spend scales like headcount, not SaaS: usage-based, salary-sized, and
  ungoverned. Why cost control is really an observability question.
date: '2026-06-09'
authors:
  - Alex Che
categories:
  - Pydantic Logfire
  - Pydantic AI Gateway
canonical: 'https://pydantic.dev/articles/ai-spend-is-the-new-headcount'
---

> Markdown version of [Cost control, reframed: "AI spend is the new headcount"](https://pydantic.dev/articles/ai-spend-is-the-new-headcount) — the canonical HTML page.
>
> By Alex Che · 2026-06-09 · Pydantic Logfire, Pydantic AI Gateway
>
> Related: [You've built this agent before](https://pydantic.dev/articles/harness-week.md) · [Your traces already know how to fix your prompt](https://pydantic.dev/articles/logfire-prompt-optimization.md)
>
> All articles: [/articles.md](https://pydantic.dev/articles.md) · Site index: [/llms.txt](https://pydantic.dev/llms.txt)

---

<!--
Title renders from the frontmatter above; the H1 and working-frame note below are kept here as author scaffolding and do not render.

# Cost control, reframed: "AI spend is the new headcount"

Working frame: the spend is the symptom, not knowing what your agents did is the disease. Register: we. Reader: VP Eng or CTO at a Series A/B/C company (20 to 500 engineers), multiple product teams shipping AI, agents in production, AI line climbing to 6 figures or over, finance starting to ask pointed questions. Length target: ~1,050 words, ~5 min read. Theses preserved as blockquotes; prose written below each. Style follows the extracted voice guide.
-->

## The line nobody owns

<!-- Theses:
1. A finance team finds, somewhere mid-quarter, that the AI tools line has quietly outgrown a senior engineer's salary, and nobody can quite say which team or product owns the burn.
2. The shape of AI spend, we want to argue, has more in common with headcount than with SaaS: it scales with usage, lands in salary-order magnitudes, and accumulates faster than the review cycle that should govern it.
-->

Somewhere mid-quarter, a finance person opens a spend report and notices something. The line labelled "AI tools" has been climbing, quietly, month over month, for long enough that the rate is no longer the interesting bit; what is interesting is the absolute number. They cross-check it against the salary band for a senior engineer, and the AI line, it turns out, is bigger. They ask the obvious question, which team owns this, and the answer comes back fuzzy. Quite a few teams use it, in their own ways. Nobody, in any precise sense, owns it.

The claim we want to put down is that **AI spend has the wrong shape to be governed like SaaS, and the right shape to be governed like headcount.** It scales with usage, so it does not behave like a flat subscription. It lands in salary-order magnitudes, which means the numbers it produces would, in any other context, prompt a hiring discussion. And it accumulates between the review cycles you have set up to catch this kind of growth, so by the time anyone looks, the line is already there.


## Headcount-shaped, SaaS-governed

<!-- Theses:
3. The trouble is that the governance machinery around it is still the SaaS machinery: a card-on-file, a renewal someone approved once, an annual review that misses the daily reality.
4. Nobody owns the line on the P&L, because everybody is using it a little, and the right question, who decides how much of this we should be doing, has no obvious home.
-->

The trouble, and we have heard this from quite a few platform leads now, is that the governance machinery around AI spend is still the SaaS machinery. A card on file. A renewal that someone approved once, eighteen months ago, on a Tuesday. An annual review that aggregates the line into "tooling" and moves on. That machinery works well enough when the underlying service costs roughly the same every month, and it breaks quietly when the underlying service costs an unpredictable amount every day.

There is a related, slightly subtler problem: nobody owns the line on the P&L. Headcount, by contrast, has owners. Somebody hired the person, somebody signs off on the renewal of their contract, and somebody is responsible if the team turns out to be the wrong shape for the work. AI spend has no equivalent owner, because everybody is using it a little. So the question that should be asked, who decides how much of this we should be doing, has no obvious home, and it gets asked, oftentimes, by finance after the fact.


## Observability wearing a CFO hat

<!-- Theses:
5. Cost, framed this way, is really observability wearing a CFO hat, because the only way to govern spend at this shape is to know what each call was actually for.
6. We have been watching the subsidy era visibly come to an end (the IPO filings, the price moves, the meter being switched on across the industry at once), and the slack that hid this problem is leaving the system.
-->

If AI spend is shaped like headcount, the only honest way to govern it is to know what each run was actually for. Which is **an observability question dressed up as a finance one**. The shape of the answer, which agent ran, which user it served, which tool it called, what came out the other side, is the shape of a trace, not the shape of a finance report. The CFO needs the data eventually; the work of producing it lands on engineering, who oftentimes are the only people in the building who can.

There is a timing piece worth naming, because it changes the urgency. We have been watching the subsidy era visibly come to an end. Inference prices that used to drift downwards every quarter have stopped drifting. The major model vendors have begun moving towards public markets, which means the patience of their balance sheets is no longer infinite. The meter, in other words, is being switched on across the industry at roughly the same time. The slack that hid this problem, the slack that let teams be a bit careless because the unit cost was small, is leaving the system.


## What seeing it changes

<!-- Theses:
7. What changes when you can see the spend per agent, per user, per session, is that the conversation moves from "should we cap this" to "is this run worth what it cost", which is a much more useful question.
8. The gateway shapes spend at the edge, and Logfire is where the visibility lives: gateway and applications both emit into the same trace, so the spend you are governing and the runs you are reading sit on the same record.
9. This is the loop we keep coming back to with customers: shape at the edge, read in the observability surface, shape again, and the CFO question and the engineering question end up looking at the same data.
-->

What changes when you can see the spend per agent, per user, per session, is that the conversation moves up a level. The default question, when finance first notices the number, is "should we cap this?". That question has a clean answer, yes or no, and it does not need much detail. The more useful question, which only opens up once you have visibility, is "is this run worth what it cost?". That question is harder, but answering it across enough runs is what tells you whether the agent you have built is doing the work you think it is doing.

We have two surfaces that pull on this, and it is worth being plain about what each one does:

- **[Pydantic AI Gateway](https://pydantic.dev/ai-gateway?utm_source=pydantic.dev&utm_medium=internal&utm_campaign=ai-spend-is-the-new-headcount&utm_content=inline)** is the edge. Once you can see where the spend is going, you tend to want a single point through which to shape it, with server-side limits at the org, project, user, and session level, composed cleanly rather than scattered across team configurations.
- **[Pydantic Logfire](https://pydantic.dev/logfire?utm_source=pydantic.dev&utm_medium=internal&utm_campaign=ai-spend-is-the-new-headcount&utm_content=inline)** is where the visibility lives. The gateway emits into it, your applications emit into it, and what shows up on the trace is the model call, the tools it touched, the data that came back, the latency, the errors, and the cost.

The coding agents driving a good slice of this spend work well with both surfaces too. [Claude Code](https://github.com/pydantic/claude-code-logfire-plugin) and [Codex](https://pydantic.dev/articles/codex-logfire-plugins?utm_source=pydantic.dev&utm_medium=internal&utm_campaign=ai-spend-is-the-new-headcount&utm_content=inline) can both run through the gateway and emit into Logfire.

This is the loop we keep coming back to in customer conversations. You see the spend in Logfire, you shape it at the gateway, you watch the next run, you shape again. The thing that makes this work as one practice rather than two products is that both surfaces are connected. The CFO question (was this run worth it) and the engineering question (did the agent do what we asked) stop being two separate investigations and start being two views of the same trace, which is, ultimately, the only way a fast-moving practice has any chance of staying coherent.


## So what

<!-- Theses:
10. We end where this started: the spend is loud, but the silence underneath it, the not-knowing what your agents did, is the part that should worry you.
-->

We end where we started: a finance person staring at a line in a spend report. The spend is the loud part, the part that prompts the meeting and gets escalated, and most orgs are at least watching it now. The quieter problem, and the more expensive one over time, is not knowing what the agents did, on whose behalf, with which data, to what result. The spend is just the symptom. **Real cost control starts there: make the runs underneath the line visible, then shape them, because that is the part you can actually act on.**

---
 If your AI line just crossed a senior engineer's salary and the ownership conversation is fuzzy, that is the conversation we constantly have. Talk to us about Logfire and the AI Gateway (https://pydantic.dev/contact?utm_source=pydantic.dev&utm_medium=internal&utm_campaign=ai-spend-is-the-new-headcount&utm_content=cta-contact). We will help you stand up the visibility first, then the controls.
