Appendices: evidence, methods and prediction records

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

Computed sensitivity, not an empirical price-response estimate. Spending is the price multiplier times the quantity multiplier.

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

Q = quadrillion. 2B × 22% × 10–25M × 365. This illustrative calculation uses a separate population formula; it is not independent confirmation of the hours forecast.

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

Skycatcher forecast-comparison protocol. Accelerated token cases are our sensitivities, not token forecasts attributed to Situational Awareness.

An accelerated token sensitivity

Skycatcher research framework · September 8, 2026.

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.

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

Skycatcher research framework · September 8, 2026.

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

Skycatcher research framework · September 8, 2026.

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.

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

Skycatcher research framework · September 8, 2026.

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

Skycatcher research framework · September 8, 2026.

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

Skycatcher research framework · September 8, 2026.

What would change our view

Skycatcher research framework · September 8, 2026.

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

Full measures and uncertainty rules are published in the Tracker. Observation periods can end before the grading deadline to allow reporting time.

The bold bets beyond the next quarter

Skycatcher research framework · September 8, 2026.

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.

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.