Right-Sizing Your Intelligence Spend

What the public scoreboard celebrates — and how narrow it really is.

In May, OpenAI reported that a general-purpose internal model had disproved a central conjecture in Erdos's planar unit-distance problem, a question mathematicians had worked on for nearly eighty years; external mathematicians checked the proof. Anthropic reports that Claude Opus 4.6 has found and validated more than 500 high-severity vulnerabilities, including bugs in codebases fuzzed for years.

When the answer is unknown and discovering it could be worth millions — a proof, a drug target, a zero-day, or an unfamiliar market structure — maximum intelligence is exactly what we should want. Spending more computation to explore more possibilities is rational.

But the public scoreboard is shaped by the work that can be cleanly stated and verified: proofs, patches, exploits, and scientific reasoning. The only problem is that the rest of the economy does not work that way.

Frontier research is extraordinarily valuable and economically narrow; the moat is not thinking better — it is knowing how your world works.

BLS data shows life, physical and social-science occupations account for less than 1% of American employment: roughly 2,000 mathematicians, 20,000 physicists and 37,000 computer and information research scientists — versus millions of nurses, managers, administrators, logistics workers and customer-service representatives.

What makes Walmart, UnitedHealth and Amazon defensible is not superior frontier intelligence: it is proprietary data, dense operational context, long-built processes, supplier relationships, regulatory licenses, physical networks, and the accumulated judgment that only comes from performing the same class of decision millions of times. Replacing every employee at American Airlines, Home Depot or Medtronic with a math olympiad would drown the organization in intelligence it cannot productively use.

The core of the thesis: below the threshold the model cannot perform the task; above it, the bottleneck changes.

Every workload has some intelligence threshold. Below it, the model cannot perform the task. As the model approaches it, greater intelligence creates enormous value. Once the threshold has been crossed, the bottleneck changes. The outcome depends increasingly on whether the system knows the company's policies, customers, history, tools and standards — and whether it can act reliably, quickly and cheaply.

Models keep getting more intelligent, but most workloads are not. Refund policies, baggage rules and invoice-reconciliation procedures are not getting any harder. The latest frontier models are optimized for extreme intelligence — the kind required by research mathematicians, physicists, and engineers solving previously unsolved problems. That market is real. It is also small.

Two trends are eroding the frontier premium: the shift from closed to open-weight models (e.g. Qwen3.8-27B), which lowers the cost of a given level of capability, and the shift from frontier-scale to small and mid-sized models, which compresses that capability into a much smaller compute footprint.

Models are overqualified too — with a more persistent failure mode than humans: they never get bored and quit.

Developers naturally reach for the most capable system available, and frontier products make that choice frictionless: long-running agents, recursive sub-agents, and high-effort reasoning loops that burn tokens by design. The result is frontier-priced intelligence applied to tasks that often do not need it.

Have you ever hired an employee that was dramatically overqualified for a role? They may reconsider settled decisions, introduce unnecessary complexity, become bored and eventually leave. Models are overqualified too, but instead of getting bored and quitting, they keep generating extra complexity, variance and cost indefinitely.

Overqualification is now measurable. Researchers studying reasoning models have documented an overthinking problem: models routinely spend additional inference compute on easy questions without improving accuracy. Amazon researchers estimate that reasoning systems can generate 7 to 10× as many tokens as necessary on simple tasks. On sufficiently easy workloads, the marginal reasoning token can approach zero.

One player is paid to increase the size of the fire. The other is paid to put it out and keep it from starting again.

The data already shows the gap. OpenAI reports that average reasoning-token consumption per enterprise organization rose approximately 320-fold over the past year. PwC's survey of 4,454 CEOs found that 56% had not yet seen a significant financial benefit from AI. Measurable business outcomes are not keeping pace. If an enterprise's goal is to reduce intelligence consumed per successful outcome, it cannot leave every decision about intelligence consumption to the model provider — that control must live inside the enterprise at every layer.

What happens once enterprises own the allocation of intelligence.

Beneath those harnesses, a new improvement layer will emerge: platforms such as Applied Compute's AC2 allow companies to train, evaluate, serve and replace the models operating inside their existing applications. The proactive assistant becomes the demand aggregator; the application harness becomes the execution system; AC2 becomes the specialization and improvement infrastructure that continuously moves each workload toward the least expensive system still capable of the correct outcome.

The most intelligent enterprise is not going to chase the frontier models blindly for all work. It will be the one that has learned how to need intelligence the least, turning yesterday's expensive reasoning into tomorrow's cheaper, more reliable execution.

Progress will not be measured by how much intelligence a company can afford to consume, but by how quickly intelligence consumed per successful outcome falls toward zero.

Four sample intel:RoutingPolicy instances that encode the article's allocation logic for the sample workloads.

Executable queries against the sample workload dataset, modeled as schema:SoftwareSourceCode with target URIBurner.

PREFIX intel: <https://linkeddata.uriburner.com/DAV/demos/daas/ontology/intelligence-allocation#>
PREFIX schema: <http://schema.org/>

# Which workloads should run on which intelligence tier?
SELECT ?tierName (COUNT(?wl) AS ?workloadCount) (SAMPLE(?wlName) AS ?exampleWorkload)
WHERE {
  ?wl a intel:WorkloadProfile ;
      intel:requiresTier ?tier ;
      schema:name ?wlName .
  ?tier schema:name ?tierName .
}
GROUP BY ?tierName
ORDER BY DESC(?workloadCount)

PREFIX intel: <https://linkeddata.uriburner.com/DAV/demos/daas/ontology/intelligence-allocation#>
PREFIX schema: <http://schema.org/>

# Is most enterprise work discovery or application?
SELECT ?valueClassName (COUNT(?wl) AS ?count)
WHERE {
  ?wl a intel:WorkloadProfile ;
      intel:hasValueClass ?vc .
  ?vc schema:name ?valueClassName .
}
GROUP BY ?valueClassName
ORDER BY DESC(?count)

PREFIX intel: <https://linkeddata.uriburner.com/DAV/demos/daas/ontology/intelligence-allocation#>
PREFIX schema: <http://schema.org/>

# Which workloads still need maximum intelligence (extreme threshold)?
SELECT ?wlName ?thresholdName ?tierName
WHERE {
  ?wl a intel:WorkloadProfile ;
      schema:name ?wlName ;
      intel:hasIntelligenceThreshold ?th ;
      intel:requiresTier ?tier .
  ?th schema:name ?thresholdName .
  ?tier schema:name ?tierName .
  FILTER(?thresholdName = "Extreme")
}
ORDER BY ?wlName

PREFIX intel: <https://linkeddata.uriburner.com/DAV/demos/daas/ontology/intelligence-allocation#>
PREFIX schema: <http://schema.org/>

# Every demo workload instance from the article, with threshold and recommended tier
SELECT ?name ?threshold ?tier
FROM <https://linkeddata.uriburner.com/DAV/demos/daas/right-sizing-intelligence-spend-deepseek_v4flash-1.ttl>
WHERE {
  ?workload a intel:WorkloadProfile ;
            schema:name ?name ;
            intel:hasIntelligenceThreshold ?th ;
            intel:requiresTier ?tier .
  ?th schema:name ?threshold .
  ?tier schema:name ?tier .
}
ORDER BY ?name

A six-step operating procedure derived from the article's thesis; each step links to its absolute-IRI schema:HowToStep entity.

Thirteen questions and answers probing the thesis, wrapped in a schema:FAQPage with schema:mainEntity.

Sixteen terms wrapped in a schema:DefinedTermSet, each linked to its schema:DefinedTerm entity and aligned to the ontology via rdfs:seeAlso.

The article's comment thread, modeled as schema:Comment entities. All sixteen comments — authors, profile URLs and verbatim text — were extracted from the live thread via an authenticated browser session (Playwright + Chrome, 2026-08-19); replies are marked. Kingsley Uyi Idehen first, then the thread in document order.