# Machine Hour: Rise of the Machine Economy

Research commentary from Skycatcher, LLC. Edition of October 8, 2026; text exported on October 29, 2026. Site: https://machinehour.ai. PDF: https://machinehour.ai/thesis/pdf. Live data feeds are listed at https://machinehour.ai/llms.txt.

Research commentary from Skycatcher, LLC, an exempt reporting adviser, published to the general public to share an idea for general research and discussion. It is not an offer or solicitation of any security or fund, not a recommendation and not investment advice; it does not consider any reader’s circumstances and is not intended for distribution where that would be unlawful. Scenario figures are Skycatcher estimates on stated assumptions, not company guidance. Skycatcher may hold positions in companies named. Full disclosures in Appendix D3.

This text edition includes the narrative, appendix notes and disclosures. Charts, data tables and interactive controls are available in the linked website and PDF.

## Executive summary

The internet is gaining a second workforce. By the end of 2032, we expect AI agents to work at a rate above 7 trillion hours a year, roughly the scale of all paid human work in 2026.

> **We see a future where billions of AI agents work around the clock. By the end of 2032, we expect this new workforce to exceed 7 trillion working hours a year, surpassing all paid human work in 2026. Our Machine Economy scenario reaches 340 trillion hours a year, 49 times that scale. This is a once-in-a-generation transformation in how humans work.**

We came to this view by putting agents to work ourselves. They read filings, write software, check results and keep research current. A question can become an ongoing research process. A small team can build software, operate it and improve it as needs change. One person can direct many streams of work at once.

We measure this activity in machine hours. One agent actively working for one hour counts as one machine hour. Agents working in parallel count separately; idle time does not. This measures the scale of activity. Its value depends on the quality of the results, the cost of human review and whether people continue to use it.

Our two scenarios explore how far this could go. The **Agentic Workforce** reaches **19 trillion machine hours a year in 2032**. The **Machine Economy**, where agents do much more work without step-by-step direction, reaches **340 trillion—49 times our 2026 human-work benchmark**. Both require rapid adoption. The larger case also requires major gains in computing capacity, efficiency and reliability. These are scenarios to test as evidence develops.

As useful work becomes cheaper, more becomes worth attempting. Research can cover more ground. Small teams can run services that once required large organizations. People can pursue ideas that were previously too expensive to build or maintain.

Every one of those services needs somewhere to run. Agents need access to information, permission to act and a reliable record of what happened. Their software needs to keep working after the conversation ends. This is the opportunity we study in the backend: the infrastructure that runs software and preserves its work.

That opportunity spans cloud platforms, established providers, open-source projects and new companies. More activity creates demand, but competition, falling prices and customer choices will determine how much becomes lasting revenue.

The longer-term vision is an internet that works on our behalf. People set the goals and limits. Agents assemble the software, coordinate work across clouds and devices, and keep services running. Building the shared infrastructure that makes this dependable could expand what individuals and small teams can accomplish. **We see a future where far more of what people imagine becomes something they can put to work.**

Skycatcher, October 8, 2026

- **Part One · A new source of work. More work becomes worth attempting.** Why lower costs make more tasks worth attempting. (https://machinehour.ai/infinite-software/2)
- **Part Two · Counting machine hours. Counting the work.** How we estimate activity and build two paths to 2032. (https://machinehour.ai/infinite-software/3)
- **Part Three · The infrastructure behind the work. How machine work creates infrastructure demand.** Which services the work needs, and when use becomes revenue. (https://machinehour.ai/infinite-software/4)
- **Part Four · How we will test the thesis. Two claims, graded separately.** What would change our view, and the predictions we will test. (https://machinehour.ai/infinite-software/5)
- **Part Five · Building for agents. Building the infrastructure for agents.** The architectures taking shape and the longer-term operating-layer vision. (https://machinehour.ai/infinite-software/6)

In May 1995, Bill Gates described the shift ahead in [The Internet Tidal Wave](https://www.justice.gov/sites/default/files/atr/legacy/2006/03/03/20.pdf). His memo is a useful reference for the question we face now: what changes when the Internet gains a new source of work?

> The Internet is a tidal wave. It changes the rules.
> Bill Gates, internal Microsoft memo · May 26, 1995

Figure 0.1 sets the scale. Both lines are modeled annual rates of machine hours against all paid human work; the parts that follow carry the evidence behind them, and the [model](https://machinehour.ai/machine-hours) lets a reader draw a different case.

*Figure 0.1. Machine hours a year: two scenarios against all paid human work.* Modeled annual rates on a logarithmic scale. The Agentic Workforce reaches 19 trillion hours in 2032 and the Machine Economy 340 trillion, on the stated capacity assumptions. These are scenarios, not bounds. The human lines compare time, not productivity or jobs displaced. The [model](https://machinehour.ai/machine-hours) lets a reader draw their own case. Passing all paid human work requires about 2.86x a year from the 2026 anchor for six years; the Agentic Workforce path grows 3.38x a year and the Machine Economy 5.46x. [Figure 1.9](https://machinehour.ai/infinite-software/2?section=fig-1.9) carries the test.

*Figure 0.2. Revenue at four companies under two scenarios.* The four-company scenarios reach $71 billion and $124 billion of annual revenue in 2032. Most of the near-term difference from consensus comes from our existing-business growth assumptions. The comparison uses analyst consensus through 2029 and our extension after that, with growth fading to 12% by 2032. The [model](https://machinehour.ai/machine-hours?section=mh-revenue) also includes slower adoption at $47 billion and limited provider revenue at $59 billion in 2032. All four are available in the [scenario controls](https://machinehour.ai/machine-hours?section=mh-controls). About nine tenths of the 2029 revenue above consensus comes from the existing-business growth assumption. Agent revenue matters more later and follows delivered hours. The 340-trillion-hour case needs nearly all the capacity in the post-2029 build; Appendix A3 sets out those assumptions.

### More work becomes worth attempting

Agents can choose steps, use tools and check a result. For selected coding tasks, we estimate about $1 of model use against roughly $200 of professional time, before review and other costs. Review, integration and operating costs remain. The larger effect is what becomes worth attempting: a report becomes a monitor, or a checklist becomes a process that runs. [Part One](https://machinehour.ai/infinite-software/2) explains the demand case.

### Counting the work

Active agents multiplied by hours per agent gives machine hours. In our scenarios, the average reaches about three hours a day in the Agentic Workforce and 13.6 in the Machine Economy. The difference rests mainly on autonomous work, which remains the least proven assumption. Machine hours pass the seven-trillion-hour human benchmark in 2032 and 2030 respectively. [Part Two](https://machinehour.ai/infinite-software/3) opens the calculation.

### Where the work runs

We map the stack of machine labor in five layers, from hardware to applications. The backend is State (data and memory) and Work (execution and control). Agents need both. Our public-company universe follows thirty-two providers, while the wider research includes clouds, private companies and open-source alternatives. Competition, pricing and customer choices determine who earns lasting revenue.

Cloudflare, MongoDB, Snowflake and Datadog give us four detailed examples of how work reaches a bill. Their combined revenue growth rose from about 25% in the first quarter of 2025 to about 34% on the latest reported quarters, to July 31, 2026, the baseline for bet B11. Their AI disclosures offer further evidence, with different definitions. The timing does not tell us how much growth came from agents. [Part Three](https://machinehour.ai/infinite-software/4) follows the activity into the companies’ reported results.

### Market expectations: a separate test

The research baskets show the hardware build being rewarded ahead of much of the backend. At September 30, 2026, Computation was up about twelvefold from January 2022. The backend basket, which includes Palantir, was up about 99%, against 84% for the Nasdaq 100; Palantir accounts for much of that gain. These are hypothetical baskets selected in 2026 and applied to earlier prices. They provide context for expectations, not a record of investment returns.

We believe the order of events is what matters. Through 2029, our financial scenarios depend mostly on stronger growth in the existing businesses. Later, agents become a larger source of revenue. From $12.7 billion in 2025, the four-company scenarios reach $71 billion and $124 billion in 2032, against about $52 billion in the extended consensus case shown in Figure 0.2. These outcomes depend on capacity, useful demand, provider share and pricing. More activity can coexist with lower provider revenue if customers choose other systems or prices fall faster. [Part Four](https://machinehour.ai/infinite-software/5) tests the financial paths and sets out what would change our view.

*Figure 0.3. The layers of the stack since January 3, 2022.* Daily price record. The equal-weight baskets were defined in 2026 and applied back to 2022, introducing hindsight. They are hypothetical and exclude fees and costs. This is also Figure 4.1 and the [tracker’s index chart](https://machinehour.ai/tracker?section=indices).

Our dated market predictions remain on the record alongside the operating tests. From October 1, 2026, we expect the backend basket to outperform Computation over one year and lead the listed comparison groups over three. The tracker grades the result from that start date.

*Figure 0.4. Eleven bold bets on the record.* Eleven supporting predictions, each with a measure and deadline, including an earlier machine-hour milestone for the end of 2027. The first grades fall in 2027. We publish misses alongside successes. See the [tracker](https://machinehour.ai/tracker?section=bets), Figure 4.8 and the full terms in Appendix D2.

In a personal post on August 19, 2026, Jerry Tworek, formerly a research vice president at OpenAI, reduced the future of computing to databases, neural networks and chips. It is a useful way to frame the question: as models do more work, what systems must keep that work running and preserve its results?

*Jerry Tworek on X, August 19, 2026, and Elon Musk’s reply. Screenshot of personal posts, reproduced for comment; copyright remains with the authors.*

We believe machine work can become one of the largest new sources of software demand since the web. **Machine Hour** follows that possibility from the work agents perform to the infrastructure it requires. The thesis states our view, the model shows what it takes, and the tracker tells us where the evidence leads.

This website is research commentary from Skycatcher, published to share an idea for general research and discussion: not an offer, a recommendation or investment advice, it does not consider individual circumstances, and it is not intended for distribution where that would be unlawful. The indices are hypothetical and not investable, and the scenario figures are our estimates, not company guidance. [Appendix D3](https://machinehour.ai/infinite-software/7?section=apx-d3) carries the disclosures.

## Part One: A new source of work

https://machinehour.ai/infinite-software/2

### A new source of work

Software has automated fixed processes for decades. Agents extend that ability: given a goal, they can choose steps, use tools, inspect the result and decide what to do next. A person can direct the task, or an event can start it under rules a person has set.

We call the resulting activity machine labor. It includes the attempts that fail. People remain responsible for the authority they give an agent and for deciding whether its work is good enough to use.

The change matters because software demand can grow beyond the number of people using it. One person can run several agents at once. A business can assign agents to processes that continue outside the working day. The limit becomes the supply of useful tasks, the cost of completing them and the infrastructure available to run them.

**Figure 1.1. From a person’s goal to machine work.** (https://machinehour.ai/infinite-software/2?section=fig-1.1)

*A person can use software directly, delegate a task to an agent, or set rules that let an event start the work. Each path uses infrastructure. The diagram shows how an agent can add steps and call other agents before the task is complete.*

### Cheaper work expands what gets attempted

For selected coding tasks, we estimate about $1 of model use against roughly $200 of professional time, before review and other costs. The comparison excludes review, retries, integration and the cost of running the finished software. It illustrates the change in direct production cost; it is not a measured reduction in the full cost of software development.

The more interesting effect is what becomes worth building. A spreadsheet can become a live dashboard. A weekly report can become a monitor. A checklist can become a process that carries out its own steps. People who could describe a problem but could not write software can now attempt a solution.

We expect much of the new work to come from tasks that were previously too expensive. An analyst can investigate more companies. A small business can test more ideas. A security team can examine more events. The outcome depends on whether the additional work is useful enough to justify its full cost.

Lower prices can expand use. Total spending rises only if the increase in use more than offsets the lower price. We think this is plausible in AI, but it will not happen automatically or equally in every market.

**Figure 1.2. Lower costs make more software worth attempting.** (https://machinehour.ai/infinite-software/2?section=fig-1.2)

*This illustration combines a 200-fold reduction in direct production cost with a 33-fold expansion in potential builders. Neither multiplier is a measured change in completed, useful software. The one-billion-person pool represents people who might build, not active developers or paying customers. Review, integration and operating costs still matter.*

### Count the time agents actually work

An agent that exists for a month may work for only a few minutes. An agent count therefore tells us little on its own.

A machine hour is one hour of active execution by one agent process. Ten agents working for an hour contribute ten machine hours. An agent waiting for an event contributes none. When a parent waits for a child agent, we count the child’s work without also counting the parent’s wait.

One instruction can produce many steps: retrieve information, call a model, query data, run a test, save a result and check it. The time spent on those steps is what we want to measure. A model call, a backend action and a completed task are different units.

Each hour also has a different infrastructure cost. Some agents run cheaply on a local machine. Others use a warehouse of business data or a large model. Part Three follows those differences into the bill.

**Figure 1.3. One request can start a working loop.** (https://machinehour.ai/infinite-software/2?section=fig-1.3)

*An agent can plan a step, use a tool, inspect the result and continue. The loop may finish, fail or require human help. More steps create activity; accepted results establish usefulness.*

**Figure 1.4. Cheaper work expands the task list.** (https://machinehour.ai/infinite-software/2?section=fig-1.4)

*Illustrative examples show work that could become economical as the cost of using agents falls. The task counts are assumptions. They explain the mechanism behind our demand thesis rather than measure adoption in 2026.*

**Figure 1.5. One goal can generate many infrastructure actions.** (https://machinehour.ai/infinite-software/2?section=fig-1.5)

*A single task can involve model calls, searches, code execution, database reads and stored results. The diagram is illustrative. Calls, tasks and machine hours are different units and should not be added together.*

### The evidence is strongest in software

Public GitHub activity gives us an early view. Merged code changes rose from roughly 3 million a month in 2023 to more than 18 million in September 2026. New repositories also grew sharply.

These are development events. A merged change does not establish AI authorship, quality or economic value. The series gives us a way to follow software production while better measures of agent use develop.

Company disclosures point in the same direction. Agents are writing code, creating databases and deploying applications. Other evidence is less encouraging: adoption remains uneven, review is costly, and some customers reduce usage after the first experiment. We keep both sides in the record.

**Figure 1.6. Software production is rising.** (https://machinehour.ai/infinite-software/2?section=fig-1.6)

*Public GitHub merged pull requests rose from roughly 3 million a month in 2023 to more than 18 million in September 2026. Repository creation provides a second view of activity. These counts do not identify AI authorship or establish the quality, continued use or value of the software produced.*

**Figure 1.7. Early evidence cuts both ways.** (https://machinehour.ai/infinite-software/2?section=fig-1.7)

*The record combines company adoption disclosures, pricing changes and capability tests with evidence of weak retention, incomplete deployment and costly review. Each observation carries its date and denominator. Salesforce’s conversation and action prices use different units; they do not establish a 95% price cut for the same task. METR (Model Evaluation and Threat Research) measures the horizon as the human time associated with tasks an agent completes at a stated success rate, not continuous autonomous runtime.*

### Two paths to 2032

Our scenarios differ mainly in adoption and autonomous work. Both include agents directed by people and agents that start tasks under standing instructions.

In the **Agentic Workforce**, adoption reaches 70% of knowledge workers by 2032, a base of about 1.2 billion people in our count (Appendix A5). Most agents remain human-directed, but the smaller autonomous group contributes a large share of the hours because it runs longer. About 17 billion agents work an average of three hours a day. That produces an annual rate of about 19 trillion machine hours.

In the **Machine Economy**, adoption reaches 95%. Businesses deploy many more autonomous agents, and a larger share works through most of the day. About 68 billion agents average 13.6 active hours a day. The annual rate reaches about 340 trillion hours, subject to the scenario’s compute assumptions.

Neither is a cautious case. From the 2026 starting point, the first requires machine hours to multiply about 3.4 times a year; the second requires about 5.5 times. Slower adoption, limited repeat use or inadequate compute can produce much smaller outcomes.

**Figure 1.8. Two paths for machine hours.** (https://machinehour.ai/infinite-software/2?section=fig-1.8)

*The Agentic Workforce reaches about 19 trillion annual hours in 2032; the Machine Economy reaches about 340 trillion under the stated capacity assumptions. Both are modeled scenarios. The two horizontal lines are all paid human work, seven trillion hours a year, and knowledge work, about 2.5 trillion. The vertical scale is logarithmic, so equal spacing represents equal multiples. Sources and method: [machine hours model](https://machinehour.ai/machine-hours).*

### The prediction we are making

We estimate all paid human work in 2026 at about seven trillion hours a year. In our published scenarios, machine hours pass that benchmark in 2032 and 2030 respectively.

This is a comparison of time. A machine hour may contain a failed attempt, while a human hour may contain judgment an agent cannot provide. Passing the line would establish the scale of machine activity. Its usefulness and value must be measured separately.

Our central prediction is the crossing by the end of 2032. The much larger Machine Economy outcome is a stronger claim. It can fail even if the crossing occurs.

**Figure 1.9. The growth required to pass human hours.** (https://machinehour.ai/infinite-software/2?section=fig-1.9)

*Annual growth required from the original 2026 forecast starting point through 2032. These are requirements of the forecast, not observed growth rates. The benchmark is seven trillion paid human working hours in 2026.*

## Part Two: Counting machine hours

https://machinehour.ai/infinite-software/3

### 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.

**Figure 2.1. Build hours from agents and active time.** (https://machinehour.ai/infinite-software/3?section=fig-2.1)

*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](https://machinehour.ai/infinite-software/7?section=apx-b1).*

**Figure 2.2. The assumptions that separate the scenarios.** (https://machinehour.ai/infinite-software/3?section=fig-2.2)

*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](https://machinehour.ai/infinite-software/7?section=apx-b1), [machine hours model](https://machinehour.ai/machine-hours).*

### 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.

**Figure 2.3. Agent workdays per researcher workday at OpenAI.** (https://machinehour.ai/infinite-software/3?section=fig-2.3)

*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](https://openai.com/index/research-acceleration-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.

**Figure 2.4. Agents are completing longer benchmark tasks.** (https://machinehour.ai/infinite-software/3?section=fig-2.4)

*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](https://metr.org/assets/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.

**Figure 2.5. From model use to infrastructure use.** (https://machinehour.ai/infinite-software/3?section=fig-2.5)

*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.

**Figure 2.6. Agent applications gain share on OpenRouter.** (https://machinehour.ai/infinite-software/3?section=fig-2.6)

*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.

**Figure 2.7. Machine hours as a share of all hours worked.** (https://machinehour.ai/infinite-software/3?section=fig-2.7)

*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.*

## Part Three: The infrastructure behind the work

https://machinehour.ai/infinite-software/4

Research commentary from Skycatcher, LLC, an exempt reporting adviser; not an offer, solicitation, recommendation or investment advice. The receipts, list prices and revenue paths in this part are our illustrations of the scenarios on stated assumptions, not company guidance and not price targets, and the companies named have not reviewed them. Skycatcher, its affiliates, principals and clients may hold long or short positions in any public company named here and may trade them without notice. [Appendix D3](https://machinehour.ai/infinite-software/7?section=apx-d3) carries the full disclosures.

### The infrastructure behind the work

Agents create demand while they work—and through the software they leave running. A task can create a database, an application or a recurring process that remains in use after the agent stops.

Lasting revenue depends on continued use and payment. We follow three steps: more agent activity, more infrastructure used, and more revenue earned by providers. Each step needs its own evidence.

The opportunity spans cloud platforms, established providers, open-source systems and new companies. Customers can choose bundled services or build their own. The four company cases below show particular ways activity can become revenue.

The sizing figure at the end of this part compares roughly $190 billion in selected backend categories with the $25 trillion to $35 trillion paid for knowledge work each year. The categories have different scopes and may overlap; the wage comparison establishes scale, not an addressable market.

### Five layers of the system

**Computation** supplies chips, servers, networks and energy. **Intelligence** supplies the models. **State** stores data and memory. **Work** runs and coordinates software, controls access and monitors activity. **Applications** deliver the result to the user.

We call State and Work the backend. The labels help organize the research; products often cross the boundaries.

A model can propose an action. The systems around it must decide whether the action is allowed, apply it consistently and preserve a record. Better databases do not make an agent’s reasoning correct. They help contain mistakes, inspect what happened and recover.

**Figure 3.1. The services behind agent work.** (https://machinehour.ai/infinite-software/4?section=fig-3.1)

*Our research map follows five layers: State, Work, Applications, Intelligence and Computation. Companies can operate across several layers. The categories describe what is sold; they do not establish which businesses will capture the most value. Sources and method: [Appendix C1](https://machinehour.ai/infinite-software/7?section=apx-c1).*

### Who serves the new demand

Our public research universe contains thirty-two backend companies. The wider map includes hardware, models and applications for context. The universe is a research scope, not a portfolio or a complete list of potential winners.

Cloudflare, MongoDB, Snowflake and Datadog are four detailed case studies. They let us examine different ways agent activity can become paid usage. The largest cloud platforms, private companies and open-source alternatives remain part of the opportunity even where disclosure makes them harder to model.

The distinction between State and Work is economic as well as technical. Stored data and deployed applications can persist after an agent finishes. Execution and monitoring tend to vary with activity. Both can generate recurring spending, but neither guarantees it.

**Figure 3.2. Where competition can change the bill.** (https://machinehour.ai/infinite-software/4?section=fig-3.2)

*Model providers, applications, cloud platforms and independent infrastructure companies can each serve part of an agent’s work. Integration may shift spending between them. The map shows possible relationships, not fixed winners or market shares. Sources and method: [Appendix E](https://machinehour.ai/infinite-software/7?section=apx-e).*

**Figure 3.3. State remembers and Work executes.** (https://machinehour.ai/infinite-software/4?section=fig-3.3)

*State services store the information an agent needs and the results it creates. Work services run tasks, move data and monitor execution. Both may benefit from more activity, but the financial outcome depends on pricing, utilization and whether the customer pays for the additional use.*

**Figure 3.4. The public backend universe.** (https://machinehour.ai/infinite-software/4?section=fig-3.4)

*Thirty-two companies provide a broad view of the category. Revenue observations retain their reporting periods; market values retain their quote dates. The roster is a research sample, with businesses of different sizes and exposure to agents. It is not a portfolio or a measure of the entire backend market.*

### Four ways an hour reaches a bill

Cloudflare serves network requests and runs code. Additional activity can fit inside an existing allowance before it creates an additional charge.

MongoDB supplies database capacity. An agent’s extra reads and writes may cost the customer little until they require a larger cluster or more resources.

Snowflake charges for warehouse compute and related services. Cost depends on the queries, the time resources stay active and the use of AI services.

Datadog charges for infrastructure monitoring and selected volumes of logs, traces and other records. Customers can change how much they collect, retain and index.

These contracts explain why activity and revenue can move at different times. More calls do not become more revenue one for one. Spare capacity, caching, volume discounts and alternative products all affect the bill.

**Figure 3.5. Four businesses and the units they bill.** (https://machinehour.ai/infinite-software/4?section=fig-3.5)

*Cloudflare, MongoDB, Snowflake and Datadog connect activity to revenue through different contracts and meters. The examples use public list prices checked on September 29, 2026. Customer discounts, commitments, included use and product mix can make realized bills materially different.*

### What the companies have reported

At the October 7, 2026 reading, all four case studies grew revenue faster in their latest reported quarter than in the quarter before: approximately 36% at Cloudflare and Datadog, 35% at Snowflake and 30% at MongoDB.

Their AI disclosures are less comparable. Snowflake disclosed a $100 million AI revenue run rate in December 2025 and later discussed AI’s contribution to growth. Datadog has reported the contribution of customers whose businesses center on AI. MongoDB has described growing agent activity without providing a separate AI revenue figure. Cloudflare has reported rapid developer-platform and agent-traffic growth.

These are signs of demand, with different definitions. Revenue from an AI company is broader than revenue caused by agents. A count of customers using AI is broader still. We keep those distinctions in the tracker.

The counterevidence matters. On August 6, 2026, [Datadog reported lower usage from its largest customer](https://investors.datadoghq.com/static-files/2360a5cc-f17a-4731-b74a-fb6f4617baf5) and included that reduction in its third-quarter and full-year guidance. The customers that adopt first can also be the first to build alternatives or negotiate lower prices.

**Figure 3.6. What the companies have reported.** (https://machinehour.ai/infinite-software/4?section=fig-3.6)

*Eight quarters of revenue sit alongside dated AI and agent disclosures. The financial series establishes company performance; the disclosures provide context. Their timing alone does not show how much growth came from agents.*

**Figure 3.7. Commitments can appear before revenue.** (https://machinehour.ai/infinite-software/4?section=fig-3.7)

*Deferred revenue helps track customer commitments and revenue timing; the tracker shows deferred revenue alongside reported revenue growth. The series covers the broader business and is affected by contract length and billing terms. It is not a direct measurement of agent demand.*

### From working time to revenue

For each company, we estimate:

**Delivered machine hours × share using the provider × revenue per hour served.**

The share using a provider is an assumption. Most global agent hours do not reach any particular company in our four-company model. One hour can also use several providers, so their shares are not exclusive market shares.

Revenue per hour served depends on the workload and contract. Our illustrative bills range from fractions of a cent for some network or database uses to between $5 and $33 for a data-intensive warehouse workflow. They use published prices and stated activity assumptions, before negotiated discounts.

We then let the price per comparable unit fall as volume grows. In the published scenarios, a tenfold increase in volume leaves 50% to 65% of the earlier unit price, depending on company and scenario. These are assumptions to test, not measured laws.

**Figure 3.8. How one workflow could reach four bills.** (https://machinehour.ai/infinite-software/4?section=fig-3.8)

*Illustrative receipts show where a workload might create charges at the four companies. They use stated workload and price assumptions. They are not a production customer’s invoice, and they should not be summed into a universal cost per machine hour.*

**Figure 3.9. More volume can come with a lower unit price.** (https://machinehour.ai/infinite-software/4?section=fig-3.9)

*Illustrative revenue per hour using each provider, 2025–2032. Prices retain 50% to 65% of their earlier level after each tenfold increase in relevant volume; this is not an annual price decline. Method and assumptions: [revenue model](https://machinehour.ai/machine-hours?section=mh-revenue).*

### The opportunity beyond current software budgets

We use roughly $190 billion as an illustrative grouping of backend markets. Their scopes differ and may overlap, so this is not a precise total for our 32-company universe.

Databases and analytics make up the largest part: about $161 billion in Gartner’s 2026 database-management forecast, compared with a $119.7 billion market in 2024. The 2026 figure is a forecast, not reported revenue (Forecast: Database Management Systems, Worldwide, 2023 to 2029, 2025 Update, December 2025).

For Work, we estimate $25 billion to $30 billion for metered observability and security event management, combining Gartner’s observability-platform and security information and event management markets. We add $1 billion to $2 billion for agent runtime, our estimate informed by Menlo Ventures’ December 2025 figures of $750 million for agent platforms and $1.5 billion for AI infrastructure in 2025.

Agents could expand these categories by making more work affordable and creating software that would never have been built by hand.

Knowledge work pays roughly $25 trillion to $35 trillion a year, our estimate from the 2.4 trillion knowledge-work hours in Appendix A5 at $10 to $15 an hour, against about $58 trillion of all labor income (the ILO’s labor income share of 52.3% applied to the IMF’s 2024 world GDP). The sizing figure uses the upper end, which gives a sense of the economic activity involved. It is not a backend revenue forecast. Customers retain part of the benefit, useful work still requires review, and spending is divided among models, applications and infrastructure.

The financial model is narrower. It estimates the four case studies company by company. Their combined revenue reaches about $71 billion in the Agentic Workforce and $124 billion in the Machine Economy in 2032. Those totals include their existing businesses; modeled agent revenue contributes about $15 billion and $53 billion respectively.

We believe the category can become much larger. The work ahead is to establish how much activity becomes durable paid use, and where that spending lands.

**Figure 3.10. A large pool of work and a smaller infrastructure bill.** (https://machinehour.ai/infinite-software/4?section=fig-3.10)

*The illustration compares up to $35 trillion of human labor value with about $190 billion of backend spending, on the definitions in the text as of September 2026. Each tier assumes agents take on the stated share of that work and that providers bill 10 to 20 cents per dollar of human work delivered; both are illustrative assumptions, not estimates. These pools overlap with other economic activity and are not directly interchangeable. The comparison frames the scale of the question; it is not a forecast that labor spending transfers to infrastructure providers.*

## Part Four: How we will test the thesis

https://machinehour.ai/infinite-software/5

Research commentary from Skycatcher, LLC, an exempt reporting adviser; not an offer, solicitation, recommendation or investment advice. The index returns in this part are equal-weight baskets defined in 2026 and applied back to 2022: hypothetical, hindsight-selected and not investable. The revenue paths and valuation arithmetic for Cloudflare, MongoDB, Snowflake and Datadog are our estimates and illustrations of the scenarios, not company guidance and not price targets, and the companies have not reviewed them. Skycatcher, its affiliates, principals and clients may hold long or short positions in any public company named here and may trade them without notice. [Appendix D3](https://machinehour.ai/infinite-software/7?section=apx-d3) carries the full disclosures.

### How we will test the thesis

The machine-hours prediction and the financial scenarios answer different questions. The first asks how much agents work. The second asks what selected companies earn from that work. A rising share price does not verify either one.

We begin with what markets have rewarded and what current prices assume. We then examine what our revenue scenarios require, how they could fail and the evidence that would settle the argument. Finally, we apply those tests company by company. Share-price performance has its own grading rule; it cannot substitute for operating evidence.

### What has the market rewarded so far?

The market has rewarded much of the hardware and data-center build ahead of the backend. Our research baskets show that sequence. They are hypothetical baskets assembled in 2026 and applied to earlier prices, so they contain hindsight and do not represent an investable track record.

The backend’s average experience also hides large differences. Palantir materially changes the index result. Company size, revenue growth and valuation vary widely. The tracker shows those differences rather than asking one average to represent them all.

We compare price performance with reported revenue growth to see how market returns and business results differ.

**Figure 4.1. How the research baskets have traded.** (https://machinehour.ai/infinite-software/5?section=fig-4.1)

*Equal-weight, adjusted-price comparisons put the backend groups beside the Nasdaq 100 benchmark. The company roster was selected in 2026 and applied to history from January 2022, which introduces hindsight. The baskets are hypothetical and exclude fees, taxes and trading costs. Sources and method: [Appendix C1](https://machinehour.ai/infinite-software/7?section=apx-c1).*

**Figure 4.2. Revenue growth across the backend.** (https://machinehour.ai/infinite-software/5?section=fig-4.2)

*The series compares trailing revenue growth for the covered companies. A quarter is shown only when at least 10 comparable companies report (50 for the Nasdaq 100), so coverage can differ from the full 32-company roster because not every company reports comparable quarterly figures. Company fiscal periods are not perfectly aligned. Sources and method: [Appendix C1](https://machinehour.ai/infinite-software/7?section=apx-c1).*

### What do today’s prices assume?

The next question is what current prices require from the businesses. A revenue multiple compares a company’s value with its revenue. Growth, profitability, dilution and risk all influence it.

Our valuation tool asks what revenue growth could support a given multiple under stated cash-flow assumptions. The standard case holds growth for five years, then fades it toward 3%, with a 25% free-cash-flow margin and a 10% discount rate.

On those assumptions, the backend’s 6.8-times forward-revenue median at October 28, 2026, the latest close in the daily series, corresponds to roughly 15% annual growth for the first five years; the figure and this sentence update each trading day. Figure 4.3 shows the trailing-revenue multiple, a different basis. The four detailed case studies generally carried higher expectations. Each should be compared with its own scenario, on the same dates and revenue basis.

This is a sensitivity exercise. A multiple does not reveal a unique market forecast, and the result changes when margins or the discount rate change.

**Figure 4.3. What the market pays for current revenue.** (https://machinehour.ai/infinite-software/5?section=fig-4.3)

*Median enterprise value to trailing revenue provides a common valuation reference for each group. Enterprise values and revenue inputs retain their dates and coverage. The median describes the selected companies; it does not adjust for every difference in margins, growth, dilution or business quality.*

**Figure 4.4. Growth consistent with the latest forward multiple.** (https://machinehour.ai/infinite-software/5?section=fig-4.4)

*The reverse valuation calculation asks what revenue path supports the observed market value under the chosen margin, discount-rate and terminal-value assumptions. A different assumption changes the required growth. The result is a conditional calculation, not a market forecast or price target.*

### What must the businesses deliver?

Our four company cases make the revenue assumptions explicit. Together, the companies reported about $12.7 billion of combined revenue in the model’s 2025 base. Our scenarios reach approximately $40 billion to $49 billion in 2029, against the analyst-consensus snapshot of $32.7 billion registered on September 8, 2026; the October 7, 2026 consensus is $33.1 billion.

Most of that difference comes from the growth we assume for the existing businesses. Modeled agent revenue is only about 2% to 3% of the 2029 totals. The near-term forecast therefore depends on reported growth lasting longer or accelerating more than the consensus snapshot assumed.

Commitments and customer expansion offer evidence, but they do not secure several years of growth. We watch consumption, renewals and reported revenue each quarter. A renewed period of customer cost-cutting would weaken this part of the forecast long before the longer-term hours question is settled.

After 2029, the modeled agent contribution becomes much larger. By 2032 it is about a fifth of combined revenue in the Agentic Workforce and more than two fifths in the Machine Economy. That is when the financial outcome depends more heavily on agent hours arriving and reaching these providers.

**Figure 4.5. Four revenue paths with different foundations.** (https://machinehour.ai/infinite-software/5?section=fig-4.5)

*Reported revenue, dated analyst consensus and the two Skycatcher scenarios are shown separately. The consensus extension after 2029 is our calculation, not a published analyst estimate. Each Skycatcher path combines existing-business growth with separately modeled agent revenue. The four companies do not represent the whole backend opportunity.*

**Figure 4.6. When agent revenue becomes material in the model.** (https://machinehour.ai/infinite-software/5?section=fig-4.6)

*The separately modeled agent line contributes about 2.1% and 3.4% of combined revenue in 2029, rising to about 21.3% and 43.2% in 2032. Those shares belong to the Agentic Workforce and Machine Economy respectively. They are model outputs, not company-reported agent revenue. Existing-business revenue already includes some AI use. Sources and method: [revenue model](https://machinehour.ai/machine-hours?section=mh-revenue).*

### Can activity grow without much provider revenue?

Those revenue paths require more than agent adoption. The strongest commercial countercase accepts the machine-hours forecast. Agents work much more, but open-source systems, cloud bundles and internal software serve most of the growth. Prices also fall faster than our central assumptions.

We model that combination explicitly. With Machine Economy hours, flat provider share, steeper price declines and slower growth in the existing businesses, combined revenue is about $59 billion in 2032. Agent activity is enormous, while the modeled agent revenue at the four companies is only about $3 billion.

This is why the category view cannot be reduced to a claim about four stocks. New companies can succeed while established providers lose share. Customers may capture most of the economic benefit.

### What would change our view

The risks span the whole chain, from repeat use to the cash providers keep.

1. **Repeat use remains low.** Agents can finish impressive demonstrations but are rarely trusted with recurring work.
2. **Review remains too expensive.** A low inference bill does not produce a low cost per accepted result.
3. **Capacity falls short.** Power, hardware or efficiency improvements cannot support the hours demanded.
4. **New workloads choose other systems.** Global activity rises while the providers we follow serve a smaller share.
5. **Prices fall faster than paid use grows.** Customers do more work while spending less.
6. **Growth fails to become cash.** Model costs, operating expenses or dilution absorb the revenue increase.
7. **The economic setting changes fundamentally.** Our financial scenarios assume a functioning market economy and useful demand for the work performed.

**Figure 4.7. What could weaken the thesis.** (https://machinehour.ai/infinite-software/5?section=fig-4.7)

*The seven risks above, each paired with our counterpoint and the observation that would test it. A larger activity total is insufficient if work stays unreliable or providers fail to earn the expected revenue.*

### What evidence will settle the argument?

We turn these questions into dated predictions. The headline hours prediction sits alongside specific tests of capability, adoption, company revenue and market performance. Each has a baseline, a measure and a deadline.

The next readings concern adoption and company growth. We will publish outcomes against the original launch terms, whether predictions succeed or fail. A later forecast revision does not erase the original call.

We believe machine work can become a major source of infrastructure demand. The tracker is there to establish how quickly that is happening and who, if anyone, is earning durable revenue from it.

**Figure 4.8. Predictions we will grade.** (https://machinehour.ai/infinite-software/5?section=fig-4.8)

*The register contains eleven supporting predictions with stated measures and deadlines, including a machine-hour milestone for the end of 2027. H1 separately records the main prediction that machine hours pass the human benchmark by the end of 2032. Original terms remain fixed. Outcomes are published whether the prediction succeeds or fails. Sources and method: [Appendix D2](https://machinehour.ai/infinite-software/7?section=apx-d2).*

### How does the test differ by company?

The same tests can produce different answers for each provider. The company cards bring product exposure, reported evidence, scenario outcomes and the strongest countercase together. We judge each business on the paid work it serves and the evidence it reports.

**Figure 4.9. Company cases as tests of the framework.** (https://machinehour.ai/infinite-software/5?section=fig-4.9)

*The cases connect product exposure, reported financial evidence and conditional model outcomes. They illustrate how to investigate the revenue providers earn from the work. They do not establish a recommendation, a target price or that rising agent activity will favor every company equally.*

The four cases illustrate the method. The wider opportunity includes new providers, open-source systems and cloud platforms. Part Five asks what they are building for agents and what a shared operating layer could make possible.

## Part Five: Building for agents

https://machinehour.ai/infinite-software/6

Research commentary from Skycatcher, LLC, an exempt reporting adviser; not an offer, solicitation, recommendation or investment advice. The private-company valuations in this part are the companies’ own announced round prices, not our estimates of value. Skycatcher is an investor in Clockwork Labs, the company behind Spacetime (SpacetimeDB), discussed below, and this site runs on its Maincloud service. Skycatcher, its affiliates, principals and clients may hold positions in any company named here and may trade them without notice. [Appendix D3](https://machinehour.ai/infinite-software/7?section=apx-d3) carries the full disclosures.

### Building for agents

Agents are becoming builders and users of software. They can choose a database, deploy an application and keep it running. The infrastructure beneath them has to become easier to use and dependable enough to carry the work.

We see a broad opportunity here. Established clouds, open-source projects and new companies are approaching the same problem from different directions. Some will sell individual services. Others will bring more of the system together. The architecture that serves machine work may look different from the one built around human developers.

### Where new companies are forming

Our private-company map follows twenty-eight businesses across four groups: services that run agents, clouds that serve models, tools that control and monitor activity, and systems that store data and memory.

Temporal, Modal and Browserbase help run work. Fireworks, Baseten and Together serve models. Grafana, Braintrust and WorkOS help monitor or control activity. Databricks, Supabase, Convex and Spacetime supply data or application infrastructure. Their products overlap, but each gives us a different view of what agents need.

The first signs appear in creation. Vercel reported on June 17, 2026 that coding agents trigger more than half of its deployments. Databricks, which owns Neon, reported in January 2026 that agents create 80% of the databases on Neon. Supabase reported in June 2026 that AI tools launched more than 60% of its new databases, and in October 2026 that the share had reached 70%.

Those disclosures count different things over different periods. A database may last seconds. A deployment may never attract a user. We want to know how many of these applications remain useful, active and paid for 90 days after creation. Creation tells us where agents are arriving. Retention tells us whether the work lasts.

**Figure 5.1. The private backend landscape.** (https://machinehour.ai/infinite-software/6?section=fig-5.1)

*Twenty-eight private companies show the range of products and architectures being built. Funding and valuation entries use the latest cited transactions or disclosures, with dates. A last-round valuation is a historical transaction reference, not a live market value or proof of operating performance. Cursor left the map when SpaceX’s acquisition closed ([8-K filed August 14, 2026](https://www.sec.gov/Archives/edgar/data/1181412/000162828026056945/spcx-20260814.htm)). Sources and method: [Appendix C3](https://machinehour.ai/infinite-software/7?section=apx-c3), which carries each company’s dated source.*

**Figure 5.2. What adoption disclosures actually count.** (https://machinehour.ai/infinite-software/6?section=fig-5.2)

*Developer registrations, database creation, projects, deployments and revenue measure different things. Each disclosure carries the company’s original definition, date and population. Product creation can be an early signal; paid retention and repeat production use provide stronger evidence of a lasting business.*

### Funding the backend build-out

The companies in our map raised much more capital from 2024 to 2026 than in the two years before. We record primary equity separately from debt and secondary share sales. Announced round prices show what investors paid at a point in time.

Funding can pay for capacity and distribution. The business still has to earn repeat use. We expect demand to grow for agent memory, identity, permissions, monitoring and application hosting. Some of that spending will reach new providers; some will be included in products customers already buy.

Acquisitions show the same convergence. Data platforms are adding tools to observe and control agents. Execution platforms are adding storage and identity. The boundaries in our map will move as providers compete to serve more of the work.

**Figure 5.3. Funding the companies building the backend.** (https://machinehour.ai/infinite-software/6?section=fig-5.3)

*The comparison includes disclosed primary equity rounds through October 5, 2026, on the stated category definitions. Debt and secondary transactions are excluded. Financing measures capital supplied to companies, not demand for their products.*

### Fewer systems to connect

Building an application often means connecting separate services for data, authentication, execution and live updates. Every connection adds setup, testing and maintenance. An agent can write the code quickly and still struggle to make the whole system work.

Supabase packages services around Postgres, a widely used open-source database. Convex brings data and application functions into a managed backend. Spacetime runs application logic inside the database and streams changes to connected clients. Each reduces a different part of the work developers have to assemble themselves.

These designs put application logic and data in different places. Each reduces some work and leaves different limits. Figure 5.4 follows an update through each system, separating processing, storage and networking. A read replica is a read-only copy; WAL means the database change log. More connected users, more stored data and more writes per second are different measures of scale. The figure describes the products on the stated date, with planned features shown separately.

**Figure 5.4. Different architectures move work to different places.** (https://machinehour.ai/infinite-software/6?section=fig-5.4)

### What adoption can establish

Supabase’s disclosed developer base rose from about one million in October 2024 to nearly ten million in June 2026. Convex has also reported substantial growth in developers and applications. These figures show distribution and interest. They do not yet give us comparable measures of paid retention or the share of agent-built applications that work correctly.

We ask the same questions of every architecture. Can an agent build a correct application with fewer repairs? Can the system handle the resulting workload? What does it cost to operate? Do customers keep using it?

Different applications may need different answers. A large analytical workload and a small collaborative app need not run on the same design. The opportunity can support several approaches.

**Figure 5.5. Supabase’s developer count has grown rapidly.** (https://machinehour.ai/infinite-software/6?section=fig-5.5)

*Supabase reported about one million developers in October 2024 and nearly ten million in June 2026. The chart preserves the company’s definition. Registered developers are not the same as active production customers or paying accounts.*

### From assembling services to running software

Andrej Karpathy described the problem in March 2025: building a web application still requires a developer to assemble and configure many separate services. His post captures a constraint we have met in our own work. Generating more code does not by itself remove the work of connecting it to a reliable system.

**Figure 5.6. A developer’s view of the remaining complexity.** (https://machinehour.ai/infinite-software/6?section=fig-5.6)

*Practitioner observation. Karpathy’s post describes the work of assembling web services. It gives context for the architecture question; it is not a benchmark or a measure of market-wide adoption.*

Figure 5.7 shows one proposed solution. Clockwork Labs’ diagram brings application logic, data and live updates together in Spacetime. The idea is the same application with fewer systems to connect—and less connection code to write and maintain.

**Figure 5.7. A proposed solution to the missing infrastructure piece.** (https://machinehour.ai/infinite-software/6?section=fig-5.7)

The next diagram separates two jobs. One layer runs the models. Another runs the code they write. Both are needed when an answer becomes an application that people depend on. The second layer has to keep working after the conversation ends.

**Figure 5.8. Running models and running the code they write.** (https://machinehour.ai/infinite-software/6?section=fig-5.8)

### What we have learned by building

Machine Hour runs on Spacetime. Skycatcher is an investor in Clockwork Labs, the company behind it. That relationship informs our access and our interest; it also makes clear disclosure and independent testing important.

Using the product gave us a direct view of the architectural idea. Application logic and data sit together, and connected clients receive changes through subscriptions. An agent has fewer separate services to configure. Our experience shows that this approach can serve this site. Larger and more demanding applications need their own evidence.

Clockwork Labs has published tests of transaction throughput and application building. The first measures a specific workload. The second asks the same agent to build a twelve-feature chat application on two backends. The figures below show the results and the limits of each test.

Independent replication, comparable configurations and paid applications running reliably over time would strengthen this evidence.

**Figure 5.9. A vendor benchmark on one workload.** (https://machinehour.ai/infinite-software/6?section=fig-5.9)

*Vendor benchmark. Clockwork Labs reports roughly 304,000 transactions per second for Spacetime Standalone; its selected alternatives range from about 130 to 3,200. Hardware, workload and durability settings affect the result. The test is not independently verified and does not establish a general performance advantage. Skycatcher is an investor in Clockwork Labs. Method and source: [Clockwork Labs benchmark post](https://spacetimedb.com/blog/benchmarking).*

**Figure 5.10. A small test of building with agents.** (https://machinehour.ai/infinite-software/6?section=fig-5.10)

*Vendor benchmark. Two runs per backend, using Claude Sonnet 4.6 and manual grading against twelve requested features. This sample cannot establish a stable success rate or general architecture advantage. Disclosed prompts, repeated trials and independent grading are needed. Skycatcher is an investor in Clockwork Labs. Method and source: [Clockwork Labs benchmark page](https://spacetimedb.com/llms-benchmark-sequential-upgrade).*

### An operating layer for the machine economy

Imagine describing a service you want to exist, and having agents build it, launch it and keep it running across clouds and devices. You set the goal, budget and decisions that need approval. A shared operating layer preserves the data, permissions and history so another agent can carry on when one stops.

That layer needs four capabilities: place work on suitable, authorized hardware; preserve information between tasks; recover from failures; and enforce people’s permissions, budgets and approval rules. It could connect several platforms through shared standards.

**Figure 5.11. One goal, many machines.** (https://machinehour.ai/infinite-software/6?section=fig-5.11)

*Illustrative vision, not a product or a measurement. A possible architecture: agents coordinate work across authorized computing resources, while people set goals and limits, and results and approval requests return to the person.*

In April 2026, we asked ChatGPT to imagine the scale of such a platform. The exchange below is a thought experiment. Its useful question is how much computing could pass through a common operating layer.

**Figure 5.12. The blue-sky scenario: a common operating layer.** (https://machinehour.ai/infinite-software/6?section=fig-5.12)

*Thought experiment. This April 2026 ChatGPT exchange considers a distributed system across cloud hardware. Its valuation figures are speculative model output, not an independent valuation, a price target or evidence of demand.*

The lasting value would come from useful systems that keep operating. Agents build and launch a service, maintain its information and propose improvements. People approve consequential decisions. If a task is interrupted, another agent can resume from the saved data and history.

**Figure 5.13. The work continues after the conversation ends.** (https://machinehour.ai/infinite-software/6?section=fig-5.13)

*Illustrative vision. One application through four stages, create, operate, adapt and continue, on a backend that preserves the application, its data, its permissions and the record of work. The lasting value comes from useful systems that keep operating; each task can build on what came before.*

### What would make that vision real

The hard part is making these systems work together reliably: moving data, isolating customers, recovering from failures and controlling cost and permissions across machines. Portability must work in production. No single company has established this outcome.

Our machine-hours thesis does not require this full vision to arrive. It describes what sustained growth in machine work could make possible.

We believe people will increasingly direct work that agents carry out and maintain. The backend would become the foundation for that work: keeping applications running, preserving what has been learned and allowing the next task to build on the last. The larger possibility is a world where far more people can turn an idea into something that works, and keeps working.

## Appendices

https://machinehour.ai/infinite-software/7

### Appendix A: Tokens: the history, our forecast and the outside view

#### A1. Tokens, from the beginning

A token is a small piece of text a model reads or writes. We use token disclosures because they provide a public record of model activity. They are not direct measurements of working time or useful output.

The historical series brings together disclosures and estimates with different coverage. Comparisons must use the same token basis and identify changes in coverage. Fresh input, cached context and written output should be shown separately where the source allows it.

The broad record shows rapidly rising use alongside falling prices. A 2,000-fold volume increase and a 200-fold price decline produce a descriptive log ratio of about 1.4. They do not identify price elasticity: better models, adoption and changing workloads also affected demand.

The sensitivity illustration asks what happens at different assumed responses to price. It does not claim that one response has been measured for the whole market.

*What demand elasticity changes.* See the [figure and data](https://machinehour.ai/infinite-software/7?section=apx-a1) in Appendix A1.

#### A2. Our token forecast: about 2,300 quadrillion a year by 2029

The token forecast checks the hours scenario against another unit. Multiply machine hours by the assumed tokens per hour. In the Machine Economy, about 2.9 trillion hours in 2029 at roughly 800,000 fresh tokens per hour gives approximately 2,300 quadrillion tokens a year: about 140x the 2026 base of about 17 quadrillion, or about 5.2x a year. The fall from about 1.3 million fresh tokens an hour in 2026 to 800,000 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, and the recorded monthly series will show whether it holds. A quadrillion is one thousand trillion.

A second calculation starts with users. Roughly two billion weekly users in 2029, 22% running continuously active agents and 10–25 million tokens per participating user per day produce a broad range around the hours-based result. These are assumptions, so agreement between the calculations is not independent confirmation.

Our coding logs provide calibration evidence. Since October 7, the published measure counts intervals when the 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 execution. The earlier capped-gap estimate remains in the record so the effect of the change is visible.

The model converts at about 1.3 million per machine hour in 2026, the blended fresh-input rate across coding, research and enterprise workflows. It 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 on October 6; it remains in the record. Fresh input, cached reads and output are shown separately so a definition change cannot look like an improvement in efficiency.

Over the nine complete weeks through October 4, 2026, the published series shows about 257 calls an hour, a median 112 million processed tokens and a median 5.9 million fresh input tokens per active hour. Cached reads account for 95% of processed tokens. On the archived capped-gap estimate the same weeks held about 1.8 times as many hours, so every rate read lower (about 144 calls, 61 million processed and 3.4 million fresh an hour); the restatement is method, not growth. The one-operator processed divisor the gauge once used for OpenRouter’s traffic, the measured cadence times the platform’s 100,000 tokens a request plus output, reads about 28 million on this basis. These observations describe our coding sample. The hours anchor remains subject to the A4 review rule.

*A bottom-up token sensitivity.* See the [figure and data](https://machinehour.ai/infinite-software/7?section=apx-a2) in Appendix A2.

#### A3. The outside forecast: Situational Awareness, graded

We compare the hours forecast with an illustrative supply path and with the themes in Leopold Aschenbrenner’s Situational Awareness. His published predictions and our calculations using related assumptions are labeled separately.

An announced campus is not operating inference capacity. The evidence record distinguishes announced investment, installed hardware, available power and capacity serving workloads.

The conversion from tokens to hours depends on workload mix and the compute required for fresh input, cached context and output. We show a simplifying arithmetic case and a price-weighted stress case. Prices are not physical compute ratios, and cached reads are not physically free.

The published 2029 path serves roughly four trillion machine hours annually, or nearer three trillion on the stress test. From 2029 to 2032, the capacity path assumes eight times as much compute and tenfold greater token efficiency. The stricter case also assumes less repeated context per fresh token. The charts show requested and delivered work, so a supply constraint also reduces the related revenue estimate.

A separate illustrative calculation uses Epoch’s estimates of installed AI chips and DeepSeek’s disclosed throughput. It asks whether the order of magnitude is plausible. The result depends on inference’s share of capacity, utilization and the models served. It is not a measured ceiling or proof that future power and hardware will be available.

*An outside forecast as a reference.* See the [figure and data](https://machinehour.ai/infinite-software/7?section=apx-a3) in Appendix A3.

*An accelerated token sensitivity.* See the [figure and data](https://machinehour.ai/infinite-software/7?section=apx-a3) in Appendix A3.

#### A4. Estimating current machine hours and the forecast starting point

We use two main estimates and a separate cross-check.

The **provider-by-provider estimate** estimates hours venue by venue: token volume × estimated agent share ÷ tokens processed per agent hour. We account for routed traffic to avoid counting it at both OpenRouter and the underlying model provider. The October 8, 2026 register defines the venue divisors as assumptions about active model and tool execution, excluding unattended idle time and between-turn human waiting. They are informed by workload profiles, not a matched timing sample across each venue. They should not be read as measured venue-wide rates or as the older capped-gap timing estimates. The original forecast anchor remains fixed under the rule below.

The **OpenRouter-based estimate** converts classified agent tokens into hours by workload, then scales those hours by OpenRouter’s share of worldwide tokens. It assumes the platform’s agent mix helps describe the wider market. That assumption is especially important because OpenRouter is not a representative global sample.

The **billed-activity cross-check** converts selected product revenue or work units into illustrative hours. Cognition’s revenue includes products beyond time-based agent work, and the duration assigned to a Salesforce work unit is our assumption. The result is not a measured lower bound.

For the week ending October 25, 2026, the latest OpenRouter-based estimate is 53 million machine hours a day. The alternative provider-by-provider estimate is 17 million. Neither is a direct count. Assigning all uncertain task tags to coding gives 42 million, to enterprise workflows 54 million and to research 91 million. Varying workload-profile endpoints gives 25 to 151 million; this range varies tokens used per active hour only. It does not capture all uncertainty in worldwide token volume, agent classification or how well OpenRouter represents other platforms. It is not a confidence interval.

The workload mix is dated October 24, 2026. Its central fresh-input rate is about 1.3 million an hour across the mix. Applying the coding operator’s fresh-token rate alone would imply about 29 million hours a day. That comparison shows why a single coding trace should not stand in for all agent work.

Were the forecast restarted from the latest OpenRouter-based estimate, 53 million a day for the week to October 25, 2026 instead of the published 35 million, the Agentic Workforce destination would rise from 19 to 29 trillion hours and its crossing would move from 2032 to 2031, with delivered hours held at the capacity path. This is an illustration. A change to the forecast must follow the review rule below.

These methods share evidence and assumptions. Their range is not a confidence interval. Work outside the covered venues and tool execution with little token use remain difficult to observe.

The published 2026 anchor remains 35 million hours a day. At a quarterly review the two estimates are compared with the forecast for the same date, not with the fixed 2026 anchor, since ordinary growth along the published path is expected to carry the readings above 35 million. If both estimates have sat on the same side of the forecast for a full quarter, the published growth rates are held and the forecast is restarted from that quarter’s pulse as a new vintage, dated and recorded; if the gap is instead traced to a change in how 2026 was measured, the 2026 anchor is restated and the path redrawn from it. Either way the registered prediction keeps its original terms.

A revised method restates history on a comparable basis and preserves the earlier series. We record the difference as a measurement change rather than growth.

#### A5. The human benchmark: 7.0 trillion paid hours a year

We use seven trillion paid human hours a year as the central benchmark: about 3.6 billion people in employment (ILO modelled estimates, November 2025: 3.60 billion in 2025 and 3.64 billion in 2026) at about 2,000 hours each; the ILO’s mean of 41 hours actually worked a week implies closer to 2,100, so seven trillion is a rounded-down benchmark. A defensible range is approximately 6.5 trillion to 7.5 trillion. The central benchmark is held flat in the forecast comparison.

This construction includes self-employment and excludes unpaid household work. Hours actually worked, usual hours and hours paid for are different statistical concepts; the benchmark is an approximation, not a single directly reported ILO total.

Knowledge work is a smaller comparison, about 2.4 trillion hours in 2026 and 2.5 trillion by 2032. Knowledge workers, in our count, are the people whose work is mainly handling information. ILO occupational data put managers, professionals, technicians and clerical workers at 25 to 28% of the employed, about 0.9 to 1.0 billion people in 2026; Gartner counted more than 1 billion knowledge workers in 2019 and Forrester 1.25 billion information workers in 2018 on a wider definition. The model uses 1.128 billion knowledge workers in 2026, rising to 1.179 billion, with an eight-hour day and five-day week: a model input between the two definitions, not a published statistic.

Machine-hour results are annualized rates at the dated reading. They compare duration, not productivity, economic value or jobs displaced.

### Appendix B: The machine hours model: the assumption register and Jevons’ paradox

#### B1. The assumption register

The register lists each input, its source, the judgment applied and the evidence that would change it. The starting adoption rate is an estimate. The 2032 settings are scenario assumptions.

The forecast uses one shared definition of an active hour. Licenses, agent registrations and corporate ambitions do not directly measure it. Survey evidence is kept with its population, question and period.

The token conversion uses three workload profiles. Central processed-token rates are approximately 20 million per hour for coding, 2.5 million for research and 7.5 million for enterprise workflows. The respective ranges are 12 to 30 million, 1 to 8 million and 2 to 14 million. They are judgments informed by traces and benchmarks. The research profile describes long report-writing work; the SimpleQA trace, short single-search questions, runs at about 16 million processed tokens an hour and does not inform that central value.

Some older comparisons combine token use from one benchmark with duration from another. The workflow panel records time, tokens and other observations from the same runs. It includes our coding sessions, enterprise tasks and research questions, plus public run logs from two other coding operators, All Hands AI and METR. Each result stays attached to the workload and evaluation that produced it.

Our workflow trace covers 48 retail and airline tasks. The agent and simulated customer used Claude Haiku 4.5. The agent passed 52%; failed tasks are not assumed to have been completed by a person. The trace reports about 13 million processed tokens, 1.07 million fresh input tokens an hour and 0.32 million written, at about $4.09 of list-price inference per hour.

The enterprise profile combines that experiment with a separate estimate assembled from production disclosures. Its fresh-input central value is about 1.6 million per hour. The workflow blend is derived from hours, so its token series must use matching definitions.

The useful next step is a broader sample that follows the same task from active work to acceptance, human review, the actual infrastructure bill and repeated paid use. The panel publishes a common contribution format so new observations can be compared.

Our panel includes 6,118 coding runs (300 from All Hands AI’s public evaluation, 5,809 from METR’s public runs and the rest our own sessions) and 48 enterprise tasks. The workflow trace reports 52% accepted, at an estimated $0.05 of list-price inference per accepted task. The coding panel reports 52 minutes of between-turn waiting per active hour; how much was human review is unmeasured. Our own sessions carry no acceptance record; the two imported logs supply acceptance for the rest, each on its own benchmark, and the pooled share mixes different tasks and operators.

The research agent answered 48 SimpleQA questions with web search: 96% correct under the benchmark’s grading rules, a median of 1 search per question and about 3 active seconds per question. List-price inference cost about $0.027 per correct answer. These are short factual tasks, so the result does not establish the cost or reliability of a long research report.

The second coding source is All Hands AI’s public OpenHands evaluation on 300 SWE-bench Lite tasks, using Claude 3.5 Sonnet on October 28, 2024. Its published logs show 22 active hours, 42% resolved and about $1.62 of inference per resolved task. Each column states how many runs support it because the sources record different measures.

A third coding source is METR’s public time-horizon run data: 5,809 runs of five 2025 and 2026 frontier models on its HCAST and RE-Bench software tasks, 82% accepted on the binary score, with each task’s human baseline time kept beside the row (median 11 minutes). The file records each run’s wall-clock span and no per-step timestamps, so these rows add acceptance and human time to the panel but no active hours (see the [METR source data](https://github.com/METR/eval-analysis-public)). The import script is not included in this public edition.

Retained paid use remains an open question. The register has 21 dated disclosures and reports covering application creation, deployment, persistence and paid usage. None reports the share of agent-created resources still generating bills after ninety days: the newest creation figures are Supabase’s 70% of new databases and 4 million launches a month (October 2, 2026, from 60% in June) and half of Vercel’s 6 million deployments a day; the platforms’ own claim windows, 72 hours on Neon and 60 minutes on Railway, are graduation gates with no disclosed claim rates; and the only survival-style number is an independent Flathub study, 73% of AI-tagged repositories abandoned within months. We do not yet have invoices linked to agent-created applications over 90 days. That evidence is needed to measure continued paid use.

Operators can contribute comparable observations through the About page, with their names included or withheld.

*Registered yearly assumptions.* See the [figure and data](https://machinehour.ai/infinite-software/7?section=apx-b1) in Appendix B1.

#### B2. Jevons’ paradox: the illustration, the precedents and the elasticity condition

Total spending is price multiplied by quantity. A tenfold price reduction requires more than a tenfold increase in comparable usage for spending to rise.

At an assumed demand elasticity of 1.3, a tenfold reduction produces about twenty times the use. At 0.7, it produces about five times. These are illustrations of the condition, not measured forecasts.

Computing, storage and bandwidth offer precedents for large increases in use as costs fall. They do not supply a coefficient for agent demand. Better AI can also reduce the time and resources needed for a fixed task. Our thesis requires enough additional useful work to outweigh those savings.

*Efficiency can expand the market.* See the [figure and data](https://machinehour.ai/infinite-software/7?section=apx-b2) in Appendix B2.

#### B3. Displacement: machine work replacing human work where both can be counted

Public GitHub records identify some code changes submitted by named agents. They miss agent work submitted under a human identity. Merged changes indicate acceptance into a codebase, not a universal quality standard.

Stack Overflow records show how many questions people ask publicly. The decline is consistent with a shift toward model assistance, but it does not establish the amount of human work displaced.

We show these series together as evidence of changing work patterns. They cover different activities and cannot be subtracted to calculate jobs or hours replaced.

#### B4. The proxies: the dated disclosures behind the inputs

The source tables collect dated observations from Census, Gallup, Ramp, Anthropic, OpenAI, Cloudflare, GitHub, Cognition, Salesforce and other providers.

Comparable observations form a time series. Changes in definition break the line. One-off statements remain table entries rather than becoming a smooth trend through interpolation.

Each entry says what was counted, who was observed and which model assumption it informs. Frontier users show what is possible in an intensive setting. They do not establish the average user’s behavior.

### Appendix C: The companies: the roster, the value chain and the private record

#### C1. The full research roster

The research universe is the 32 companies classified as State or Work. Other layers appear for comparison. Membership follows the published product, listing, size and data-coverage rules.

Palantir is identified separately where its size or valuation materially affects a comparison. Megaport reports half-yearly in Australian dollars and is excluded from quarterly panels that require comparable observations.

The roster includes the reason for each classification and records changes with their dates. Index membership, research coverage and holdings are different concepts. Predictions retain the universe rules under which they were registered.

#### C2. From the value of the work to backend revenue

The economic value of an agent’s work begins with accepted output, including time saved and tasks newly made affordable. Review and integration consume part of the benefit. Customers retain part, and the remainder is divided among providers across the system.

The knowledge-work wage pool is therefore a scale comparison. It cannot be converted directly into backend revenue. Application revenue and the infrastructure purchased to deliver it must not be counted twice in an aggregate market total.

*From customer value to backend spending.* See the [figure and data](https://machinehour.ai/infinite-software/7?section=apx-c2) in Appendix C2.

#### C3. The private universe: the dated record

The private-company table records the latest sourced financing, operating disclosure or relevant launch for each company. Round prices, primary capital, secondary transactions and debt are identified separately.

Companies that leave the active map remain in the record with the reason. A financing or acquisition is evidence of a transaction. Paid use and retention are the evidence for the demand thesis.

#### C4. State and Work: the economic questions

State keeps data, memory and records that can remain after a task ends. Work runs software and manages the activity around it. Both can be priced by capacity, usage or subscription, depending on the product.

The questions are practical: what persists, what the customer pays for, and what could make that spending move elsewhere. Compression and portability can reduce data costs. Sampling and bundling can reduce monitoring revenue. The model tests those effects separately from growth in hours.

*State and work: the evidence to watch.* See the [figure and data](https://machinehour.ai/infinite-software/7?section=apx-c4) in Appendix C4.

### Appendix D: The record: downside, registered calls and disclosures

#### D1. What would change our view: sensitivities, risks and evidence to watch

Adoption and active time drive hours demanded. Compute can limit delivery. Provider share and pricing determine agent revenue. Costs and dilution determine how much revenue becomes value for owners.

The main commercial risk is that machine work grows while the selected providers earn less. The sensitivity table changes the hourly bill, provider-use share and price separately. The model also tests slower adoption, limited provider revenue and a capacity path that stops expanding after 2029.

Software built by agents can keep generating infrastructure bills after the task ends. We estimate this continuing demand separately to check the model. The published scenarios already include it in existing-business revenue, so we do not add it again.

If activity rises but paid use does not, reduce the assumed share of work using these providers and the revenue earned per hour. If repeated use is weak, reduce adoption or active hours. If applications are abandoned, reduce the spending that continues after they are built.

*The commercial failure cases.* See the [figure and data](https://machinehour.ai/infinite-software/7?section=apx-d1) in Appendix D1.

*What would change our view.* See the [figure and data](https://machinehour.ai/infinite-software/7?section=apx-d1) in Appendix D1.

#### D2. The launch predictions and their grading rules

These are the original launch bets, registered October 8, 2026. Each has a stated measure, observation period and grading deadline. The full rule appears beside each bet in the tracker.

H1 asks whether active machine duration passes the fixed 2026 paid-human-work benchmark by the end of 2032. It does not equate machine and human output. A robust hit requires the lower sensitivity bounds of both the provider-by-provider and OpenRouter-based estimates above 7.5 trillion annual hours; a miss requires both upper bounds below 6.5 trillion. Overlap or disagreement is unresolved. Initial grade January 31, 2033; one final restatement of the last complete week of December 2032 by June 30, 2033 may remain unresolved. Independent method review is due September 30, 2032.

B15 applies the same uncertainty principle to 100 million hours a day in the last complete week of December 2027: initial grade January 31, 2028, final grade June 30, 2028. Its method review is due September 30, 2027. B2 observes the June 2027 quarter and allows filings through September 30, 2027. Missing or incomparable filings leave these grades unresolved.

B3 sets an absolute target of 17 companies using one inclusion rule. No comparable launch baseline is asserted. The model scenarios, the headline crossover and company-revenue outcomes are separate claims: success in one does not establish the others. The 65/35 weights are conditional on the two published adoption scenarios, not a probability that the crossover happens.

*Our bets · October 8, 2026.* See the [figure and data](https://machinehour.ai/infinite-software/7?section=apx-d2) in Appendix D2.

*The bold bets beyond the next quarter.* See the [figure and data](https://machinehour.ai/infinite-software/7?section=apx-d2) in Appendix D2.

#### D3. Disclosures

The full text of the site’s disclosures: research commentary, not investment advice; Skycatcher’s investment in Clockwork Labs, the company behind Spacetime, which also serves this site; positions and conflicts, market comparisons, data, third-party material and privacy.

**Research commentary.** Machine Hour is research commentary published by Skycatcher, LLC, an exempt reporting adviser. We publish it on a regular schedule to the general public to share an idea. It does not solicit investors for any Skycatcher fund. It is published for general research and discussion and does not consider any reader’s circumstances. It is not an offer or solicitation of any security or fund, not a recommendation and not investment advice, and it is not intended for distribution where that would be unlawful.

**Forward-looking statements.** The scenarios, the machine hours model, the revenue paths for Cloudflare, MongoDB, Snowflake and Datadog, the bold bets and every figure marked modeled are Skycatcher estimates built on stated assumptions. They are not company guidance, consensus or assurances of future results, and the companies named have not reviewed them. They can be wrong. A bold bet is a dated prediction with a public measure; its grade records whether the prediction landed and is not a record of trading, returns or advice, and no bet is an instruction to buy or sell anything. We grade the bets at their deadlines and publish every grade, hit or miss; we are under no duty to update any other statement. We fix and date the scenario inputs at each edition and grade the tracker’s hours gauge each quarter on the machine hours model; the crossover years move with that grading. Several figures and the model page carry sliders: a case a reader draws with them is that reader’s own input, not a Skycatcher estimate, and it is not stored or published.

**Framework and company cases.** State, Work, Applications, Intelligence and Computation are research classifications of what a company sells. The roster, the four bellwethers and every named company case are illustrations of the argument, not holdings disclosures, a portfolio, a model portfolio or a screened investment basket.

**Positions and conflicts.** Skycatcher, its affiliates, principals and clients may hold long or short positions in any public company named on this site, including the 32 companies of the backend universe and the four bellwethers, and may buy or sell them before, during and after publication without notice. No company named on this site pays Skycatcher in any form for its coverage. Skycatcher, its affiliates and principals hold venture positions in some of the private companies mentioned, including Clockwork Labs, the company behind Spacetime. This site is served by a Spacetime module on that company’s Maincloud service, and subscriber email addresses are stored there and processed by Beehiiv to send the monthly email. Our operating experience with Spacetime and the vendor’s published benchmarks are not independent research, and the competitors named in those benchmarks have not verified them.

**Market comparisons.** Price comparisons use split- and dividend-adjusted closes in equal-weight baskets. We defined the baskets in 2026 and applied them back to January 2022, so they carry hindsight selection. They are hypothetical: not an investable index, not an actual account, and no fees, taxes or trading costs are deducted. Historical observations are not a guarantee of future returns. Consensus figures are the analyst mean carried by Financial Modeling Prep on the date stated and can change as analyst coverage changes.

**Data and dates.** Company financial observations are Financial Modeling Prep’s standardized quarterly statements, each tagged with its reporting period and filing date and cut at the filing date, refreshed each trading night; coverage is shown, and the SEC filings remain the primary source a reader can check. Market prices, balance-sheet components and trailing revenue can have different dates; valuation approximations disclose their basis. Missing observations remain missing. Non-US companies are measured in their listing currency unless a conversion is stated.

**Third-party material.** Names and marks identify their owners and do not imply endorsement. Nasdaq-100 is a registered trademark of Nasdaq, Inc., used here only to identify the benchmark; Nasdaq does not sponsor, endorse or review this site. Company figures are summarized in original illustrations with links to the underlying publications. Names and source links do not imply permission, endorsement or independent verification. Rights questions can be sent through the About page. Links to other sites are provided for reference; we do not control their content and are not responsible for it. Analyst consensus, market values and the balance-sheet inputs to valuation approximations come from Financial Modeling Prep (FMP); company financials from SEC filings; token volumes from OpenRouter; software-production counts from the GitHub Search API; question counts from Stack Overflow (CC BY-SA 4.0); task-horizon observations from METR.

**Privacy.** The subscribe form records your email address, signup time and the form used. Skycatcher, LLC handles subscription requests. Addresses are stored by Spacetime and shared with Beehiiv for email delivery. New subscriptions require email confirmation before they become active in Beehiiv. We do not automatically reactivate an unsubscribed address. Use the unsubscribe link in an email to stop updates, or the About contact link to request access or deletion. We may retain a suppression record to prevent further mail. Vercel and Spacetime serve these pages and may process request information, including IP addresses, in their service logs. The chart library is served with the site. This site code sets no cookies or analytics tags; it stores your theme preference in your browser. Beehiiv email tracking and processing depend on the publication settings and its privacy notice. Processing locations and retention periods depend on the providers and applicable obligations; no fixed location or deletion period is promised here.

**Accuracy and liability.** We take care with the data and the arithmetic and link each figure to its source, but we do not warrant that anything here is accurate, complete or current; third-party data is shown as received. To the extent the law allows, Skycatcher, LLC accepts no liability for loss arising from use of or reliance on this site. Corrections reach us through the About page, and we publish each one, dated, in the monthly update.

**Jurisdiction and contact.** This site is published from the United States. Questions, corrections, rights-holder notices, grading disputes and privacy requests go through the contact link on the About page. Disclosures last reviewed October 8, 2026.

### Appendix E: Company presentations: findings summarized in our own illustrations

#### E1. Cloudflare, June 9, 2026

The June 9, 2026 slides show how Cloudflare connects its network and developer platform to agent activity. The most useful evidence concerns growth in requests and how contracts turn those requests into revenue.

Its agents-per-worker example is a planning assumption. It is context for our scenarios, not a measured floor under global adoption. Our original illustrations retain the stated metrics and link to the company source.

#### E2. Datadog, February 12, 2026

The February 12, 2026 slides describe a move from monitoring toward systems that can respond to problems. They show rapid growth in AI-related records and the contribution of AI-focused customers.

The pricing example combines more volume with a different storage mix. It should not be read as a like-for-like price reduction. The distinction matters when using it to stress the revenue model.

#### E3. MongoDB, September 29, 2026

The September 29, 2026 slides show the scale of Atlas, the connection of agent tools to its database and growth among customers building AI products.

Approximately 40% of Atlas recurring revenue came from customers with at least one AI use case. That is a customer classification, not an AI-revenue share. The fast-growing AI-focused customer group was still a small part of Atlas revenue.

#### E4. Snowflake, June 2, 2026

The June 2, 2026 slides show product growth, existing-customer expansion and examples of agents working with governed business data.

The task example compares answers with and without additional runtime context. Its accuracy and cost figures belong to that setup. They demonstrate a possible benefit of supplying relevant context, not a universal advantage over every alternative.

## About Skycatcher

Machine Hour is public research from [Skycatcher](https://skycatcher.xyz), an investment firm founded in 2015. We study the Internet by using the products being built on it. Putting agents to work ourselves led us to the question behind this site: how much work can machines perform, and what infrastructure will that work need?

### What we study

We study AI agents doing work for people and the infrastructure that supports them. Our agents read filings, query data, write software and check results. Using them helps us see their strengths and failures; it does not replace broader evidence.

A machine hour is one agent actively working for one hour. It measures activity, not the value or quality of the result. We estimate that activity, explore how it could grow and track whether it creates lasting demand for software infrastructure.

### How to follow the research

Start with the [summary](https://machinehour.ai/). Five parts develop the thesis. Use the [model](https://machinehour.ai/machine-hours) to test the assumptions and the [tracker](https://machinehour.ai/tracker) to follow the evidence. The [appendices](https://machinehour.ai/infinite-software/7) explain sources, methods and limitations.

The thesis and human-hours prediction were published on October 8, 2026. Predictions keep their original terms. The monthly update explains what the evidence supports, what challenges our view and what remains unknown.

### Write to us

For questions, corrections, better data or privacy requests, [write to Skycatcher](mailto:machine@skycatcher.xyz).

### Disclosures

Skycatcher, LLC is an exempt reporting adviser. This site is published for general research and discussion. It is not an offer of any fund, a solicitation, a recommendation or investment advice. It does not consider individual circumstances and is not intended for distribution where that would be unlawful.

Scenario outputs are our estimates on stated assumptions, not company guidance. Reported data retain their sources and dates. The index comparisons are hypothetical baskets defined in 2026 and applied back to 2022.

Skycatcher, its affiliates, principals and clients may hold positions in any public company named, including the 32 backend companies and the four company cases, and may trade them without notice. Skycatcher is an investor in Clockwork Labs, the company behind Spacetime.

This site runs on a Spacetime module and stores subscriber addresses there. Beehiiv delivers the monthly email. See the [full disclosures and privacy note](https://machinehour.ai/infinite-software/7?section=apx-d3).