You Have One Job

What predicting the World Cup says about enterprise AI, compute costs, and right-sizing.

On July 19th, Ferran Torres came off the bench and scored in the 106th minute at New York / New Jersey¹ MetLife Stadium. Spain 1-0 over Argentina. The second World Cup for La Roja, and perhaps the final match of Lionel Messi’s Argentina career.

Photo by Waseem R on Unsplash

My model called that final in June, before a ball was ever kicked.

It called it again the week of the final. Same answer both times: Spain over Argentina.

No massive database. No real-time odds tracking. Just a simple set of rules running in memory.

The experiment

Like most I’ve been building at Differential Factor, the World Cup model started as an experiment. I wanted to test some new predictive modeling workflows - and Anthropic just happened to release their new Claude Fable model around the same time². As an avid soccer fan, the World Cup offered the perfect data-rich playground.

Going in, I assumed a frontier model would help me design something complex and powerful - a system that could ingest match stats, account for tactical coaching shifts, and pick non-obvious upsets.

That’s not what happened.

Instead, what Fable helped me build was small. Very small. It is printed below, and it runs in a rounding error’s worth of memory.

{
 "params": {
  "version": "v1.0.0",
  "K": 50,
  "HOST_ADV": 100,
  "ALT_PER_1000M": 35,
  "HEAT_PER_10C_OVER_28": 12,
  "REST_PER_DAY": 8,
  "REST_CAP_DAYS": 3,
  "GD_SCALE": 250,
  "GD_CLAMP": 2.5,
  "TOTAL_GOALS": 2.7,
  "MIN_LAMBDA": 0.15,
  "GOAL_GRID": 9
 },
 "version": {
  "id": 1,
  "version": "v1.0.0",
  "created_at": "2026-06-11 13:58:55",
  "params_json": "{\"version\": \"v1.0.0\", \"K\": 50, \"HOST_ADV\": 100, \"ALT_PER_1000M\": 35, \"HEAT_PER_10C_OVER_28\": 12, \"REST_PER_DAY\": 8, \"REST_CAP_DAYS\": 3, \"GD_SCALE\": 250, \"GD_CLAMP\": 2.5, \"TOTAL_GOALS\": 2.7, \"MIN_LAMBDA\": 0.15, \"GOAL_GRID\": 9}",
  "change_note": "Initial public model. Covariate coefficients are declared assumptions, not estimates."
 }
}

And it nailed the outcome that mattered most.

Where it lost

To be clear, this isn’t a victory lap.

Across all 104 matches, the betting markets beat my model handily—especially in the group stage. A tiny set of rules can’t account for a team resting starters once they’ve already qualified, lineup leaks, sudden injuries, or squad drama. Betting markets, of course, are experts at capturing real-time news and subtle coaching shifts.

On aggregate, the markets won. But on the single question that mattered most, the simple model got it right.

Small vs the supercomputer

All summer, Sports Illustrated ran projections from the Opta supercomputer. Massive infrastructure, continuous data pipelines, updated after every match.

Look at how Opta’s predictions shifted over time. France kept climbing while Spain drifted down. Of course, France didn’t even make the final.

To be fair, my model wasn’t entirely immune to matchday noise either. As the live tracking chart shows, a surge in France’s late-stage metrics temporarily bumped them ahead in our simulations around July 9th.

But here’s a crucial difference: because my model relied on a tight, bounded set of core rules, it quickly recalibrated back to its foundational premise. It called Spain over Argentina in June before the tournament started, and held that final stance in July.

Opta’s supercomputer, by comparison, had no way to pull itself back. Because it ingested five weeks of live match data—shot charts, expected goals (xG), match results—it continuously refined itself away from the right answer.

More compute. More data. Continuous tuning. All driving a massive system further in the wrong direction.

Two brief caveats before I draw enterprise parallels:

• Probabilities aren’t predictions. Opta outputs probability distributions, not binary picks. Giving France a 34% chance isn’t “wrong” when Spain wins. The issue isn’t Opta’s math - it’s the media narrative framing it as a “supercomputer prophecy.” Those same misplaced expectations are too often forced on enterprise AI - and AI in general.

• n=1. Calling one final correctly is a nice story, but not statistical proof. Over ten tournaments, Opta’s engine would likely win on average.

The Job to be Done

The Job to be Done here wasn’t “outperform a supercomputer across 104 individual matches.” The job was “predict the tournament winner.” For that specific outcome, a tiny heuristic model was entirely sufficient.

Would routing this problem through a massive, multi-billion-parameter frontier model have shaved a few percentage points off our variance? Probably. Would it have changed the actual business outcome? Not at all.

Yet in most enterprise AI discussions, this distinction gets completely buried under executive panic.

When a board asks, “What’s our AI strategy?”, the instinct is to provision the biggest, most capable model available. Nobody wants to look like they’re cheaping out or falling behind in the race to become “AI-native.” But provisioning an expensive frontier model without scoping the task is like hiring a team of PhDs to sort incoming mail.

Or like driving a Ferrari to the grocery store, as I wrote about a few days before the tournament.

So what is the job, actually?

Most enterprise tasks aren’t open-ended reasoning puzzles. They are bounded, specifiable, and repetitive:

• Classify an inquiry

• Extract three fields from an invoice

• Route a support ticket

• Summarize a call

Well-defined jobs don’t need frontier models. They need right-sized models. Focused models that run quickly, cheaply, and reliably—and often run perfectly well on a local device or edge node.

Where the frontier earns its money

Saying “small models are often enough” isn’t the same as saying “frontier models are a waste.”

The frontier is where synthesis and ideation lives. It’s built for ambiguous problems, novel framing and cross-domain reasoning.

Look at what actually happened in this experiment: I used a frontier model once, to act as the architect. I asked it to help me figure out how to frame the problem, combine team skills ratings (Elo) with expected goal distributions (Poisson) and then build a Monte Carlo simulator to run thousands of bracket outcomes.

Once Fable helped write those core rules, its work was done. I no longer needed a multi-billion-parameter LLM to run daily simulations or track match-by-match Brier scores, which is how we ranked against the betting markets. I just needed the tiny, lightweight script it helped me create.

That is the core pattern. Frontier to think. Small to run.

The mistake isn’t using frontier models - it’s overusing them as runtime workhorses. Deploying a massive, high-cost model for a daily execution job means paying a steep and unnecessary compute tax on every inference. Right now, that’s exactly what too many organizations are doing.

My commute as an example

I drive a Tesla Model 3, which is a terrific commuter car for my trips to and from Northeastern University, where I teach. The local model in my car is very good at one thing: keeping me on the road. It’s fast, local, and hyper-optimized for its specific environment.

But as I sometimes tell my classes once I arrive—that same model would be completely useless at filing my taxes.

My World Cup model would, of course, be useless for both. But for predicting the tournament, it matched the scope of the problem effectively.

Matching the tool to the task used to be standard engineering discipline. Somehow, in the AI gold rush, enterprise leadership has lost that instinct entirely. The default setting has become reaching for the largest, most expensive model available—regardless of what it’s actually being asked to do.

Why this is a capital story

This isn’t just an operational detail—it’s a macro capital story.

Today’s AI infrastructure spending surge relies heavily on a single implicit assumption: universal frontier dependency. The belief that every enterprise workflow, agent, and query must route through the largest, most expensive cloud models available.

That assumption underpins massive capital allocations across venture portfolios, hyperscaler projections, and corporate IT budgets. But a tiny heuristic model correctly predicting the World Cup isn’t just a fun math story—it’s a direct counter-argument.

If most business tasks only require targeted, small-footprint models, the true long-term demand curve for frontier compute looks fundamentally different than what the market has priced in.

The rapid rise of open-weight models is forcing enterprise leaders to rethink their deployment strategies—driven primarily by pure cost pressure. While open-weight doesn’t automatically solve the engineering complexity of hosting, fine-tuning, and maintenance (a topic so deep it deserves its own upcoming post), the price gap between proprietary API calls and self-hosted models is hitting CFO radar screens hard. C-suites are being forced to stop throwing raw compute at every problem and start asking what the job actually requires.

Match the model to the job. Most of the time, the job is much smaller than you think.

1. #FireInfantino

2. This was the first release of Fable on June 9 https://www.anthropic.com/news/claude-fable-5-mythos-5