A developer at a consultancy starts Claude Code on a client's repository, describes a change, and goes to a meeting while the agent works. Forty minutes later the change is ready for review. Whose time was that, which client does it belong to, and should the client pay for it?
Most firms answer by not recording it at all. The developer logs the review they did afterwards, and the agent's working time disappears. That is fine until a client asks why a project with fewer people delivered more, or a fixed-fee job turns out to have depended on hours nobody measured.
This post sets out a workable approach: record agent time as its own kind of time, credit it to the person who launched the agent, price it at a rate of its own, and decide whether it is accepted automatically or held for a person to review.
Treat it as supporting agent time
An agent working in a repository did not choose the client, accept the brief or answer for the result. A person did. So the most useful way to record the work is as supporting agent time: time the agent spent working, credited to the person who launched it and responsible for it.
That framing settles several questions at once:
- Attribution. The time belongs to the person who ran the agent, on the project that person was working on.
- Accountability. The same person reviews it, corrects it and answers for it, as they would for their own entry. That is the heart of agent accountability.
- Separation. It is not that person's own hours. It should not count toward their utilization, their capacity or their timesheet total, or a developer who runs two agents in parallel will look like they worked a 20-hour day.
Decide what counts as working time
Wall-clock time from opening a session to closing it overstates the work badly. A session left open overnight is not twelve hours of effort.
A better measure is the sum of the agent's turns: a turn starts when somebody submits a prompt and ends when the agent stops. The gaps between turns, while the person reads, thinks or is away, are not agent work. Neither is the time an agent spends waiting for somebody to approve an action.
This is how Time Trakkr's agent time measures it for Claude Code. On Codex, time spent waiting at a permission prompt is counted, because Codex does not report it reliably.
Map repositories to clients, not people to clients
Asking every developer to pick a client and project for every agent session reproduces the problem of manual timesheets, with more sessions. The repository already knows which client the work is for.
So the mapping lives at the repository: this repository, on these branches, belongs to this project and task. A session in a mapped repository is recorded there. A session in an unmapped repository is not recorded at all, which keeps personal side projects and internal tools out of client billing by default.
A worked example
A four-person studio bills human time at $150 an hour. It sets an agent rate of $60 an hour to bill and $12 an hour as its cost, and rounds invoice lines to 15 minutes. In one week on the Acme project:
| Work | Hours | Rate | Billed |
|---|---|---|---|
| Priya, design and development | 30.0 | $150 | $4,500 |
| Jonas, development and review | 12.0 | $150 | $1,800 |
| Priya's agent time (Claude Code) | 6.5 | $60 | $390 |
| Jonas's agent time (Codex) | 3.25 | $60 | $195 |
| Total | $6,885 |
The two agent lines are separate from the people's lines on the invoice. Profitability costs them at $12 an hour, so the 9.75 agent hours cost the studio $117 against $585 billed. Priya's and Jonas's own hours stay at 30 and 12, not 36.5 and 15.25, and their utilization is worked out from those.
None of these numbers is a recommendation. The point is that each kind of time has its own rate, its own cost and its own line, so a client and a project manager can both see what happened.
Accept it automatically, or hold it for review
Some sessions will be experiments, some will be on the wrong project, and some will have run far longer than the work was worth. So decide how agent time becomes billable, rather than leaving it to the default.
In Time Trakkr, sessions from a repository an admin has mapped are accepted automatically once the day has ended, unless an admin turns that off. An entry accepted this way is marked accepted automatically on its person's timesheet. Until it is invoiced, they can reduce it, move it to another project or delete it; deleting it puts the time back in their pending list. Once it is on an invoice it is locked, like any entry. Nobody reviews it before it is accepted.
Turn automatic accepting off and every session is held in its person's pending list instead, with its project, branch and duration. They accept it, move it to another project first, or discard it. Either way, an entry can be reduced but never raised above what the agent measured.
If your firm's policy is that a person looks at agent time before it can be billed, turn automatic accepting off.
Agree it with the client first
Recording agent time does not settle whether to bill it. Before the first invoice with agent lines on it, decide with the client:
- whether agent time is billed at all, or tracked for your own margin and left off the invoice;
- what the agent rate is and how it relates to human rates;
- how agent lines will be labeled and what level of detail the client sees.
If the agreement is that agent work is included in the human fee, record it anyway and mark it not billable. You still learn what the project actually took.
What this will not do
Time Trakkr records Claude Code and the Codex CLI running on a person's own machine. It does not record agents that run in the cloud, and the Cursor plugin has never been run against a real Cursor session, so treat Cursor as unsupported. It never records prompts, file contents or diffs. And it measures time, not value: an agent hour that produced nothing useful costs the same as one that shipped a feature, which is exactly why the review step matters.
Common questions
Should agent time count toward a person's utilization?
No. Utilization measures how a person's own working hours were spent. Agent time sits beside it as a separate figure, so a person who runs agents does not look overloaded and a person who does not run them does not look idle.
Can we track agent time without billing it?
Yes. An agent rate rule can be set to track but never bill. The time still appears in budgets and profitability at its cost rate, so you learn what the work cost even when the client does not pay for it separately.
What happens if an agent runs on a repository we have not mapped?
Nothing is recorded or sent for it, not even the repository's name. Only mapped repositories produce agent time.
Do managers see what each session was about?
No. On the Approvals page, managers and admins see how many sessions each person has waiting and how much time, and nothing about what the sessions were. They cannot accept or discard anybody else's agent time either.
