Where AI tool costs belong in project margin
Seats and metered model spend are different costs. One is overhead, the other follows the work, and only one of them belongs on a client project.
Ask a delivery lead what a project cost and you will get an answer built from hours and rates. Ask what the AI on that project cost and the usual answer is a shrug, followed by a monthly invoice from each tool vendor that nobody has broken down by client. The money is real. It just lands in a general software line, a long way from the work it paid for.
That was fine when AI spend was a few seats and a rounding error. It stops being fine once agents run batch work on client projects and the metered bill moves with the work. At that point a fixed-fee project can lose its margin to model spend, and the first anyone hears of it is the quarterly accounts.
Two kinds of AI cost, and they belong in different places
Most of the confusion comes from treating every AI cost as one kind of thing. There are two, and they behave differently.
| Seat licences | Metered model spend | |
|---|---|---|
| How it is charged | Per person, per month, whatever the use | Per token or per call, as the work happens |
| Does it move with the work? | No | Yes |
| Where it belongs | Overhead, in the rate or the fixed-fee buffer | On the project and workstream that used it |
| What to record | Who holds a seat, and the monthly total | Tool, model, tokens and cost for each AI session |
A seat costs the same whether the person spends the month on one client or five, so it behaves like a laptop or a design licence. Metered spend is closer to a freelancer's invoice: it exists because a particular piece of work happened, and it should sit with that work.
Metered spend follows the session
The clean way to put metered spend on a project is not to allocate it at all. Record it where it happened. Every AI session has an observable cost: the tool, the model, the tokens in and out, and what they were billed at. Attach that session to the time entry a person logged for the same work, and the cost inherits everything the entry already carries: client, project, workstream, date.
This is why the work record matters more than the vendor invoice. The invoice knows which API key spent the money. It does not know which client the work was for. The time entry does. Join the two at the session, and project margin picks up model spend with no spreadsheet in between.
Agent work that runs with nobody at the keyboard follows the same rule. The run has a person who started it and a project it was for, and its cost goes there. Agent runs are not timesheets covers what that record needs to hold.
Seats are overhead until you decide otherwise
The tempting move is to take the monthly seat total and spread it across projects in proportion to the hours AI touched on each. Resist it. A seat is paid for whether it is used or not, so the result is a number that moves when usage moves and has nothing to do with what the work cost. It looks like evidence and it is an allocation rule.
Put seats where the rest of your software goes: in the loaded cost behind your day rate, or in the buffer you add to a fixed fee. If a client has asked for a dedicated tool, or a project needs a seat nobody else uses, that seat belongs on the project. Otherwise it does not.
What the margin view should show
Once metered spend sits on the entries, a project's cost view can show three things side by side, each of them observed rather than estimated.
- Human cost. Hours worked at loaded rates, as before.
- Model spend. The sum of AI session costs on the project's entries, split by workstream.
- Hours AI touched. Time entries with at least one AI session on them. This says where AI was present, not how much of the work it did.
Keep this view at project and workstream level. A per-person model spend figure invites exactly the wrong conversation, about who is using too much or too little, when the useful question is whether the work was scoped and priced for what it needed. The person sees their own sessions. The owner sees the totals.
An illustrative example
The numbers here are illustrative. A twelve-person agency pays for twelve assistant seats at $30 a month each, $360 in total, and carries it as overhead. It also has metered model spend, which it attaches to time entries through the AI sessions recorded on them.
At the end of the month, a fixed-fee website rebuild shows $840 of model spend across two workstreams: $120 on the design system and $720 on content migration, where an agent rewrote several hundred legacy pages in batches, each batch started and reviewed by one of the team. Nothing about that is wrong. But the fixed fee was quoted from a migration estimate that assumed the work would be done by hand, with no model spend in it.
The margin is still healthy, because the human hours on migration came in well under the estimate. What the agency changes is the quote. The next migration proposal carries model spend as its own line in the cost build-up, and the fixed fee is set with both numbers in view. The client never sees a token count. The agency just stops guessing.
How that cost reaches the client, if it reaches them at all, is a commercial choice. How to invoice AI-assisted work compares the options. Whichever you pick, it starts with knowing the number.
Where to start this month
- List every AI tool you pay for and mark each one as seat or metered. Some are both.
- Move seats into overhead and stop reporting them per project.
- Record metered spend per session on the time entry it belongs to, starting with the one project where agents do the most batch work.
- Review model spend per workstream at the end of the month, beside human cost, and look for the workstream the quote did not expect.
None of this needs a finance project. It needs AI sessions recorded on the work they were part of, which is the same record that answers a client's questions about AI. Cost per client is one more thing it can say.