A lot of development work now looks like this: you read the ticket, write a careful prompt, and hand the job to Claude Code or Codex. For the next twenty minutes the agent reads files, runs tests and edits code. You watch, answer a question, stop it once when it heads the wrong way. Then you review the diff, fix two things and ship.
Your keyboard was still for most of that. Your time tracker probably called it idle. Your client is paying for the result. So what do you bill?
Is waiting on an agent work?
Start with the plain question, because the billing follows from it.
When you run an agent on a client's task, you chose the task, framed it, set the limits, and you're responsible for what comes out. You can't do much else while it runs: you're checking its plan, catching it when it goes off course, and waiting to review. That's the same as waiting on a long build or a deploy, and nobody seriously argues that a build you're babysitting isn't work.
So our view is yes: time you spend supervising an agent on a client's work is work on that client's job. That's also how Hourbrook counts it.
What doesn't count is the time you're not there. If you start an agent, close the laptop and go to dinner, the agent may have worked for two hours, but you didn't. Whether that is billable is a pricing question, not a time question.
Three ways to bill it
1. Hourly, waits included
You bill your normal rate for the time you were working on the job, including the stretches you supervised an agent. Time you weren't there isn't billed as hours.
- Good for: existing hourly clients, retainers, anyone who already trusts your timesheets.
- Watch out for: the client's natural question, “if the agent does the typing, why is this still six hours?” The honest answer is usually that the hours went down for the same scope, or the scope went up for the same hours. If neither is true, say what is.
- The fairness check: if a task took you three hours with an agent and would have taken eight without, bill three. Billing hours you didn't spend because “that's what it would have cost” is a fixed price called hourly.
2. Hourly for your time, plus usage at cost
You bill your hours as above and pass the agent's usage through as a separate line, the way you would a stock photo or a hosting bill.
- Good for: heavy agent use billed per use through an API, where a long session has a real cost per client.
- Watch out for: subscriptions. If you pay a flat monthly plan and use it for every client, there's no clean per-client cost. Treat it as overhead in your rate, like your laptop, or agree a flat tooling fee with retainer clients. Don't invent a per-client number.
- Keep: the provider's usage export next to the invoice, so the line can be checked.
3. Fixed price, or per outcome
You quote the job, not the hours. The agent's speed becomes your margin, and the risk of a job that drags is yours.
- Good for: well-scoped work you've done before: a migration, a landing page, an integration with a known API.
- Watch out for: scope creep, which agents make cheaper to say yes to and easier to lose track of.
- You still track time. Not for the invoice, but to learn whether your quotes are right. If a two-day fixed job keeps taking four, the next quote is wrong.
Many studios end up with a mix: fixed prices for defined projects, hourly with waits for ongoing work, usage passed through only on API-heavy jobs. If you're unsure what your hourly number should be in the first place, the hourly rate calculator works it out from what you need to earn.
The rule you can't bend: one hour, one client
Agents make something possible that wasn't before: running two jobs at once. One agent refactors Client A's API while another writes tests for Client B, and you glance between them.
That doesn't give you two hours per hour. If you bill hourly, split the time you actually spent between the two, for example by which one you were reviewing or steering, or agree with both clients in advance how parallel work is charged. Billing both a full hour for the same hour is double billing, whatever did the typing.
If you regularly run several clients in parallel, that's a strong sign fixed prices suit your work better than hours.
What to write in the contract
You don't need a new contract. You need two or three sentences in the one you have. Something like:
I use AI coding tools, including [Claude Code / Codex], under my direction and review. Time I spend directing, supervising and reviewing that work is billed at my hourly rate. [Tool usage billed per job is passed through at cost / is included in my rate.] I'm responsible for the code I deliver, whoever or whatever typed it.
Adjust the middle sentence to the model you chose, and check two more things:
- Confidentiality. Does the client allow their code to be sent to an AI provider at all? Some don't; some allow only certain providers or settings. Ask before you start.
- Ownership. Most contracts already say you deliver code you have the right to deliver. Keep it that way.
If you work in a regulated profession, check what your professional body says about billing for AI-assisted work. The line most of it draws is the one above: bill the time you spent, not the time the tool saved.
Keeping a record a client can trust
Whichever model you pick, the record is what makes it believable. A good one answers three questions per entry:
- What was the work? A title a client recognises: the ticket key, the feature, the bug.
- When, and how long? Start and end, not just a number, so overlaps show.
- Where did the number come from? A timer, typed in afterwards, or put together from what was on screen? Was anything rounded?
Two habits help. Log against the ticket: if the branch is kes-431-fix-export, the entry says KES-431, and “what was this?” has a one-word answer. Round in one direction, and say so: if you round to the quarter hour, round the whole sitting once, not each five-minute piece, and say so in the contract or on the invoice.
Keep the agent's own record apart from the invoice. “The agent was busy for 47 minutes in this repository” is useful when a client asks. It isn't an invoice line.
If you're on a spreadsheet, the free timesheet template has a column for the ticket and start and end times.
How Hourbrook records it
We built Hourbrook for this case, so here's what it does, and what it doesn't.
- It counts supervised waits as work. When you sit still, it checks whether Claude Code, Codex or something in a terminal is using the CPU. If so, you're not marked away, for up to three hours. An agent waiting at its prompt doesn't count. You can switch this off in Settings › Tracking.
- It can show agent time per repository. Turn on coding agent sessions (off until you say yes) and each agent gets a lane on the Day, by repository and branch, so a parallel session for another client is visible instead of merged. Agent time stays on your screen; it's never in the PDF or CSV you send.
- It picks up issue keys from branch names and window titles and offers them as tasks, so entries get a title a client recognises.
- It rounds out, once, and shows it. A stretch you pick from your day is rounded out to the quarter hour, and the log card says how much was rounding and which breaks were joined. Drafted entries round to 5 minutes; timers don't round.
- It makes the invoice from logged entries, with each project's rate, as a PDF.
- It doesn't decide your billing model. Whether waits are billable, whether usage is passed through, and how parallel jobs are split are yours to agree with the client.
The raw record (apps, window titles, which repository an agent ran in) stays on your Mac; only entries you log can sync. See how it works, what goes where, and the Claude Code guide for exactly what is read.