Part Two: Counting machine hours

Counting machine hours

One agent actively working for one hour counts as one machine hour. Parallel agents count separately; idle time does not. The model begins with a simple calculation:

*Active agents × active hours per agent = machine hours.*

We build the agent population from the number of people using agents and the agents associated with each user. We then separate human-directed work from autonomous work. This makes the assumptions visible, even though no representative global survey yet measures all of them.

What the public data can tell us

There is no worldwide meter of machine hours. We estimate it from disclosed model usage and from profiles of how agents work.

A token is a small piece of text a model reads or writes. Token totals include ordinary chat as well as agent work. They also include repeated context, so the same information can be processed many times during a task.

Our provider-by-provider estimate combines each venue’s token volume, its assumed agent share and the tokens its agents process per hour. We add the hours and account for traffic routed through OpenRouter so that it is counted once.

Our OpenRouter estimate applies the platform’s agent mix to the wider market. We separate coding, research and enterprise workflows because their token use per hour differs. OpenRouter’s task classifications describe platform traffic; using them for agent applications is an assumption.

For the week ending October 25, 2026, this edition’s OpenRouter-based estimate is 53 million hours a day; the tracker carries the current weekly reading. The alternative provider-by-provider estimate is 17 million. Neither is a direct count. They share assumptions, so their disagreement is useful information rather than independent confirmation. The original 2026 forecast starting point remains 35 million hours a day.

Changing the workload profiles gives a wide range. The OpenRouter estimate is roughly 25–151 million hours a day at the profile endpoints. That is an assumption range, not a statistical confidence interval.

From today’s estimates to the scenarios

The original 2026 forecast starting point is 35 million machine hours a day, an annual rate of about 13 billion. We set the inputs on October 6, 2026 and registered the launch prediction on October 8. This starting point stays fixed under the published review rule; the tracker updates current estimates separately.

Active agents multiplied by daily active hours per agent gives machine hours a day; multiplied by 365 it gives the annual rate. The 2026 reading and the two 2029 scenarios show each term, and the second line prices those hours at the four company cases, which Part Three builds meter by meter. Agents are active users multiplied by agents per user, with human-directed and autonomous work calculated separately and added (Figure 2.2). Daily hours are averaged across all calendar days. Sources and method: Appendix B1.

The 2032 build shows adoption, agents per user and active hours for each group. The largest difference comes from autonomous work: how many agents operate under standing instructions and how long they stay busy. These inputs are scenario judgments. Registrations and software licenses do not directly measure them. Sources and method: Appendix B1, machine hours model.

How many people use agents

The model assumes that 12% of knowledge workers actively use agents in 2026. By 2032, that share reaches 70% in the Agentic Workforce and 95% in the Machine Economy.

Surveys help us judge the direction, but they answer different questions. Census measures AI use among US businesses. Gallup measures use among US employees. Ramp observes payments among its customers. A paid license, a chatbot visit and an agent used repeatedly in production are different observations.

We use these sources as checks on our assumptions. None establishes the worldwide share of knowledge workers using agents. The faster scenario assumes deployment spreads through firms as well as through individual users.

How long each agent works

This is the largest uncertainty in the hours forecast. Both scenarios reach sixteen human-directed agents per user, each working 1.8 hours a day in 2032. That is 28.8 machine hours per user per calendar day, spread across parallel agents.

The autonomous assumptions differ much more. The Agentic Workforce reaches five autonomous agents per user. A quarter of them work 17 hours a day; the rest average 3.5 hours. The Machine Economy reaches 45 autonomous agents per user. Of these, 70% work 23 hours a day; the rest average 5.8 hours.

These are strong assumptions about useful, affordable activity. An agent with a permanent identity is not necessarily busy. A business will keep running it only if its work is worth the cost and its mistakes can be controlled.

OpenAI’s account of its research organization provides one comparison. It reported 3.1 agent workdays per human workday in mid-August 2026. That shows what an intensive user can do; it does not establish what an average business will do. Its definition of an agent workday also differs from our definition of an active hour.

OpenAI reported 3.1 agent-workdays per human researcher workday in mid-August 2026. The chart approximately redraws the company’s May-to-August series. The 3.1 figure is a ratio of agent days to human days, not a growth multiple. The company’s definition may include time excluded from our active-hour measure. Source: OpenAI, Research acceleration: the view inside OpenAI.

Capability and working time are different

METR measures the difficulty of tasks an agent can complete at a stated success rate. Difficulty is expressed as the time a human expert would need. An eight-hour task on that measure might take an agent twenty minutes.

We therefore track three quantities separately: time agents spend working, tasks they complete, and the difficulty of those tasks. More capable models can attempt harder work and complete familiar work faster. The net effect on hours depends on how much additional work users start.

METR estimates the human-expert time associated with tasks that a model completes at 50% or 80% reliability. Higher values indicate success on longer tasks in that evaluation. They do not establish equal reliability in business workflows or the duration an agent ran. Read the success rate, evaluation date and uncertainty together. This is the historical Time Horizon 1.1 series. METR marked its source page as no longer actively updated on September 8, 2026; a recent fetch is not a new evaluation. Central estimates above 16 human-expert hours are omitted as unreliable under this task suite, so a line ends where its next reading would exceed that limit. Sources and method: benchmark_results_1_1.yaml.

Our own measurements

We use our agents’ logs to study what an hour contains. The coding logs show heavy reuse of cached context. Our separate workflow experiment ran a service agent through 48 benchmark tasks. It passed 52% of them and processed about 13 million tokens per active hour.

The workflow trace added about 1.07 million fresh input tokens and wrote about 0.32 million output tokens per hour. These are separate quantities. The experiment is small, and the customer was simulated. It calibrates one profile; it does not measure enterprise productivity as a whole.

Since October 7, 2026, our published coding series counts the time a model generates or a tool runs. It excludes waiting for a person and counts a parent’s wait for a child only in the child’s work. The earlier estimate, based on capped gaps between calls, remains in the record. The change produces fewer measured hours and more tokens per hour; it is a change in method.

The workflow panel brings hours, tokens, tool use and review measures together from the same runs. It includes our coding sessions, the service experiment and a web-searching agent tested on short factual questions. A public OpenHands evaluation adds a second coding operator. Each pass rate belongs to its own benchmark; none is applied to global hours.

Vendor disclosures help us follow agent-built applications from creation to deployment and paid use. They do not yet show how many still generate bills after ninety days. That remains a gap in the evidence.

Thinking, tool use and execution can each draw on different services. Caching, batching, local execution and bundled allowances can reduce the paid bill. The diagram explains the paths through which activity may become revenue; it does not assign a fixed infrastructure cost to every hour.

The activity behind the OpenRouter estimate

OpenRouter’s application mix helps us judge how much of its traffic comes from agent work. Applying that mix to the wider market remains an assumption. The tracker shows the latest reading alongside the provider-by-provider estimate.

The historical trace shows agent-app token use passing chat-app use around February 6, 2026. Earlier points were read from the published chart through August 7, 2026; later observations use application classification; the two series join at August 7, 2026. This measures traffic on OpenRouter, whose mix may differ from the wider market.

From hours to tokens

The model uses about 1.3 million fresh tokens per machine hour in 2026, blended across coding, research and enterprise workflows. This rate updates with the data and is recorded month by month. The original 2.3-million figure describes the coding sample used to set the hours anchor; it is kept in the record.

At roughly 800,000 fresh tokens per hour in 2029, the Machine Economy’s 2.9 trillion hours imply about 2,300 quadrillion tokens a year. The fall from about 1.3 million fresh tokens an hour today assumes that routine steps move to smaller models and that more context is served from cache as tools mature; it is an assumption, not a measured trend. That is about 140x the 2026 base of about 17 quadrillion. The calculation translates the hours scenario into token demand. It is not a separate forecast of revenue.

Compute can limit the outcome

Demand does not guarantee that enough capacity will exist to serve it. We compare the hours forecast with an illustrative compute build, allowing for differences in fresh input, cached context and written output.

On the published assumptions, the 2029 build can serve about 4 trillion machine hours a year. A price-weighted stress test puts it nearer 3 trillion. Token prices are not physical compute ratios, so neither calculation is a measured global ceiling.

The Machine Economy’s 340 trillion hours use about 95% of the illustrative 2032 capacity allowance of 357 trillion hours. It requires compute to double each year after 2029, tokens per hour to fall tenfold, and nearly the full allowance to be available to agents. The stricter case also needs less repeated context for each fresh token. If those changes fall short, delivered hours fall below demand. These assumptions describe a demanding supply path; they do not establish its physical feasibility.

We also check the scale against estimates of installed AI chips and disclosed inference throughput. That hardware comparison in Appendix A3 is a plausibility check. It depends on how much capacity serves inference, how heavily it is used and which models it runs.

The model shows requested work, available capacity and delivered work separately. Revenue follows delivered hours. The share of capacity available to agents is adjustable because agents compete with other uses of AI.

How we will judge the crossing

The headline prediction uses the last complete week of December 2032. We multiply average daily machine hours by 365 and compare that annual rate with seven trillion paid human hours.

A robust success requires both estimates—the provider-by-provider build and the OpenRouter extrapolation—to clear the top of the human-work benchmark range: even the lower end of each sensitivity range must exceed 7.5 trillion hours a year. It is not enough for their central estimates to pass seven trillion. Appendix D2 sets the full rules for a success, a miss or an unresolved result. Later activity cannot rescue the prediction; better evidence can revise the estimate of the original observation week.

The model’s growth paths will change as evidence improves. The registered prediction remains on the record.

Divide annualized machine hours by machine hours plus seven trillion paid human hours. A value above 50% means machine activity exceeds the human benchmark in duration; the Machine Economy passes 50% in 2030 and the Agentic Workforce in 2032. It does not imply equivalent output, productivity or jobs displaced. The benchmark is held constant throughout the comparison.