In this piece
AI Agent Hours + Human Hours: Why Clients Should Push Back
Your agency says AI makes development faster. Then the proposal arrives: developer hours, AI agent hours, and human review on top.
More transparent? Perhaps. A better deal? Not necessarily.
A second clock does not make an invoice fairer. For a client buying working software, uncapped AI runtime plus human time is a poor default. It makes your bill depend on how the supplier works, rather than what you can actually use.
Our view at Wavect: agree the result, the quality bar and the commercial boundary. Let the delivery team choose the tools. Its internal efficiency should not become your invoice-auditing problem.
Sources checked . The pricing critique is Wavect's analysis. Public examples establish that combined billing is being offered or advocated, not how common it is. Calculations below are illustrative, not client results or supplier quotations.
Are providers really billing AI hours alongside human hours?
LeoTech Services publishes two development rates: $120 per engineer-hour and $10 per AI agent-hour. It includes engineer verification and presents the model as a way to pass AI savings to clients.
In a separate first-person billing post, consultant EJ Bantz describes charging $65 per hour for AI runtime and meetings, with automated logs visible to clients.
Keito's professional-services guide explicitly describes invoices combining human hours at one rate with AI hours at another. It also presents outcome-based billing as an alternative.
These are self-described practices and vendor guidance, not an independent survey of agency adoption. They also do not establish that a particular supplier overcharges or delivers poor work.
AI agent-hour billing means charging for the time an automated agent runs, separately from or alongside human work. The contract must say whether an hour means elapsed runtime, active processing, reserved capacity or a human-equivalent estimate. Those are different products.
Why is AI agent-hour billing a bad default for software clients?
1. Your bill can grow without your result improving
An agent can spend another hour finding a critical security defect. That might be excellent value. It can also spend another hour repeating a failed approach. A runtime meter counts both.
The problem is not that every extra run is waste. It is that runtime alone cannot tell you which extra work was worth buying. Without acceptance criteria, retry limits and a budget ceiling, the client carries too much of the execution risk.
In its June 2025 research-system write-up, Anthropic reported roughly 15 times the tokens of ordinary chats for its multi-agent systems. This is historical, system-specific evidence, not a universal cost multiplier or an agency markup benchmark.
Our commercial conclusion: the supplier choosing the architecture should be accountable for whether the extra complexity earns its place.
2. Parallel agents can multiply the meter
Ten agents running for two hours can produce twenty billable agent-hours if the contract sums their runtimes. The client experienced two elapsed hours. Neither number tells you whether the feature passed its tests.
Parallel work can be valuable. But a supplier should not get a larger invoice merely for launching more workers. Ask who approves concurrency and whether duplicate or abandoned work is billable.
In Anthropic's August 2026 coordination experiments, agent swarms ran for 12 hours on a game-building task. Even newer models that integrated code more successfully produced poor end products in that test. More integrated activity did not ensure a usable result.
3. You can end up funding generation and its repair
Human review is essential work, not an illegitimate surcharge. The issue is responsibility: does the agency absorb defects within the agreed scope, or invoice you for every failed generation and every correction?
A weak arrangement charges for producing the first version, reviewing it, repairing it and trying again, without a stopping rule. A stronger arrangement includes the testing and correction needed to meet the agreed acceptance criteria.
New requirements are different. Changing the desired behavior can justify a new price. Repairing a result that fails the existing requirements should follow the agreed defect-remedy terms, not automatically become extra scope.
4. An agent-hour is not a human-hour
An engineer might review one task while another agent runs. A busy log does not establish two hours of human labor. Nor does it show that two hours of elapsed runtime represent two hours of productive machine work.
METR's February 2026 study-design update identifies concurrent agent use as a problem for task-time measurement. Selection effects also made its follow-up an unreliable estimate of current productivity. That is a reason to measure your own workflow, not reuse old speedup or slowdown headlines.
Two suppliers quoting the same agent-hour rate may therefore be selling very different capacity. Compare the accepted scope, quality, total exposure and handover, not just the hourly number.
5. Cost visibility is not the same as a right to bill
Tracking tokens, runtime and human effort can help an agency operate well. That does not mean every tracked item belongs on the client's invoice.
Distinguish actual provider charges, an internal allocation of a shared subscription, and a supplier's managed-service fee. All can be legitimate when agreed. They are not interchangeable. An API-equivalent usage estimate is not automatically another cash expense on top of an already-paid subscription.
For the accounting distinction, see our guide to billed AI costs versus internal cost allocation. This article asks a different question: which of those inputs should the client agree to buy?
Worked example: the same feature, two clocks, a changing invoice
Imagine a bounded customer-export feature. It needs implementation, access controls, testing and handover. These are invented commercial scenarios in EUR, excluding VAT, not market rates or Wavect offers. The scope and acceptance bar stay the same.
| Scenario | Human work | Agent runtime | Total |
|---|---|---|---|
| Initial time-based estimate | 20 hours × €150 = €3,000 | 40 hours × €15 = €600 | €3,600 |
| Same scope, extra retries and repair | 28 hours × €150 = €4,200 | 120 hours × €15 = €1,800 | €6,000 |
| Agreed accepted-deliverable price | Included within scope | Included within scope | €4,500 |
The second time-based invoice is €2,400 higher than the estimate, an increase of 66.7%. The fixed deliverable costs €900 more than the clean first scenario, but €1,500 less than the retry scenario.
That is the honest trade-off. Outcome accountability is not a guarantee of the lowest invoice. You can pay a premium for a defined result and a clearer risk boundary.
The fixed figure stays fixed only within the agreed assumptions and scope. Changed requirements or explicitly excluded third-party charges need their own approval. An hourly contract with a genuine ceiling can also bound exposure. A fixed price without acceptance remedies does not guarantee completion.
What should outcome-based software pricing actually mean?
For scoped software delivery, outcome-based pricing should connect an agreed fee to a defined, verifiable result, with explicit consequences if it fails acceptance. Here, that means accepted-deliverable pricing. It does not mean an agency can guarantee your revenue, product-market fit or every downstream business result.
| Model | What you buy | What must be defined |
|---|---|---|
| Human hours + agent hours | Specified inputs or capacity. | Meter definitions, rates, caps, overlaps and billable retries. |
| Fixed-price accepted deliverable | A bounded capability that meets agreed tests. | Acceptance, included QA, dependencies, remedies and changes. |
| Business-performance fee | Payment linked to measured commercial improvement. | Baseline, attribution, measurement period, exclusions and disputes. |
A fixed monthly fee is not automatically outcome-based. Neither is a price per generated pull request, closed ticket or document. Those units need a quality definition. Otherwise, you have replaced the clock with another activity counter.
Intercom's Fin documentation lists $0.99 chat/email resolutions with Intercom, including assumed resolutions, plus billable configured handoffs. It reverses a resolution charge when the customer returns to the same conversation seeking further help.
The lesson is not that such a model is wrong. It is that the word outcome does not settle what counts as success. Read the definition and the reversal rules.
For the broader choice between time-based, fixed-price and staged delivery, use our existing software project pricing guide.
What should clients put into an outcome-based proposal?
Start with a small result that can be demonstrated and accepted. For the export feature above, a useful buying specification might look like this:
| Boundary | What to agree before work starts |
|---|---|
| Usable result | An authorized user can export the agreed customer fields in the specified format. |
| Functional acceptance | Named test cases cover empty data, agreed data volume, special characters and export failures. |
| Security and performance | Unauthorized users cannot export data. Specify the response-time target, dataset and test environment. |
| Evidence and reviewer | Working demonstration, test results and a named client reviewer, with an agreed review period. |
| Price and payment | Milestone price, payment dates, included review and retries, and separately approved expenses with caps. |
| Failure and change | Define correction, retesting, unresolved-defect remedies and approval for genuinely new requirements. |
| Handover and dependencies | Repository access, agreed code rights, documentation and deployment assets; name required client access, data and decisions. |
A result is not accepted just because the agent says it is finished. Nor should acceptance depend on an unlimited, subjective instruction to make it better. Both sides need a testable boundary and a way to resolve disagreement.
For larger projects, price one bounded milestone at a time. Unknowns belong in discovery, a capped experiment or a clearly scoped retainer. Do not hide them inside a supposedly guaranteed transformation.
For ongoing agent operations rather than a development milestone, our AI agent SLA template covers service-level measurement and remedies.
When can separate AI usage and human fees be reasonable?
When you knowingly buy two distinct services, understand the meters and control the budget. There is nothing inherently wrong with paying for infrastructure and the people operating it.
AWS AgentCore Runtime pricing, for example, separates active CPU consumption from memory consumption. CPU waiting for I/O is not charged as active CPU; memory can remain billable. Those are defined infrastructure resources, not promised software results.
For a client-owned production agent, demand-driven model charges can reasonably sit outside the build fee. So can an agreed human support service. Require spending limits, clear allocation, approval for overages and no duplicate recovery of the same cost.
For research or incident response, a capped human-time engagement can be more honest than pretending the final answer is already knowable. Reserved capacity may also be what you actually need. The purchasing mistake is buying those inputs while believing you bought an accepted result.
Our AI agent cost-per-action guide explains the operating bill. Here, focus on which charges your agency contract passes to you.
How Wavect approaches outcome accountability
For Wavect's scoped software delivery, the starting point is a defined result, a fixed price and a signed scope. Human judgment, implementation and the agreed quality checks belong to the delivery commitment. The client's job should be to evaluate the result, not reconstruct our internal timesheets.
Where priorities are still evolving, we also offer weekly cancellable retainers. These are continuing-service arrangements with progress accountability, not pure payment-per-result contracts. Applicable money-back terms and refund procedures depend on the selected offer and agreement.
There is an important exception to any blanket slogan: our published pricing also includes prepaid developer hours. Buying a defined amount of human capacity is different from accepting an open-ended agent-runtime surcharge. This article does not claim that Wavect never sells time.
Our position is narrower and stronger: when you hire us for an agreed software result, the commercial model should reward delivering that result, not expanding the list of billable inputs.
AI efficiency can improve our margin. That is legitimate. You should receive a competitive price, the agreed quality, accountable delivery and a usable handover. A supplier does not need to bill more machine-hours to earn a fair profit.
Five questions before you approve AI charges
- What exactly am I buying? Accepted software, human capacity, reserved infrastructure or runtime?
- What makes the invoice grow? Ask about concurrency, waiting, retries, review, failures and overages.
- Who pays when the agreed result fails? Separate defect correction from a genuine scope change.
- What is my maximum exposure? Require a fixed boundary or a spending ceiling with an approval stop.
- What can I verify and take away? Acceptance evidence, code access, documentation and an agreed exit state.
Compare proposals on those answers. A low agent-hour rate can still produce an expensive unfinished project. A higher fixed price can still be poor value. The result, evidence and risk allocation decide.
Buy accepted progress, not a second timesheet
AI is a reason to improve the delivery model, not preserve every old billing habit and add another meter.
For a well-scoped software project, our preferred deal is straightforward: one agreed outcome, a defined price, visible quality evidence and clear responsibility when something fails. For uncertain work, use a smaller paid discovery, a capped experiment or a transparent retainer.
You should know what you are buying before the agents start running.