AI's $600B Question: A CapEx Return Model for 2026

AI's "$600 billion question" is best understood as a capital-allocation stress test, not a prophecy. David Cahn's 2024 Sequoia essay took a projected NVIDIA data-center revenue run rate, doubled it for non-GPU data-center cost, and doubled it again for a 50% downstream gross-margin assumption. The result asked whether end-user AI revenue could justify the infrastructure being built.

That historical model was intentionally simple. In 2026, the useful task is to preserve the question while replacing the headline with a model that exposes depreciation, operating cost, financing, utilization, price, and customer value.

Key Takeaways

• The $600B number is an output of a 2024 assumption set, not an audited industry liability.
• Comparing infrastructure spend with "AI revenue" requires matched periods, entities, accounting scope, and treatment of internal cloud consumption.
• Capital return depends on installed and usable capacity, not announced projects or purchased accelerators alone.
• Falling energy or compute per simple query can coexist with rising total demand as reasoning, video, and agentic workloads expand.
• Application economics should be measured per accepted business outcome, after inference, tools, review, support, and failure costs.
• Use scenario ranges and sensitivity analysis; a single break-even number hides the variables that matter.

Reconstruct the Original $600B Scenario

The 2024 framework used two explicit multipliers:

projected NVIDIA data-center run rate
    x 2 for total data-center cost beyond GPUs
    x 2 for a 50% downstream gross-margin assumption
    = implied annual end-user revenue

The arithmetic is transparent, but each term is contestable:

The model is valuable because it makes a large claim falsifiable. It becomes misleading when the resulting $600B is repeated without the date and assumptions.

What Changed by 2026

Current evidence strengthens both sides of the argument.

The International Energy Agency reports that capital expenditure by the largest technology companies exceeded $400 billion in 2025 and was expected to rise another 75% in 2026. It also observes that not every announced project will be completed and that grid connections, energy equipment, chip manufacturing, financing, and local acceptance constrain deployment.

At the same time, demand and efficiency are both moving quickly. The IEA estimates that energy use per individual AI task has fallen by at least an order of magnitude annually in recent years, while reasoning, video, and agentic tasks can consume hundreds or thousands of times more energy than a simple text query. Total data-center electricity use is therefore driven by efficiency, adoption, and workload mix together.

Sequoia's later "Tale of Two AIs" frames 2026 as a collision between data-center delays and continued application adoption. That is an investor perspective, not neutral measurement, but it identifies the right separation: infrastructure completion and application demand can move in different directions.

The 2026 question is no longer only "where is the revenue?" It is:

1. How much announced capital becomes deployed, energized capacity?
2. What utilization and price does that capacity achieve by workload?
3. Which revenues are incremental and attributable to AI?
4. What contribution remains after variable compute, support, review, and failure costs?
5. Does the return exceed financing cost before the asset loses economic value?

Separate Three Economic Layers

Do not combine the economics of infrastructure owners, model providers, and applications.

An internal productivity gain can justify CapEx without appearing as external AI revenue, but it still needs evidence: cycle time, labor reallocation, quality, risk, and opportunity cost. Conversely, high reported revenue can coexist with weak returns if serving and support costs absorb it.

Build an Auditable Capital-Return Model

Start with a cash hurdle rather than a slogan:

annual capital recovery = deployed capital / economic life
annual operating cost = deployed capital x operating-cost rate
annual required return = deployed capital x required return rate
annual revenue hurdle = recovery + operating cost + required return
accepted outcomes required = revenue hurdle / contribution per accepted outcome

This is still a simplified model. Taxes, working capital, residual value, ramp time, lease structure, internal transfer pricing, and uneven cash flows may matter. Its advantage is that every assumption is visible.

The following standard-library Go program calculates three scenarios and makes the unit of value explicit.

package main

import (
	"encoding/json"
	"fmt"
	"os"
)

type scenario struct {
	Name                   string  `json:"name"`
	DeployedCapital        float64 `json:"deployed_capital"`
	EconomicLifeYears      float64 `json:"economic_life_years"`
	AnnualOperatingRate    float64 `json:"annual_operating_rate"`
	RequiredReturnRate     float64 `json:"required_return_rate"`
	ContributionPerOutcome float64 `json:"contribution_per_outcome"`
}

type result struct {
	Name                     string  `json:"name"`
	AnnualCapitalRecovery    float64 `json:"annual_capital_recovery"`
	AnnualOperatingCost      float64 `json:"annual_operating_cost"`
	AnnualRequiredReturn     float64 `json:"annual_required_return"`
	AnnualRevenueHurdle      float64 `json:"annual_revenue_hurdle"`
	AcceptedOutcomesRequired float64 `json:"accepted_outcomes_required"`
}

func evaluate(s scenario) (result, error) {
	if s.DeployedCapital <= 0 || s.EconomicLifeYears <= 0 {
		return result{}, fmt.Errorf("%s: capital and economic life must be positive", s.Name)
	}
	if s.AnnualOperatingRate < 0 || s.RequiredReturnRate < 0 || s.ContributionPerOutcome <= 0 {
		return result{}, fmt.Errorf("%s: rates and contribution are invalid", s.Name)
	}
	recovery := s.DeployedCapital / s.EconomicLifeYears
	operating := s.DeployedCapital * s.AnnualOperatingRate
	requiredReturn := s.DeployedCapital * s.RequiredReturnRate
	hurdle := recovery + operating + requiredReturn
	return result{
		Name:                     s.Name,
		AnnualCapitalRecovery:    recovery,
		AnnualOperatingCost:      operating,
		AnnualRequiredReturn:     requiredReturn,
		AnnualRevenueHurdle:      hurdle,
		AcceptedOutcomesRequired: hurdle / s.ContributionPerOutcome,
	}, nil
}

func main() {
	scenarios := []scenario{
		{Name: "base", DeployedCapital: 1e9, EconomicLifeYears: 4, AnnualOperatingRate: 0.12, RequiredReturnRate: 0.08, ContributionPerOutcome: 20},
		{Name: "short-life", DeployedCapital: 1e9, EconomicLifeYears: 3, AnnualOperatingRate: 0.12, RequiredReturnRate: 0.08, ContributionPerOutcome: 20},
		{Name: "lower-margin", DeployedCapital: 1e9, EconomicLifeYears: 4, AnnualOperatingRate: 0.12, RequiredReturnRate: 0.08, ContributionPerOutcome: 12},
	}

	results := make([]result, 0, len(scenarios))
	for _, item := range scenarios {
		value, err := evaluate(item)
		if err != nil {
			fmt.Fprintln(os.Stderr, err)
			os.Exit(1)
		}
		results = append(results, value)
	}
	output, err := json.MarshalIndent(results, "", "  ")
	if err != nil {
		fmt.Fprintln(os.Stderr, err)
		os.Exit(1)
	}
	fmt.Println(string(output))
}

The values are illustrative, not forecasts. Replace them with sourced, date-matched inputs and keep base, downside, and upside scenarios. The most useful output is often sensitivity: shortening economic life or reducing contribution per outcome can change required volume more than a small improvement in token cost.

Model Utilization and Deployment Delay

Purchased hardware does not become revenue-generating capacity immediately. Track at least four states:

1. Ordered: contract signed, but delivery and cancellation risk remain.
2. Delivered: equipment exists, but the site may lack power, networking, or cooling.
3. Energized: capacity can run, but workload scheduling and software may limit use.
4. Productive: capacity serves accepted workloads at measurable contribution.

Use productive utilization in the return model. A high cluster utilization rate can still be economically weak if jobs are internal experiments, discounted commitments, or retries that never produce accepted outcomes.

The IEA's physical evidence is a useful counterweight to purely financial models: global data-center electricity consumption grew 17% in 2025, while AI-focused data-center consumption grew 50%; its central projection rises from 485 TWh in 2025 to about 950 TWh in 2030. These are system-level estimates, not a revenue forecast, but they show why grid and equipment constraints belong in the capital model.

Price the Application by Accepted Outcomes

For an application, token revenue and token cost are intermediate measurements. The durable unit is an accepted business outcome:

contribution per accepted outcome
  = price or verified customer value
  - model inference
  - retrieval and tool calls
  - human review
  - support and remediation
  - expected failure and compliance cost

Examples include a merged code change, a resolved support case, a reviewed document, or a completed transaction. Define acceptance independently of the model and prevent the system from lowering quality to improve throughput.

Monitor:

• task acceptance and repeat use by customer cohort;
• gross and contribution margin per accepted outcome;
• human minutes and escalation rate;
• retries, failures, refunds, and incident cost;
• latency and capacity consumed by successful versus rejected work;
• retention after promotional pricing ends.

An Agent that uses more tokens can be economically better if it completes more valuable work. A cheaper model can be worse if it creates more review or failure cost.

Use a Decision Dashboard, Not One Gap Number

The infrastructure thesis should be reviewed with several linked indicators:

No row proves a bubble or disproves one. The decision comes from whether the same cohort of assets and customers moves from capital commitment to accepted value and cash generation.

Failure Modes in AI CapEx Analysis

Avoid these shortcuts:

• treating the original $600B scenario as a current audited requirement;
• comparing one-year CapEx with a revenue run rate from another period;
• subtracting private-company estimates from public-company accounting;
• counting all hyperscaler CapEx as AI-specific without disclosure;
• treating announced projects as deployed capacity;
• using accounting depreciation as a guaranteed economic life;
• assuming lower inference cost always raises margin;
• using tokens, seats, or demos as a proxy for accepted outcomes;
• assuming agents automatically create value because they perform more steps;
• ignoring power, network, financing, and local permitting constraints.

Review Checklist

Before approving an infrastructure or application investment:

1. Name the asset, workload, customer, and accounting boundary.
2. Separate ordered, delivered, energized, and productive capacity.
3. Use source dates and reconcile fiscal periods.
4. Model economic life, residual value, financing, and ramp delay.
5. Stress utilization, price, operating cost, and contribution margin.
6. Define one independently verifiable accepted outcome.
7. Include review, support, failure, security, and compliance costs.
8. Compare build, reserve, and API purchase options.
9. Establish stop, resize, or renegotiation triggers.
10. Re-run the model when workload mix, hardware, pricing, or energy constraints change.

Conclusion

The $600 billion question remains useful because it forces the AI industry to connect infrastructure investment with end-user value. Its original number should remain attached to its 2024 assumptions. In 2026, a stronger analysis follows each dollar from deployed capital through productive utilization to contribution from accepted outcomes, while accounting for physical bottlenecks and economic life. That model will not predict the cycle perfectly, but it makes disagreement auditable and investment decisions reversible.

Primary Sources

• Sequoia Capital: AI's $600B Question
• Sequoia Capital: AI in 2026 - A Tale of Two AIs
• IEA: Key Questions on Energy and AI

Related Resources

• AI Inference Cost Economics
• AI Agent Development Guide
• Inference
• Token
• AI Agent