What AI Agent Tasks Actually Cost Developers
Real task data shows why agent cost, active time, review cycles, and developer attention need separate measurements.
Founder, Task Machine
A coding agent can return a clean-looking patch in minutes. The developer still has to inspect the diff, run the repository checks, exercise the changed behavior, and confirm that the implementation matches the request. A missed edge case or repository convention sends the task through another implementation pass.
Response time captures only the first patch. Engineering cost includes every run, the model used, failed checks, review comments, corrections, and the developer time required to accept the change.
We examined an anonymized, platform-wide 30-day window from August 6 through September 4, 2026. It contained 534 tasks with active execution time, 533 tasks with recorded cost, and 68 completed tasks across product, engineering, operational, and client work run through Task Machine.
The interface screenshots use fictional examples. The published figures come from the anonymized 30-day dataset.
The dataset suggests five lessons for developers who want agent work to survive tests and review.
1. Measure execution, delivery time, review time, and cost separately
Four measurements describe different constraints in a coding task.
| Measurement | What it answers | Pair it with |
|---|---|---|
| Active agent time | How long qualifying runs occupied execution capacity | Worker availability and queue length |
| Elapsed delivery time | How long the task remained open across work and pauses | Blockers and pending decisions |
| Developer review time | How much briefing, testing, and review a person supplied | Change risk and task type |
| Recorded cost | How much task-attributed model usage accumulated | Model selection and accepted outcome |
The average task recorded 1 hour 43 minutes of active agent time and $21.43 in cost.
Average active agent time
1h 43m
Average recorded cost
$21.43
Tasks with active time
534
The dataset contains no developer-review timer. Coding tasks vary too much for the general 5 to 10 minute guidance to be a responsible developer estimate. A narrow change covered by deterministic tests may need a brief review. UI work, migrations, authorization changes, and architecture decisions can require substantially more.
A Task Machine task keeps execution usage, delivery state, and the accepted result together without treating them as the same measurement.
The task detail keeps review, duration, and spend together without treating them as the same measurement.
2. Keep implementation and requested corrections in one task
A coding task can move through planning, implementation, review, correction, and follow-up. Looking only at the final successful run removes the history that explains its cost.
Recorded cost by execution stage
Share of recorded task cost
100%
Rework means the agent continued after review requested a change. It can include fixing a missed requirement, applying a developer comment, repairing an integration, or refining an implementation after the first patch exposed a tradeoff. The 40.5% figure measures cost share only. Task failure rate requires a separate count.
Review-driven changes are expected in substantial engineering work. Repeated corrections for the same repository rule or acceptance criterion point to missing setup that should be fixed before the next similar task. Task comments and mentions keep each requested change beside the run it affected, so the next implementation pass starts with the reason intact.
3. Choose checks from the risk of the change
A single review process fits poorly across backend refactors, interface changes, migrations, and authorization work. Start with automated checks, then add runtime proof and human review where the risk requires them.
| Change type | Required proof before review | Human judgment still needed |
|---|---|---|
| Small backend refactor | Format, compile, focused tests, scoped diff | Whether the change stayed within scope |
| Permission change | Success and denial tests for every affected role | Whether the intended access boundary is correct |
| Rendered interface | Rendering tests and screenshots of changed states | Whether the experience is clear and visually acceptable |
| Database change | Migration review and tests against the migrated schema | Whether rollout and data ownership are correct |
| External action | Dry run or exact action preview | Whether the action should happen now |
A green test suite proves only the behavior covered by those tests. The task still needs a person when product meaning, risk, or visual quality determines acceptance.
During the agent loop, the Work Spec holds the expected behavior, preserved constraints, required checks, and human review boundary before implementation begins.
The review surface makes task risk visible before a person approves the Work Spec and coding begins.
4. Budget by model and leave room for expensive tasks
The median task cost $0.20, the average was $21.43, the 90th percentile reached $81.42, and the highest task reached $468.04.
Average recorded task cost
Across 533 tasks with recorded cost
$21.43
The period included GPT-5.6 Luna, Sol, and Terra. Model choice can materially change the cost of similar token usage. Task complexity, repository exploration, review cycles, and failed attempts add further variation.
A cost cap should create a decision point before it interrupts valid work. Long tasks need a checkpoint where the developer can inspect progress, narrow the scope, switch approach, or authorize the next block of work.
Task Machine budgets set the spend boundary that routes an exception for a person to decide. Model selection remains an explicit input to that budget and the task estimate.
A budget turns a cost boundary into a visible checkpoint instead of silently interrupting valid work.
Failed attempts remain part of recorded cost
An unsuccessful run can disappear from active-time reporting while its positive cost remains in the task total. The spend happened even though the run failed to produce the accepted patch. Keeping it exposes expensive failure paths and keeps the budget aligned with the bill.
5. Make review requests immediately actionable
Agents asked 237 questions, and people made 395 approval decisions during the reporting period.
Agent questions
237
Approval decisions
395
A developer should receive the exact missing decision, relevant files or output, checks already run, and the action available next. A generic notification forces the developer to reconstruct the task before reviewing it.
The reviewer should return a concrete reason with every requested change. That reason becomes part of the next run and makes repeated objections visible across similar tasks.
For pull requests, the Inbox presents the reported change, exact reviewed head, automated review result, and approve-or-revise actions in the same decision.
The review request identifies the exact code version and evidence covered by the developer's decision.
Apply the lessons in the next sprint
Choose one category of coding task and apply the same operating rules for a full sprint:
- Record active agent time, developer review time, model, and cost.
- Keep the first patch and every requested correction in one task history.
- Define required checks from the risk of the change.
- Require a developer decision at the cost or retry boundary.
- Review recurring comments and update the repository instructions.
Chat remains suitable while the team is still deciding what to build. A task should begin once the expected behavior and acceptance decision are clear.
Inspect the current platform averages and calculation method on Task Machine Pulse, then compare them with the next ten coding tasks in your own repository.