The Token Is Not the Unit

A friend working at one of Australia’s major banks sent me a message in Portuguese:

“Pessoal começou a descobrir que Claude não é de graça. A partir de agora o padrão é só liberar o Sonnet como padrão pra todo mundo, e o Opus é só pra ‘power users’.” 😜

In English:

“People have started discovering that Claude isn’t free. From now on, Sonnet will be the default for everyone, and Opus will only be available to ‘power users’.”

It is funny because it is true.

The AI bill has arrived.

Now comes the entirely predictable response.

Use the cheaper model by default. Restrict access to the expensive model. Introduce per-person limits. Ask why one engineer consumed A$5,000 of inference in a month. Create a category called “power users” and make access to the frontier model an exception requiring approval.

From a conventional cost-control perspective, that response is perfectly rational.

It may also be catastrophically wrong.

Not because Claude is free.

It is not.

Not because every engineer should have unlimited access to the most expensive model.

They should not.

And not because AI expenditure should escape financial scrutiny.

It absolutely should not.

The problem is more fundamental.

Most organisations can see the cost of AI, but they cannot yet see the production function it is creating.

The token bill arrives before the force multiplier becomes visible. Leadership sees a new cost centre. Engineers see rapidly increasing capability. Finance sees weak attribution. The resulting proof-of-value gap naturally produces token caps, cheaper-model defaults and pressure to control consumption before the organisation has built a credible way to measure what that consumption returns.

That is the category error at the centre of enterprise AI economics:

The token is a metering unit. It is not an economic unit.

The economically relevant question is not:

How many tokens did this person consume?

It is:

What verified production did the augmented engineering system create, what did that production cost, and did every additional dollar of machine intelligence return enough to justify itself?

This article proposes a complete framework for answering that question.

I call it enterprise AI tokenomics.

The word already has a different meaning in cryptocurrency. I am using it more literally here:

Enterprise AI tokenomics is the discipline of measuring, allocating and governing machine intelligence according to how effectively it converts human capacity into verified outcomes.

It connects four things that organisations currently manage separately:

1. The cost of models, tokens, tools and platforms.
2. The probability that AI-assisted work produces an acceptable result.
3. The change in the engineering production function.
4. The economic value of the capacity created.

The framework is deliberately demanding.

It does not ask Finance to believe AI vendors.

It does not ask executives to accept self-reported productivity.

It does not confuse activity with output.

It does not treat raw lines of code as value.

It does not assume that more software is automatically better.

It does not claim that a 10× engineering force multiplier means 10× business value.

And it does not ask anyone to write a blank cheque.

Instead, it proposes a hard financial hurdle:

For every A$1 of incremental AI compute, require at least A$10 of risk-adjusted additional production capacity.

That is a 10:1 Compute Return Ratio.

At that hurdle, Finance can be extraordinarily conservative without accidentally destroying the upside.

But first, AI needs its equivalent of horsepower.

Section 01AI needs horsepower

Rory Sutherland tells a powerful story about the commercialisation of the steam engine.

An invention, he argues, does not become an innovation merely because it works. It becomes an innovation when it changes behaviour. A technically impressive machine that nobody adopts remains an invention.

Mine owners did not want to hear about boiler capacity, piston length or mechanical specifications.

They wanted to know something much simpler:

How many horses will I no longer need to feed?

James Watt translated the unfamiliar capabilities of the steam engine into a unit that buyers could connect to an existing cost.

That unit was horsepower.

A mine owner could estimate the cost of acquiring, feeding, housing and maintaining horses. Once the engine was expressed in horsepower, the buyer could perform the economic calculation on the back of an envelope.

Horsepower was not primarily an engineering unit created to impress other engineers.

It was a translation unit.

It connected technical capacity to commercial consequence.

In the same conversation, the hosts make the connection to AI directly. Modern AI products present people with model families, version numbers, context windows and technical benchmarks, but do not give buyers an intuitive equivalent of horsepower. They contrast that with Apple’s much more comprehensible promise of “a thousand songs in your pocket”.

Enterprise AI now has the same problem the steam engine had.

A CFO does not fundamentally care that one model consumed 100 million input tokens, generated 12 million output tokens, scored a particular percentage on a coding benchmark or used adaptive reasoning.

Those facts may matter operationally.

They do not answer the investment question.

The CFO wants to know:

What existing production cost, constraint or delay does this intelligence remove?

The modern equivalent of horsepower is the Agentic Engineering Force Multiplier.

The full translation is:

The components have distinct roles:

Product Surface is the production unit.

Force Multiplier is AI’s horsepower.

Compute Return Ratio is the CFO’s purchase rule.

The earned compute envelope is the governance mechanism.

This is the central thesis of enterprise tokenomics.

Section 02A token is fuel, not production

At the time of writing, Anthropic lists Claude Sonnet 5 at US$2 per million input tokens and US$10 per million output tokens. Claude Opus 5 is listed at US$5 per million input tokens and US$25 per million output tokens.

On the price sheet, Opus is therefore 2.5 times as expensive per token.

That appears to make model selection easy.

Use Sonnet unless someone can justify Opus.

But price per token is several layers removed from economic cost.

A token is not a standard unit of intelligence, effort, text, correctness or value.

Different models can use different tokenisers. Anthropic notes, for example, that Sonnet 5’s newer tokeniser produces approximately 30% more tokens for the same text than Sonnet 4.6, meaning the change in effective request cost is not proportional to the published change in per-token price.

Input and output tokens are priced differently.

Cached input is priced differently again.

Cache writes, batch processing, fast service tiers, long contexts, reasoning, retries and tool loops all change the real cost.

Prompt caching can materially reduce the cost of repeatedly loading stable context, and batch processing can change the economics again.

Even inside one model, two tasks consuming the same number of tokens may have completely different economic consequences.

One may produce a correct, integrated capability on the first attempt.

The other may produce plausible-looking output that consumes three hours of human repair, introduces a defect and never reaches production.

The invoice can be identical.

The economics are not.

This gives us the first rule of tokenomics:

Never confuse the price of inference with the cost of an accepted outcome.

The total cost of an AI-assisted task is closer to:

Total task cost =
  inference cost
+ human steering cost
+ context preparation cost
+ verification cost
+ retry and rework cost
+ failure remediation cost
+ cost of delay

A simplified expected-cost formula is:

Expected cost per accepted outcome =
  total cost per attempt
  ----------------------
  probability of acceptance

That is why the more expensive model can be the cheaper production resource.

Suppose one model costs three times as much per run but:

• completes the task in one attempt rather than four;
• requires five minutes of human steering rather than forty;
• produces tests that pass;
• understands the architecture;
• avoids a review cycle;
• reduces the probability of a production defect;
• finishes a critical task a day earlier.

The expensive model may have the lower cost per accepted outcome.

Therefore:

The right default is not the cheapest model. It is the cheapest model that reliably clears the acceptance criteria for the task.

Sonnet as a default can be sensible.

Sonnet as a doctrine is not.

Opus as a controlled escalation can be sensible.

Opus as a prestige benefit for senior “power users” is not.

The choice should be determined by task economics, not organisational status.

Section 03The four layers of enterprise tokenomics

Most organisations stop at the first layer of measurement.

They count tokens.

A mature tokenomics system needs four layers.

Each layer is necessary.

None is sufficient by itself.

Token cost without task outcome is consumption telemetry.

Task success without production measurement may describe isolated wins.

Production multiplication without product judgement can create more software pointed at the wrong problems.

Business outcomes without a production measure are multi-causal and difficult to attribute honestly.

This is why efficiency, effectiveness and value must remain separate.

Section 04Efficiency, effectiveness and value are different truths

The three questions are:

Efficiency

Can the same amount of human engineering capacity produce more verified software?

Effectiveness

Did leadership direct that capacity towards the right customer problems, product bets and technical investments?

Value

Did the resulting capability create revenue, avoid real cost, reduce risk, improve customer outcomes or advance strategy?

The Agentic Engineering Force Multiplier lives in the first layer.

It measures efficiency.

It does not claim to prove effectiveness or business value.

That separation is not a weakness.

It is what keeps the framework intellectually honest.

A 50× production system aimed at the wrong work can produce 50× more waste.

A 2× system aimed at a critical commercial bottleneck may create extraordinary value.

Agentic engineering can multiply the rate at which intent becomes verified software.

It cannot guarantee that the intent was correct.

The pathway is:

Prove the multiplier → unlock new engineering capacity → direct it through established product disciplines → expand the range of economically solvable problems → create and capture value.

This also explains why it is usually impossible to calculate “AI business value” directly from a feature outcome.

A feature’s result depends on:

• customer need;
• product strategy;
• design;
• distribution;
• pricing;
• timing;
• sales;
• adoption;
• operations;
• change management;
• competitive response.

Trying to isolate exactly how much revenue was caused by Claude usually produces false precision.

The narrower claim is more credible:

Did the augmented engineering system materially change the amount of verified production created per unit of human capacity?

That question can be measured.

Section 05The one metric worth proving

The wrong executive metrics are not always useless.

They are merely being asked to answer questions they cannot answer.

Common AI dashboards include:

• licences assigned;
• monthly active users;
• prompts submitted;
• tokens consumed;
• suggestions shown;
• suggestions accepted;
• AI-generated lines accepted;
• pull requests created;
• review comments;
• Jira cycle time;
• vulnerabilities detected.

These measures can help diagnose adoption, training, configuration, workflow constraints and vendor utilisation.

They do not prove that the engineering production function changed.

The primary proof metric is:

Positive net Product Surface per effective engineer coding day, relative to the relevant historical baseline.

In plain English:

How much real, tested product surface can one engineer land in a coding day compared with the pre-agentic baseline?

Product Surface is:

Selected real product and test source code that becomes part of the product after deterministic exclusions and the required quality gates.

It excludes obvious sources of fake volume:

• generated files;
• lock files;
• dependency and vendored code;
• build output;
• bundles and source maps;
• configuration;
• documentation;
• images and binaries;
• caches;
• tooling artefacts.

It is net, not gross:

Net Product Surface =
  selected lines added
- selected lines removed

Net measurement matters because gross additions reward verbosity, rewrites, churn and code movement.

A 50,000-line rewrite that removes 49,900 lines has created 100 net lines of surface, not 50,000.

Negative days do not erase positive production elsewhere. They record zero Product Surface produced and retain deleted surface separately as surface retired.

The denominator is not naive headcount. It uses effective contributors so that a day where one person produced almost all the work and two people made tiny changes is not treated as three equal engineer-days.

The force multiplier is:

Force Multiplier =
  Product Surface per effective engineer coding day
  -------------------------------------------------
  historical baseline Product Surface per engineer coding day

The detailed measurement system uses the Git record, aggregates at the engineer-day level, applies deterministic exclusions, calculates effective contributors, compares current production with a frozen historical baseline and subjects current output to strict quality admission.

In a proprietary analysis across more than 5,000 enterprise repositories, I observed an initial anchor of approximately 120 selected net lines per engineer coding day, with a broader range of roughly 100 to 200.

That is not a universal constant.

Each organisation should calculate its own benchmark from its own engineering record.

Against a 120-line benchmark:

The claim is not that every line contains equal value.

The claim is that if the same organisation, measured through the same processor and exclusions, moves from 120 to 1,200 selected, net, quality-gated lines per effective engineer coding day, its engineering production function has changed.

That is a narrower claim than “AI generated business value”.

It is also more falsifiable.

Section 06Quality is admission, not an adjustment factor

Raw lines of code are a terrible productivity metric.

They have historically rewarded exactly the wrong behaviours:

• unnecessary verbosity;
• copy and paste;
• churn;
• artificial decomposition;
• boilerplate;
• generated artefacts;
• “busy” engineering.

Product Surface does not make raw lines of code respectable.

It defines a different object.

Code does not count because a model generated it.

Code counts because the engineering system verified and integrated it.

Quality is therefore not inferred from volume.

It is a condition of admission.

A production-grade system can include:

• engineer-approved intent and plans;
• explicit acceptance criteria;
• architectural and dependency constraints;
• strict linting and type checking;
• secret scanning;
• dependency and vulnerability scanning;
• architecture enforcement;
• minimum code coverage;
• duplication thresholds;
• static application security testing;
• semantic analysis such as CodeQL;
• infrastructure-as-code scanning;
• licence controls;
• integration tests;
• performance tests;
• container scanning;
• mutation testing;
• reliability and regression suites.

The current agentic system should be held to a stronger, more automated bar than the historical system.

The thesis is not:

AI can produce more code.

The thesis is:

An agentically augmented engineering system can produce orders of magnitude more verified Product Surface while increasing the degree of machine-enforced quality.

The detailed framework treats quality as a defence-in-depth admission system, combining human control of intent and architecture with automated verification of implementation.

At high production rates, this is not optional.

A human review system designed for 1× output cannot linearly absorb 50× output.

If every additional line requires the same human review effort as before, the local speedup simply moves the bottleneck downstream.

The operating model must change with the production function.

Section 07What the evidence does and does not say

Public research on AI coding productivity remains mixed.

DORA’s 2025 research describes AI as an amplifier. It magnifies the strengths of capable organisations and the dysfunctions of struggling ones. Individual coding gains can disappear into downstream disorder in testing, review, security and deployment.

METR’s early-2025 randomised study found that experienced open-source developers working on familiar repositories took 19% longer when using the AI tools available at the time, despite believing that AI had made them faster. METR’s 2026 update found signals moving towards possible speedups, but with broad uncertainty and important selection effects.

These findings are not contradictions to be resolved with a slogan.

They tell us that “Does AI make engineers faster?” is too broad a question.

The answer depends on:

• model capability;
• task type;
• repository familiarity;
• harness design;
• context quality;
• human skill;
• autonomy;
• latency;
• quality automation;
• architecture;
• team design;
• downstream constraints;
• the measurement unit.

Every organisation must measure its own production system.

In my own work, I have measured weekly Force Multipliers of 84.1× and 92.9×.

The 92.9× week included approximately 69,645 lines of net functional TypeScript integrated over five coding days, 163 commits, 15 database migrations and 31 releases.

It was predominantly net-new product capability, not a refactor.

The output passed an engineering system that included zero-warning linting, strict type checking, architecture enforcement, changed-file coverage thresholds, duplication limits, full tests and builds, secret and dependency scanning, vulnerability checks, static analysis and deeper scheduled verification.

Those numbers do not mean:

• 92.9× business value;
• one engineer should replace 92.9 engineers;
• every organisation will reproduce the result;
• every week will sustain the same multiplier;
• all types of engineering are represented equally.

They mean that, in the measured work class and operating context, the production ratio was too large to dismiss as ordinary variance.

The published 84.1× and 92.9× calculations used the active baseline of approximately 150 selected net functional lines per engineer-day at the time. The later formal research framework found a broader cross-repository starting anchor closer to 120.

I would not retroactively change the published figures.

The correct response is methodological transparency:

Make the denominator explicit. Pre-register it. Freeze it for the proof window. Version it. Never change it retrospectively to improve the result.

The objective is not to declare a universal multiplier.

It is to build a credible system in which a multiplier can be proved, challenged, audited and either accepted or rejected.

Section 08The CFO mathematics

Now we can translate engineering horsepower into financial terms.

Let:

H = annual fully loaded human engineering cost

A = annual incremental AI cost
    including inference, licences and allocated platform cost

M = verified Agentic Engineering Force Multiplier

For simplicity, assume:

H = A$200,000 per year

Using salary alone would understate the true organisational cost. A mature model should include superannuation, leave, equipment, management, recruitment, facilities, insurance and other relevant overheads.

The augmented engineer costs:

Augmented cost = H + A

The relative cost per unit of Product Surface is:

Relative unit cost =
  1 + (A / H)
  -----------
       M

The pure financial break-even multiplier is:

Break-even multiplier =
  1 + (A / H)

For a A$200,000 engineer:

This is the first important surprise.

An engineer consuming A$5,000 per month does not need to become 5× or 10× as productive merely to break even.

They need to move from 1× to 1.3×.

If they produce 5× Product Surface at a 30% cost uplift, the relative unit cost becomes:

1.30 / 5 = 0.26

The organisation is producing each unit of Product Surface at approximately 26% of the previous cost.

That is roughly a 74% reduction in unit production cost.

At 10×:

1.30 / 10 = 0.13

The unit cost is approximately 87% lower.

The total engineering spend has increased.

The cost per unit of production has collapsed.

This distinction is fundamental:

A rising AI bill can coexist with dramatically improving economics.

A CFO who watches only the total token bill will see cost growth.

A CFO who watches cost per verified unit of production may see an industrial transformation.

The economic overlay in the Product Surface framework therefore asks Finance to evaluate total augmented cost relative to the verified production created, rather than treating token cost in isolation.

Section 09Break-even is not enough

Finance should not fund AI merely because it crosses break-even.

The hurdle should be much higher.

Let us require:

A$10 of risk-adjusted additional capacity for every A$1 of incremental AI expenditure.

I will call this the Compute Return Ratio, rather than simply ROI, because conventional ROI is often calculated as net benefit divided by cost.

A 10:1 gross benefit-cost ratio corresponds to:

Gross benefit = 10 × cost

Net benefit = 9 × cost

Conventional net ROI = 900%

That is a severe hurdle.

Good.

Let:

R = required Compute Return Ratio

For this framework:

R = 10

The gross additional capacity-equivalent value is:

Gross additional capacity =
  H × (M - 1)

The Compute Return Ratio is:

Compute Return Ratio =
  H × (M - 1)
  -----------
       A

The maximum AI expenditure permitted at the 10:1 hurdle is:

Maximum annual AI spend =
  H × (M - 1)
  -----------
       10

The multiplier required for a given AI budget is:

Required multiplier =
  1 + (10 × A / H)

For a A$200,000 engineer:

Now we have an actual capital-allocation policy.

An engineer, pod or workflow consuming A$5,000 per month must prove at least 4×.

At 4×:

Additional capacity equivalent =
  A$200,000 × (4 - 1)
= A$600,000

Annual AI cost =
  A$60,000

Compute Return Ratio =
  A$600,000 / A$60,000
= 10:1

An augmented system consuming A$10,000 per month must prove 7×.

A system consuming A$15,000 per month must prove 10×.

This is not permissive.

It is not “AI at any cost”.

It is an extraordinarily demanding return requirement.

Yet it still shows why arbitrary A$1,000 or A$5,000 token caps can be economically irrational.

Section 10What a 10× engineer is worth

At a 10× Force Multiplier and a A$200,000 cost basis:

Gross additional capacity equivalent =
  A$200,000 × (10 - 1)
= A$1,800,000 per year

At a 10:1 Compute Return Ratio:

Maximum annual AI spend =
  A$1,800,000 / 10
= A$180,000

Maximum monthly AI spend =
  A$15,000

This does not mean the engineer should deliberately spend A$15,000 per month.

That would confuse an economic ceiling with a spending target.

It means:

Preventing a demonstrably 10× production system from consuming A$6,000 instead of A$5,000 because it exceeded an arbitrary monthly cap is not necessarily financial discipline.

It may be local optimisation.

The business could be protecting A$12,000 of annual budget while constraining hundreds of thousands of dollars of additional production capacity.

At 84.1×, the unadjusted 10:1 calculation produces a theoretical compute envelope of approximately A$138,500 per month.

At 92.9×, approximately A$153,000 per month.

Those are not proposed budgets.

They are diagnostic numbers.

They expose the scale mismatch between the inference cost being debated and the production ratio being claimed.

When a result produces an apparently absurd economic envelope, the responsible reaction is:

1. Audit the baseline.
2. Audit the exclusions.
3. Audit the denominator.
4. Audit the quality gates.
5. Audit whether the result persists.
6. Audit whether the organisation can absorb the output.

If the multiplier fails scrutiny, reject it.

If it survives scrutiny, stop managing the system as though it were an ordinary software licence.

Section 11Capacity equivalent is not automatically cash saving

This distinction is essential.

The formula:

H × (M - 1)

calculates additional engineering capacity equivalent.

It does not automatically calculate cash saved.

Cash cost avoidance occurs only when the organisation avoids expenditure it would otherwise have incurred, such as:

• planned hires;
• contractors;
• outsourced delivery;
• programme extensions;
• additional teams;
• duplicated platforms;
• future support costs.

If the organisation keeps the same people and spends the released capacity on additional work, the result is not immediate payroll saving.

It is capacity release.

That capacity may still be extraordinarily valuable, but it must be described honestly.

There are at least five distinct value pools.

1. Cost avoidance

Planned expenditure is not incurred.

2. Capacity release

The existing team produces more without proportional headcount growth.

3. Acceleration value

Capabilities reach customers or operations earlier.

A simple expression is:

Acceleration value =
  cost of delay per day
× days brought forward

4. Risk reduction

Stronger tests, faster remediation, improved reliability, better controls or reduced operational exposure create value.

5. Option value

The organisation can run more experiments and solve long-tail problems that were previously too small, expensive or slow to justify.

These should not all be added together indiscriminately.

A credible investment case should:

• choose a conservative primary value pool;
• identify additional value separately;
• avoid double counting;
• disclose assumptions;
• distinguish capacity from cash;
• reconcile forecasts with realised outcomes over time.

The biggest long-term effect may not be doing the old backlog faster.

It may be changing which work is economically possible.

When the cost of producing verified software falls by an order of magnitude, problems that once affected too few users to justify a team can become viable.

A new integration for one important customer.

An internal workflow used by twelve people.

A modernisation task that always lost against feature work.

A support tool for a narrow operational process.

A new channel that could never earn its place in the old portfolio.

The feasible problem set expands.

Recent METR work makes a related distinction between uplift on old tasks, uplift on new tasks and uplift in value. When the cost of completing some tasks collapses, people substitute towards different tasks, so productivity measured only against the old task portfolio may miss part of the change.

This is why capacity-equivalent production matters even when it does not immediately remove a salary line.

Section 12A risk-adjusted realisation factor

Finance may reasonably reject the assumption that every dollar of additional engineering capacity will be absorbed and converted into useful output.

The framework can accommodate that conservatism.

Let:

α = economic realisation factor

The factor represents the proportion of additional capacity that Finance is willing to recognise for budget purposes after considering:

• absorption constraints;
• product effectiveness;
• portfolio quality;
• adoption;
• substitution;
• value capture;
• measurement uncertainty.

Then:

Risk-adjusted capacity value =
  α × H × (M - 1)

The Compute Return Ratio becomes:

Compute Return Ratio =
  α × H × (M - 1)
  -----------------
          A

The maximum AI budget at a 10:1 hurdle becomes:

Maximum annual AI spend =
  α × H × (M - 1)
  -----------------
          10

For a A$200,000 engineer operating at 10×:

This is an excellent mechanism for CFOs who want a margin of safety.

Even if Finance recognises only 25% of the capacity-equivalent result, a genuinely 10× system still supports A$3,750 per month of AI spend at a 10:1 hurdle.

At 50% realisation, it supports A$7,500.

The organisation does not need to agree that every unit of Product Surface becomes cash.

It only needs to agree on a conservative realisation factor and then apply it consistently.

Section 13The expensive model may be the cheaper system

The phrase “Opus is more expensive” is incomplete.

More expensive per what?

Per million tokens?

Per run?

Per completed task?

Per accepted pull request?

Per production release?

Per unit of Product Surface?

Per business outcome?

These are not equivalent.

The correct comparison is:

Expected cost per accepted outcome =
  inference
+ human steering
+ verification
+ retry and rework
+ failure risk
+ delay

A lower-capability model may create hidden costs through:

• more prompting;
• more context reconstruction;
• repeated failures;
• smaller task horizons;
• more human intervention;
• more fragmented changes;
• review fatigue;
• shallow tests;
• architectural inconsistency;
• incomplete execution;
• higher defect risk.

A more capable model may cost more per token but require:

• fewer attempts;
• less steering;
• less repair;
• less context repetition;
• fewer handovers;
• fewer review cycles;
• less elapsed time;
• less human attention.

Therefore:

The model with the lowest procurement price may not be the model with the lowest production cost.

This is not an argument to route every task to the frontier model.

It is an argument to route by task economics.

A sensible routing strategy might use:

Lower-cost models

For tasks that are:

• narrow;
• low ambiguity;
• easy to verify;
• highly reversible;
• mechanically repetitive;
• supported by strong tests;
• tolerant of additional iterations.

Frontier models

For tasks that are:

• long-horizon;
• architecturally complex;
• ambiguous;
• context-heavy;
• integration-heavy;
• expensive to fail;
• expensive to delay;
• likely to require deep diagnosis or sustained reasoning.

Human-led execution

For work where:

• customer judgement matters;
• trade-offs are irreversible;
• legal or regulatory exposure is material;
• data sensitivity constrains model choice;
• architecture is still emerging;
• acceptance criteria cannot yet be made explicit.

The governing question should be:

Which approved model, harness and effort level produces the lowest risk-adjusted cost per accepted outcome for this class of work?

A model that cannot legally or safely process the relevant data is not economically eligible, regardless of its theoretical return.

Security, privacy, sovereignty, regulatory and contractual constraints remain hard boundaries.

Economics operates inside those boundaries.

Section 14“Power user” is the wrong category

A “power user” is an entitlement category.

It tells us that someone:

• uses the tool frequently;
• has seniority;
• is considered sophisticated;
• has received permission;
• may consume more.

It says nothing about return on capital.

A better category is:

Power producer

A power producer is not someone who enjoys using the premium model.

It is an engineer, pod, workflow or operating pattern that demonstrably converts machine intelligence into disproportionately more verified production.

The distinction changes the question.

Power user framing:

Why is this person allowed to consume so much?

Power producer framing:

What verified return is this production system creating, and what compute should be allocated to it?

Rory Sutherland gives several examples of small wording changes altering behaviour. In one American Express example, changing the framing from “apply for your card” to what someone needed to do to “receive your card” reduced the psychological fear of rejection.

Language changes what people attend to.

Consider the difference:

This cannot be empty relabelling.

The production language must be supported by a ledger, a baseline and evidence.

But when the evidence exists, the language should represent the economics accurately.

One caution matters:

Do not turn “power producer” into an individual employee leaderboard.

The Force Multiplier is an operating-model metric.

It should not become a quota for lines per person or a ranking of human worth.

The measured unit may be:

• a team;
• a pod;
• a product area;
• a workflow;
• a repository family;
• a defined agentic cohort.

Use the smallest unit with enough signal, but never convert the metric into surveillance theatre.

Section 15The earned compute envelope

The logical alternative to an arbitrary token cap is an earned compute envelope.

The envelope expands or contracts according to demonstrated leverage.

It should have three parts.

1. Discovery envelope

A bounded, time-limited budget for exploring:

• models;
• harnesses;
• agent patterns;
• context strategies;
• skills;
• tools;
• task classes;
• quality controls.

Not every experiment must individually return 10:1.

The discovery portfolio exists to find the high-leverage operating patterns.

2. Earned production envelope

Once a team or workflow demonstrates sustained production leverage, its available compute expands according to the 10:1 formula.

Earned compute envelope =
  α × H × (M - 1)
  -----------------
          10

The envelope is not a spending target.

It is the maximum amount that still preserves the required return.

3. Critical-path exception

Some work should be governed by cost of delay rather than normal monthly limits.

Examples include:

• material incidents;
• security remediation;
• regulatory deadlines;
• critical bids;
• production outages;
• time-sensitive launches;
• customer commitments.

For these tasks, the value of an hour or a day may dwarf the token cost.

The decision should still be recorded and reviewed, but forcing a critical task through a low-cost model because an individual exhausted a monthly allowance can be irrational.

The envelope should also be elastic.

If the multiplier falls, the earned envelope falls.

If quality deteriorates, output stops being admitted.

If the active benchmark changes, the measurement must be rerun consistently.

If the task mix changes, the result must be interpreted against the appropriate work class.

If the multiplier rises and survives audit, the envelope rises.

This is governance through demonstrated economics rather than status.

Section 16Why 10:1 must not eliminate discovery

A severe return hurdle creates one danger.

It can encourage organisations to fund only uses that already have evidence.

That would kill the discovery process required to find the largest multipliers.

Rory describes how large organisations become increasingly risk-averse as decision accountability moves down the hierarchy. A divisional leader may reject a favourable bet because the downside is personally visible, even when the aggregate portfolio economics are attractive.

He also argues that innovation and marketing are fat-tailed activities. A small percentage of experiments may create most of the value, and the organisation cannot know in advance which experiments will become the outliers. In pursuing apparent efficiency, companies often remove the discovery layer that produces future breakthroughs.

Agentic engineering has the same distribution.

Most employees may achieve modest leverage.

Some may become slower.

Some tasks may be poor fits.

Some workflows may create 2×.

A smaller number of combinations may produce 10×, 50× or more.

The mistake would be to design the entire policy around the median before discovering the tail.

Therefore:

Apply the 10:1 hurdle to scaling, not to the existence of experimentation.

Use a portfolio model:

Discovery:
  small bets
  bounded downside
  rapid evidence
  broad search

Production:
  measured multiplier
  strict quality admission
  earned compute
  aggressive scaling

The practical principle is:

Bound the search. Measure the results. Scale the winners.

Rory’s discussion of direct-response advertising provides the experimental method.

Direct-response practitioners tested creative variants, headlines and media placements against observable responses. Small changes could create large differences. The purpose was not to argue theoretically about which approach ought to work. It was to produce evidence.

The same approach should govern AI model selection.

Do not debate Sonnet versus Opus as an identity question.

Run controlled comparisons over coherent task classes and record:

• inference cost;
• human steering time;
• elapsed time;
• first-pass acceptance;
• retries;
• review time;
• defects;
• quality-gate results;
• Product Surface admitted;
• cost per accepted outcome.

Where practical, test one variable at a time.

When changing the entire operating model, acknowledge that the model, harness, context, process and team design are being tested as a combined system.

As Rory puts it, test one thing or test everything. Changing five unrelated variables without a coherent design makes attribution almost impossible.

Section 17Token anxiety is range anxiety with a cloud invoice

Rory tells a story about driving an electric car whose battery display showed 16%.

The remaining absolute range was similar to what he regularly tolerated in another vehicle without concern.

But 16% felt alarming.

The physical situation was not materially different.

The presentation changed the psychological response.

Enterprise AI has the same problem.

A dashboard shows:

A$5,000 of Claude usage this month.

The number is isolated.

It feels uncontrolled.

Now display:

A$5,000 of AI compute produced A$75,000 of risk-adjusted additional engineering capacity, after quality admission, for a 15:1 Compute Return Ratio.

The invoice has not changed.

The decision information has improved.

This is not an argument for psychological manipulation.

It is an argument for completing the denominator.

Token anxiety is rational when production is invisible.

The answer is not to hide the cost.

It is to place the cost next to the return.

An executive AI production dashboard should show:

Tokens, prompts, active users and suggestions can remain available as diagnostic telemetry.

They should not be the headline.

A useful test for any executive metric is:

If this number doubled tomorrow, what material decision would we make differently?

If token consumption doubles, Finance investigates.

If Product Surface rises from 1× to 10× while cost per surface collapses and quality remains green, leadership may reconsider:

• model caps;
• team size;
• hiring;
• contractor dependence;
• portfolio scope;
• programme duration;
• product economics;
• operating model;
• funding.

That is the difference between telemetry and a production metric.

Section 18Reverse benchmarking for AI

Rory calls one of his methods reverse benchmarking.

Instead of studying everything competitors already measure and trying to become marginally better, find the important dimension the entire category has neglected.

Then become disproportionately good at it.

Enterprise AI is currently focused on the obvious dimensions:

• model price;
• benchmark scores;
• token volume;
• context window;
• active users;
• adoption;
• suggestion acceptance;
• latency.

These measures are available and familiar.

The neglected metric is harder:

Cost per unit of verified production.

Anyone can read the Anthropic invoice.

It is much harder to:

• define Product Surface;
• inspect Git history;
• exclude non-product artefacts;
• normalise by effective engineer-days;
• establish a valid baseline;
• freeze the denominator;
• version the processor;
• enforce strict quality gates;
• link inference spend to accepted outcomes;
• separate efficiency from value;
• maintain the ledger continuously.

That difficulty is precisely why the metric matters.

The best enterprise opportunities often sit in dimensions competitors do not measure because the measurement is inconvenient.

Force Multiplier is reverse benchmarking applied to AI production.

Section 19The multiplier is not created by the model alone

A common mistake is to attribute the entire result to the model.

The model matters.

It is not the operating system.

High-leverage agentic engineering combines:

• capable models;
• an effective harness;
• repository context;
• architecture constraints;
• tools;
• memory;
• skills;
• reusable workflows;
• feedback loops;
• quality automation;
• human judgement;
• team design;
• product direction;
• delivery infrastructure;
• governance.

A licence is access.

Access is not adoption.

Adoption is not value realisation.

The model may generate code quickly, but the organisation can still lose the gain through:

• fragmented work;
• handovers;
• slow reviews;
• manual testing;
• security queues;
• release governance;
• unclear ownership;
• poor architecture;
• weak product decisions;
• overloaded teams.

This is consistent with DORA’s finding that AI amplifies the surrounding organisational system rather than independently repairing it.

The goal is not to scale agentic engineering by trusting agents more.

The goal is to make:

• intent clearer;
• context stronger;
• tasks more coherent;
• feedback faster;
• integrations smaller;
• quality gates stronger;
• governance more automated;
• human accountability explicit.

The human role moves up the abstraction stack.

Humans remain responsible for:

• problem framing;
• architecture;
• constraints;
• customer experience;
• taste;
• trade-offs;
• risk;
• acceptance;
• ownership.

Agents perform more of the mechanical production and verification loop.

For complex or high-risk work, the human should remain an active conductor, making incremental decisions and maintaining architectural control.

More autonomous, fire-and-forget patterns are better suited to work that is:

• mechanical;
• well specified;
• reversible;
• observable;
• strongly tested;
• low consequence if repeated.

The question is not whether humans or agents write the code.

It is:

Who thinks, who decides, when feedback enters the loop, and what system determines whether the result is accepted?

Section 20The two ledgers tokenomics requires

A serious tokenomics system needs two connected ledgers.

The compute ledger

For each meaningful run or workflow, record:

• user, team or service;
• task classification;
• model;
• service tier;
• input tokens;
• output tokens;
• cached tokens;
• tool calls;
• retries;
• latency;
• direct inference cost;
• allocated platform cost;
• human steering time;
• verification time;
• completion status;
• acceptance status;
• relevant security classification.

The production ledger

Record:

• repository;
• commit;
• author date;
• selected files;
• selected additions;
• selected removals;
• effective contributors;
• Product Surface produced;
• surface retired;
• quality-gate status;
• release or deployment association;
• active baseline;
• processor version;
• exclusion version.

The two ledgers connect:

Tokens
  ↓
Model run
  ↓
Task outcome
  ↓
Quality admission
  ↓
Product Surface
  ↓
Release or operational outcome
  ↓
Economic interpretation

Most AI dashboards stop between the first and second steps.

Enterprise tokenomics requires the entire chain.

Perfect attribution will not always be possible.

One agent session can influence several commits.

One commit can be supported by several tools.

A human may use AI across analysis, implementation, tests and documentation.

The purpose is not forensic precision at every keystroke.

The purpose is enough traceability to evaluate coherent teams, workflows and periods.

The Git ledger remains the authoritative record of integrated change.

The inference ledger explains the cost of the production system.

Section 21Measurement cadence

The metric should be continuously produced but not impulsively managed.

A practical cadence is:

Daily

Capture source facts, identify anomalies and confirm quality status.

Weekly or fortnightly

Review where the operating model is producing leverage and where agents are getting stuck.

Monthly

Review the sustained Force Multiplier, total augmented cost, cost per Product Surface and earned compute envelope.

Quarterly

Make decisions about:

• model access;
• budgets;
• caps;
• team structures;
• hiring;
• contractor strategy;
• portfolio ambition;
• platform investment;
• operating-model redesign.

Do not make executive decisions from one exceptional day.

Use rolling windows with enough coding-day signal.

Do not change the baseline every time the current system improves.

The baseline answers:

What was normal before?

The current system answers:

What are we producing now?

The multiplier answers:

How far did the production function move?

Section 22The strongest objections

The objections to this framework are important.

They should not be dismissed.

They should shape the measurement design.

“Lines of code are a terrible metric.”

Raw lines of code are a terrible productivity metric.

Product Surface is selected, net, quality-admitted and integrated software surface measured at the operating-system level.

The claim is narrow.

If the same organisation moves from approximately 120 to 1,200 selected net lines per effective engineer-day under the same processing rules and stronger quality gates, the production system has changed.

The metric does not rank engineers or claim that every line has equal value.

“More code is not better.”

Correct.

If a problem can be solved clearly in 100 lines, solving it in 1,000 is waste.

That is why the measure is net, excludes generated artefacts, constrains duplication and maintainability, and operates over broader windows rather than judging one change.

The opportunity is not to make one feature 50 times larger.

It is to make 50 times more economically viable work possible.

“AI code is verbose.”

It can be.

Human code also varies by engineer, language, framework and style.

A 10% or 20% verbosity difference cannot explain a 10× or 100× shift.

Unnecessary verbosity should be constrained by architecture rules, duplication limits, maintainability gates, tests and human judgement.

“This will create AI slop.”

It will if the organisation measures generation instead of admission.

The framework does not count what the model produced.

It counts what the engineering system accepted.

If low-quality output passes every configured gate, the quality system is not strict enough.

The answer is stronger admission, not pretending that unmeasured output does not exist.

“The result does not prove causality.”

Correct.

The hypothesis concerns the combined operating model:

• models;
• harnesses;
• humans;
• workflows;
• context;
• quality automation;
• architecture;
• organisation design.

The objective is not to isolate the causal contribution of every component.

It is to determine whether the current production system materially outperforms the historical one.

“Refactoring and deletion can be valuable.”

Correct.

Positive net Product Surface can undercount a major refactor, simplification or decommissioning.

That is why surface retired is recorded separately and transformation outcomes remain part of operational context.

The framework accepts this limitation rather than rewarding gross churn.

“Not every kind of engineering becomes code.”

Correct.

Product Surface is strongest where capability is expressed in application and test source.

Configuration-heavy platforms, data engineering, infrastructure, model development and other work may require separately defined surface families and relevant historical benchmarks.

Do not force unlike artefacts into one metric.

Use the same principle:

Define a stable production surface, process it consistently and compare it with the appropriate historical record.

“The metric can be gamed.”

Any metric can be gamed when converted into an individual target.

Safeguards include:

• net rather than gross;
• deterministic exclusions;
• day-level aggregation;
• quality admission;
• effective contributors;
• frozen benchmarks;
• minimum signal thresholds;
• coding-day-weighted roll-ups;
• processor versioning;
• separate retirement accounting;
• no individual quotas.

The metric should evaluate the operating model.

It should never determine which human is worth more.

“A 10:1 hurdle is arbitrary.”

It is a policy choice, not a law of nature.

That is intentional.

Finance can choose 5:1, 10:1, 15:1 or another ratio according to risk appetite.

The framework makes the choice explicit.

A 10:1 ratio is useful because it is demanding enough to create a large margin of safety while still revealing how economically small inference cost can become at genuine multipliers.

“Not everyone will produce 84×.”

Correct.

They do not need to.

At A$5,000 per month and a A$200,000 cost basis, the 10:1 threshold is 4×.

At A$1,000 per month, it is 1.6×.

The objective is not universal 90× performance.

It is compute allocation proportional to demonstrated leverage.

“This sounds like headcount reduction.”

It can support cost avoidance, but that is not the only or necessarily the best use.

The capacity may be directed towards:

• more products;
• faster modernisation;
• improved security;
• stronger tests;
• new integrations;
• smaller programme teams;
• shorter delivery windows;
• reduced contractor growth;
• more experimentation;
• previously uneconomic long-tail problems.

Workforce decisions remain human, strategic and social decisions.

The Force Multiplier describes production capacity.

It does not dictate what leadership must do with it.

“Regulated organisations cannot just use any model.”

Correct.

Security, privacy, data residency, record keeping, explainability, legal, model-risk and operational controls are not optional.

The earned compute envelope operates only across approved models, data classes, deployment patterns and use cases.

A high economic return does not override a regulatory boundary.

Section 23Outcome-linked economics is older than software

Rory’s steam-engine story goes further.

Watt and Boulton reportedly supplied more efficient engines and charged customers a proportion of the coal savings.

Rather than selling only a fixed piece of hardware, they aligned their revenue with the economic improvement realised by the mine owner.

Rory describes it as a form of hardware as a service in 1775.

That principle maps directly to agentic engineering.

Internally, the earned compute envelope aligns AI expenditure with measured production uplift.

Externally, it suggests new commercial structures.

Instead of pricing all agentic engineering exclusively through:

• hours;
• day rates;
• team size;
• licences;
• token pass-through;

a provider could combine:

• a base platform or service fee;
• a transparent baseline;
• defined quality admission;
• measurable production or cycle-time improvement;
• a variable component linked to verified uplift.

Engineering value is more difficult to attribute than coal savings.

The contract would need to account for:

• customer dependencies;
• product decisions;
• access delays;
• scope changes;
• adoption;
• quality;
• baseline validity;
• value capture.

Pure shared-savings pricing may therefore be inappropriate.

But the principle remains powerful:

Price and govern intelligence in relation to the outcome it produces, not merely the amount consumed.

The traditional time-and-materials model rewards more human effort.

Agentic economics increasingly rewards compressed effort and verified outcomes.

That will change consulting, managed services, software development and internal capital allocation.

Section 24A compact CFO and CTO operating contract

A functioning tokenomics system requires clear ownership.

Finance owns

• the fully loaded cost basis;
• the Compute Return Ratio hurdle;
• the economic realisation factor;
• budget policy;
• cost-avoidance recognition;
• financial reconciliation;
• challenge and assurance.

Engineering and platform leadership own

• Product Surface definition;
• repository eligibility;
• historical baseline;
• processor and exclusion rules;
• compute and production ledgers;
• model routing;
• harness design;
• quality gates;
• measurement integrity.

Product leadership owns

• problem selection;
• prioritisation;
• customer value;
• adoption;
• effectiveness;
• portfolio direction.

Security, risk and legal own

• approved models;
• data classifications;
• deployment constraints;
• privacy;
• assurance;
• auditability;
• regulatory boundaries.

Executive leadership owns

• where multiplied capacity is directed;
• whether organisation design should change;
• whether hiring assumptions remain valid;
• whether the portfolio should become more ambitious;
• how realised benefits are shared.

No single function can credibly own the full equation.

Finance cannot determine engineering production from the invoice.

Engineering cannot declare financial value from code volume.

Product cannot claim causal attribution without the production record.

The compact works because each function owns a different truth.

Section 25A 90-day implementation sequence

An organisation can begin without building a perfect enterprise measurement platform.

Days 1 to 15: Define the proof

1. Select a coherent engineering cohort, product area or technology family.
2. Calculate the fully loaded engineering cost basis.
3. Define what counts as Product Surface.
4. Define deterministic exclusions.
5. Select the historical evidence window.
6. Pre-register the baseline methodology.
7. Choose the Compute Return Ratio, ideally 10:1.
8. Select an initial economic realisation factor.

Days 16 to 30: Build the ledger

1. Process the historical Git record.
2. Exclude low-signal repositories.
3. Establish the active baseline.
4. Version the processor and filter.
5. Instrument AI inference and tooling costs.
6. Capture task class, model, retries and outcome status.
7. Connect compute events to engineering work where practical.

Days 31 to 45: Establish quality admission

1. Make intent and acceptance criteria explicit.
2. Add strict linting and type checks.
3. Enforce architecture and dependency rules.
4. Set coverage and duplication thresholds.
5. Add secret, dependency and vulnerability scanning.
6. Add authoritative CI checks.
7. Add scheduled deep verification.
8. Confirm that failed quality gates exclude output from Product Surface.

Days 46 to 60: Run bounded discovery

1. Test several model and harness combinations.
2. Select coherent task classes.
3. Record human steering and verification time.
4. Compare cost per accepted outcome.
5. Identify where the agentic operating model fails.
6. Remove bottlenecks.
7. Do not impose production-scale caps during bounded discovery.

Days 61 to 75: Calculate production economics

1. Measure the rolling Force Multiplier.
2. Calculate total augmented cost.
3. Calculate cost per Product Surface.
4. Apply the economic realisation factor.
5. Calculate the Compute Return Ratio.
6. Calculate the earned compute envelope.
7. Separate cost avoidance from capacity release and acceleration.

Days 76 to 90: Make the operating decision

1. Reduce or redirect spend where the multiplier is absent.
2. Improve the harness where the task fit is weak.
3. Expand selectively where the result is promising but uncertain.
4. Scale aggressively where the multiplier is sustained, quality-admitted and economically compelling.
5. Review team design and downstream bottlenecks.
6. Establish monthly and quarterly governance.
7. Keep discovery funding separate from earned production funding.

The operating rule is simple:

If the multiplier is absent, limits are rational.

If the multiplier is present, arbitrary limits are irrational.

Section 26The policy in one equation

The entire financial policy can be expressed as:

Permitted annual AI spend =
  economic realisation factor
× annual human engineering cost
× (verified Force Multiplier - 1)
÷ required Compute Return Ratio

Or:

Amax = αH(M - 1) / R

Where:

Amax = maximum economically supported annual AI spend

α    = economic realisation factor

H    = fully loaded annual human engineering cost

M    = verified Force Multiplier

R    = required Compute Return Ratio

For this article:

R = 10

The matching access rule is:

Allow the cheapest approved model that reliably clears the task’s acceptance criteria. Escalate automatically when a more capable model lowers the risk-adjusted cost per accepted outcome. Expand compute only where the measured production system continues to clear the 10:1 hurdle.

That is enterprise tokenomics.

Not free tokens.

Not unlimited inference.

Not executive enthusiasm.

Not procurement by sticker price.

Measured intelligence under an aggressive return constraint.

Section 27A letter to Australian CFOs

Dear CFOs,

You are right to challenge the AI bill.

You are right to ask whether thousands of licences are being used.

You are right to ask why one engineer consumed A$5,000 in a month.

You are right to demand evidence when someone claims a 10×, 50× or 90× multiplier.

Audit the baseline.

Audit the exclusions.

Audit the denominator.

Audit the quality gates.

Audit the cost allocation.

Audit persistence.

Audit whether the organisation can absorb the capacity.

Audit whether it becomes value.

But please do not stop at the invoice.

The token is not the unit.

A token tells you how a vendor meters the machine.

It does not tell you how much engineering production the machine created.

It does not tell you how much human time it released.

It does not tell you how many retries it avoided.

It does not tell you whether the output passed security, testing and architecture controls.

It does not tell you whether the work reached production.

It does not tell you whether a critical release arrived three months earlier.

It does not tell you whether a A$5,000 inference bill avoided a A$500,000 delivery cost.

Claude is not free.

Opus is not free.

Sonnet is not free.

Neither are engineers.

Neither are contractors.

Neither are delivery teams.

Neither are handovers.

Neither are review queues.

Neither are delayed programmes.

Neither are missed market windows.

Neither are defects.

Neither is waiting six months to learn what the customer could have told you next week.

So keep the hard financial hurdle.

Make it 10:1.

For every dollar of incremental AI compute, demand ten dollars of risk-adjusted additional production capacity.

If the system cannot prove it, constrain the spend.

If it can prove it, do not optimise the token while destroying the multiplier.

Do not ask who deserves access to Opus because they are a “power user”.

Ask which approved model, task and operating pattern produces the lowest cost per verified outcome.

Do not ask only whether AI expenditure increased.

Ask whether cost per unit of production fell.

Do not ask the model how productive the engineer feels.

Read the engineering record.

Do not assume 90×.

Make the system prove it.

But once it does, act on the evidence.

Force Multiplier is AI’s horsepower.

Product Surface is the instrument that measures it.

The 10:1 Compute Return Ratio is the purchase rule.

The earned compute envelope is the governance mechanism.

The token is fuel.

Verified production is the unit.