Estimating agent work in agent time

Sometimes, after an in-depth planning session, I ask the agent to estimate the

work. The answer sounds like a traditional software estimate:

“Roughly 75 to 130 hours.”

As a schedule, that number is wildly off, and the reason is simple. The agent is

pricing the work at human reading, thinking, and typing speed, not at its own

tokens-per-second. So it never answers the question I actually have:

How much time should I set aside for the agent run?

I do not want to replace the agent’s estimate. Decomposing the request into

familiar human hours is useful work. I want to translate that estimate into

agent time, using my own traces. The forward skill does the conversion with a

confidence cone; the look-back writes the ledger that conversion reads.

This is one person’s small, changing dataset—not formal research or a universal

benchmark.

Keep the estimate. Change the units.

The process is:

1. Ask the agent for its conventional human-hour estimate, including the task

breakdown, range, assumptions and dependencies.

1. Convert with measured rates from completed work (work-type medians and a

global human→agent multiplier). My current overall multiplier is

43.8× (attended denominator:

assumed).

1. Project agent wall-clock from size and work type, with a confidence cone —

not a single false-precise number.

The outputs remain separate:

• Human-equivalent effort: a rough implementation-size estimate for an

experienced person working alone.

• Agent labor: the sum of all worker durations.
• Attended wall-clock: elapsed time from dispatch to verified completion.

Four agents working for 15 minutes represent about one hour of agent labor, but

perhaps only 15 minutes of wall-clock before serial integration and

verification.

Take the skills—and the coefficients

Todd shared the seed in public, so I want to do the same with my fork. These are

the complete, portable Markdown skills I currently use—not abbreviated prompts

or screenshots.

• Agent Effort Estimation skill
• Look-back effort-accounting skill

Agent Effort Estimation looks forward: take a conventional breakdown (or agent human-hour

estimate), classify items by work type, apply measured rates and the global

multiplier, and report agent wall-clock with a confidence cone. **Look-back

effort accounting** runs after ship: weigh the git range with tier rates,

separate cleanup credit, and write anonymized ledger rows the forward skill

reads.

Each file includes real coefficients from one personal workflow, formulas,

guardrails and output templates. Save either Markdown file as SKILL.md

wherever your agent loads skills. The coefficients are a usable starting point,

but they should be replaced as your own actuals accumulate.

Current personal human-equivalent rates:

The current overall human-equivalent → attended-agent multiplier is

43.8×, based on 243

anonymized work-item rows (2026-06-17 through

2026-07-14, rates v2.1-countable-medians). The attended

denominator is labelled assumed

(distinct active days × 6 h nominal when measured wall-time is absent).

I think agents are about 40× faster in my workflow. That coefficient still isn't

“the speed of agents.”

They stream around 50 tokens per second of thought

and code. They can think and type at that rate. I can't. They also work in

parallel: I usually spin up 2 to

4 at once.

Planning is the other difference. The back-and-forth between me and the agent is

usually about 25% to

50% of wall-clock. When there's more

agent effort, planning is a smaller share of the clock. On larger work, less of

the wall-clock is planning. With about 2 hours of

planning I can usually execute the equivalent of about

80 hours (or more) of human time.

I round the belief to about 40×. The measured conversion here is

43.8× under its assumptions, not a

universal speed claim. Your number will probably be different. Workflows,

project types, models, tools, verification gates, and attendance assumptions all

change the calibration. Judge thin basis on countable coverage (n_countable),

not raw row count, and treat the overall multiplier as one global constant until

worker durations are attributed per item.

In a future post I plan to share the trace-harvesting repository behind this

experiment so you can collect the same kind of evidence from your own sessions

and derive coefficients for your own work.

From 64 hours to 1.5 was the useful result.

The human-equivalent work estimate held up: about 64 hours going in versus 59.7

in the look-back.

Neither the original agent estimate nor my conversion assumed parallel

execution. The 1.5-hour result is total agent labor, not a parallel wall-clock

forecast.

The observed run used Grok 4.5. In my measurements, its prefill and decode

speeds were at least 50% faster than the Codex and Claude API routes behind my

coefficient, and the harness also ran work in parallel. Those unmodeled

advantages help explain the 7-minute wall-clock. This is an observation

about my workflow, not a universal model comparison.

I don't need to model every variable. The conversion already tells me what

matters: work the agent sized at 64 human hours is about 1.5 hours of

actual agent work. Good enough to kick it off and go walk my dog.

Credit

This work was seeded by Todd Saunders’s public /cost-estimate prompt: lines of

code plus complexity translated into senior-developer hours. I used it publicly

on March 5, 2026 with both hours and dollar return-on-investment framing.

• Todd’s original post: https://x.com/toddsaunders/status/2029594318361571497
• Todd Saunders: https://x.com/toddsaunders
• METR time-horizon research: https://metr.org/time-horizons/

My current fork retires the dollar layer, keeps hours-only look-back accounting,

separates agent labor from attended wall-clock, and calibrates a forward

forecast against my own session ledger. The adaptation (and any mistakes in it)

is mine.

Skills

Portable skills shipped with this field note (OKF skill bundles):

• Agent Effort Estimation
• Look Back Effort Accounting