DEV Community: Elio Liberatore

Playoff Probability Calibration — LLMs vs. a Real Monte Carlo Model

Elio Liberatore — Sat, 26 Sep 2026 19:33:53 +0000

Submission for the DEV Community x Kaggle Benchmarking Challenge (#kagglechallenge)

The question

Large language models are increasingly asked to reason about probability — "what's the chance this team makes the playoffs?" is a perfectly natural thing to ask one. But do they actually reason about it, or do they just echo whatever number is floating around in the sports media they were trained on?

I already run a small sports-data business built on real Monte Carlo simulations (10,000-20,000 trials per team, cross-checked live against Kalshi prediction-market prices) for MLB and NFL playoff odds. That gave me a genuine, independently-verified ground truth to grade LLMs against — instead of grading them against each other, or against vibes.

So I built a two-task Kaggle Benchmark, "Playoff Probability Calibration: LLM vs Model", comparing 7 frontier and mid-tier models against my own simulation engine across 18 real MLB and NFL cases (5 MLB + 13 NFL).

The two tasks

Task A — Probability calibration (pure reasoning). The model gets the same plain-English context a bettor would have — team, record, games remaining, season point/run differential, a short narrative — and has to respond with a single number: its estimated playoff probability. No market price, no hints. Scored against my Monte Carlo model's own probability for that same team.

Task B — Monte Carlo code generation (agentic). No opinions allowed here. The model has to write a Python program that simulates the team's remaining games and prints a probability — and we actually execute what it writes. This isolates coding/agentic ability from sports "intuition": a model can't talk its way to a good score, it has to produce working simulation code that lands near the truth.

Both tasks share the same 18-case dataset (benchmark_dataset.csv), and 5 of those MLB cases resolve for real before the benchmark's own deadline — including a live Texas Rangers vs. Houston Astros game.

Models tested

Claude Opus 4.8, Claude Haiku 4.5, GPT-5.5, GPT-5.4 mini, Gemini 3.8 Flash, Gemini 3.7 Flash, and Qwen 3 Next 80B Instruct.

Results

(Mean score across all 18 cases, higher is better, 0-100%. See the live Kaggle benchmark for the underlying per-case breakdown.)

Model	Task A — Calibration	Task B — Code-gen
GPT-5.4 mini	98.0%	99.6%
Gemini 3.7 Flash	97.3%	99.7%
Gemini 3.8 Flash	97.1%	99.7%
Claude Haiku 4.5	95.4%	99.6%
Qwen 3 Next 80B Instruct	see note below	see note below
GPT-5.5	see note below	see note below
Claude Opus 4.8	see note below	see note below

A note on the missing three. Claude Opus 4.8, GPT-5.5, and Qwen 3 Next 80B Instruct could not complete either task on Kaggle's benchmarking infrastructure — every call to them failed before it was even billed, with a 403 PermissionDeniedError: "The max estimated cost of operation exceeds your available quota (based on max_output_tokens)." I confirmed this is not simple quota exhaustion (it reproduces with most of the daily allowance still free) and not concurrency contention (it reproduces running a single model completely alone). There's no exposed way — in the task code, the model-selection UI, or the notebook itself — to lower the max_output_tokens reservation these three models apparently require. I'm treating this as a hard platform-side limitation rather than a finding about the models themselves, and reporting the results here with the four models that could actually run.

What actually stood out

Every model that could run scored strikingly well — all four sit above 95% on both tasks, and the smaller/cheaper models (GPT-5.4 mini, the Gemini Flash pair) held their own right alongside the larger Claude Haiku 4.5. The bigger separation isn't between models — it's between the two tasks: Task B (write-and-execute code) scores even higher and tighter across the board than Task A (state an opinion), which suggests these models are more reliable translating "simulate this" into working code than they are at directly reasoning their way to a well-calibrated number. That's a more interesting result than "model X beats model Y" — it says something about how to prompt a model for a probability estimate at all: ask it to write the simulation, don't ask it to guess.

Live-resolving case: Texas Rangers vs. Houston Astros

One of the 18 cases in the dataset is a real, still-upcoming MLB matchup — Texas Rangers vs. Houston Astros, around September 28, 2026. I'll update this section once the game resolves, with how each model's estimate compared to both the simulation and the actual outcome.

Methodology notes

Ground truth: two of my own Apify-published Monte Carlo actors (commodus67/mlb-playoff-odds-monte-carlo, commodus67/nfl-playoff-odds-api-monte-carlo-simulator), each independently checked against live Kalshi prediction-market prices before being used as the benchmark's target.
Built entirely on Kaggle's Benchmarks SDK (kbench) — two @kbench.task-decorated aggregate functions, one per task, each running the full 18-row dataset against whichever model Kaggle passes in.
Every model got the same context, the same instructions, and the same scoring function — no reasoning traces or chain-of-thought hints, no tools beyond Python code execution for Task B.

Try it yourself

The benchmark is set up to evaluate any additional model Kaggle supports — just point "Evaluate More Models" at either task. I'd be curious whether a model with more headroom on Kaggle's token-cost reservation (once I sort that out) closes the gap on the top four, or whether ~97-99% is close to a ceiling for this kind of task.

Projecting a tennis match while it's still being played, without point-by-point data

Elio Liberatore — Thu, 24 Sep 2026 15:41:49 +0000

The problem: ESPN gives you a score, not a probability

Public tennis data is thin compared to what's available for team sports. ESPN's tennis API returns the score of every ATP/WTA match, live or finished — sets won, current game, current point when it bothers to update — but nothing that looks like win probability, and no point-by-point log you could replay.

That's a problem if you want to answer the question a live match actually raises: given the score right now, who wins? A pre-match number computed from rankings goes stale the moment the first point is played. You need something that reacts to the score without needing data ESPN simply doesn't expose.

Start with a number you can actually get: ranking points

Before a ball is hit, the only signal worth trusting is each player's current ATP or WTA ranking points — public, updated weekly, and already a decent proxy for recent form. A Bradley-Terry model turns the ratio of two players' points into a pre-match win probability:

p = pointsA^k / (pointsA^k + pointsB^k)

k controls how much a ranking gap matters; k = 1 (plain ratio) turned out to minimize error against live Kalshi prices when I backtested it against five liquid ATP markets. A second parameter blends that raw probability toward a coin flip, because ranking points alone say nothing about surface, current form or head-to-head — the kind of thing a market prices in and a Bradley-Terry model on points cannot see.

That gets you a solid pre-match number. It does not get you a live one.

Turning a match probability into a set probability, backwards

Here's the trick: a Grand Slam player up two sets to love is not simply "60% to win the match" scaled up. What actually changes when a set is won is the number of sets still needed, not some vague match-level confidence score. So the real quantity to simulate isn't "the match" — it's "the sets that are left."

That means I need a per-set win probability, not a per-match one. And I only have the match one.

The fix is to invert it. For a best-of-three match, the probability of winning the match given a per-set probability q has a closed form:

P(match | q) = q² + 2·q²·(1 − q)

(win in two sets, or win the decider after splitting the first two.) I already know P(match) from the Bradley-Terry step — call it p. So I solve for q such that P(match | q) = p, by bisection: pick a q in [0, 1], compute P(match | q), and narrow the interval until it converges on p. A dozen iterations gets you machine precision; there's no need for anything fancier.

function invertSetProbability(matchProb, matchFn, lo = 0, hi = 1) {
  for (let i = 0; i < 40; i++) {
    const mid = (lo + hi) / 2;
    if (matchFn(mid) < matchProb) lo = mid; else hi = mid;
  }
  return (lo + hi) / 2;
}

Best-of-five gets the same treatment with its own (longer) closed form. Now I have a per-set probability that, run back through the formula, reproduces the pre-match number exactly — which means it's the right one to carry into the live simulation.

From set probability to a live score

Once a match is actually in progress, the question becomes simple: from the current score — sets won by each player — how many more sets does each need, and what's the chance of winning that many more out of what's left, at probability q per set? That's just a binomial tail, and I compute it with a quick Monte Carlo simulation (thousands of trials of "flip the coin at probability q until someone reaches the target") rather than deriving a closed form for every possible remaining-sets combination — simpler to write, and cheap enough to run per match.

The result: a player already up one set shows a higher live probability than their pre-match number, without ever touching point-by-point data ESPN doesn't provide. The signal is coarse — set-level, not point-level — but it's honest about what it does and doesn't know, and it's free.

The format detail that almost broke best-of-five

One wrinkle: ESPN's own periods field, which should say whether a match is best-of-three or best-of-five, is unreliable — it reported 5 even for an ATP 250 event that's best-of-three. Trusting it would have inverted the wrong formula for most matches. The fix was to ignore it and detect the format from the tournament name instead: best-of-five only for the four ATP Grand Slams, best-of-three everywhere else — including the WTA majors, which are best-of-three regardless of prestige. A field that lies less than 50% of the time is worse than no field at all, because it's confident about being wrong.

A production crash that unit tests didn't catch

The model and the live projection both checked out against static fixtures — 29 passing tests. The first real end-to-end run against live ESPN and Kalshi data crashed 55 matches in, with a schema validation error on an undefined player name.

The cause: ESPN's tennis scoreboard mixes doubles draws into the same feed as singles, undifferentiated by any simple flag. In a doubles match, each side is a team/roster object, not an athlete — so the code path that reads athlete.displayName returned undefined for every doubles competitor, and JSON.stringify silently drops undefined values, which then failed a required field check downstream. Unlike ESPN's own explicit "TBD" placeholder for a genuinely unresolved future-round singles match, this wasn't a "no data yet" case — it was a shape mismatch that looked like missing data until you traced it back.

The fix was two-fold: skip doubles groups (checked by both the group label and the shape of the competitor side, since either can be wrong on its own), and make sure the name-reading function always returns a string, falling back to "TBD" only for a genuinely absent name. Two regression tests were added reproducing the exact draw shape that crashed. Static fixtures had been drawn from a single real match capture; the actual scoreboard on a random Tuesday has draws unit tests never saw. Rankings and prediction markets are singles-only anyway, so doubles rows were never wanted in the output — but "not wanted" and "safe to silently produce broken JSON for" are different bugs, and only one of them showed up until a real run hit it.

What this adds up to

Nothing here needs anything ESPN doesn't already give away for free: rankings, a live score, set counts. The engineering is in turning a static pre-match number into something that reacts to a live score without inventing data that isn't there — bisection to get from "match probability" to "set probability," a small Monte Carlo to get from "set probability" back to "match probability, live" — and in not trusting a field just because it exists.

The model behind this is the Tennis Match Winner Monte Carlo Actor — live and upcoming ATP/WTA singles matches, priced against Kalshi's KXATPMATCH/KXWTAMATCH prediction markets.

NFL playoff odds after Week 1 (2026): why my Monte Carlo model barely trusts a 31-10 win

Elio Liberatore — Tue, 15 Sep 2026 23:10:28 +0000

Week 1 of the 2026 NFL season is done. Sixteen teams are 1-0, sixteen are 0-1, and every sports show is already telling you who is "for real."

I build a Monte Carlo simulator that estimates NFL playoff odds for all 32 teams, so I wanted to know how much one week should move those numbers. The model's answer is "not much," and the reasons are more interesting than the numbers themselves.

The problem with one game of data

A common way to estimate team strength is the Pythagorean expectation. You take points scored and points allowed and turn them into an expected win percentage. Across a full season it predicts future wins better than the win-loss record does.

After one game it gives you nonsense. Here is what it says after Week 1, next to what my model actually uses:

Team	Week 1	Point diff	Pythagorean (1 game)	Model's strength estimate	Playoff odds
Jacksonville Jaguars	W 34-10	+24	.948	.679	92.6%
Kansas City Chiefs	W 31-10	+21	.936	.559	69.1%
New York Jets	W 23-10	+13	.878	.411	23.6%
Las Vegas Raiders	W 27-13	+14	.850	.399	21.4%
New England Patriots	L 10-13	-3	.349	.597	55.8%
Denver Broncos	L 10-31	-21	.064	.542	39.9%
Los Angeles Rams	L 7-27	-20	.039	.544	33.3%

Model run on September 15, 2026, after Week 1, with 20,000 simulated seasons. These numbers will change after Week 2.

Two things stand out:

Winning big barely helps if you weren't good before. The Jets and Raiders both won by double digits and are still below 25%.
Losing big barely hurts if you were. The Patriots lost their opener and still have better playoff odds than the 1-0 Giants (39.9%). The Broncos lost by 21 and are still near 40%.

That's by design. Here is how it works.

Step 1: shrink the current season hard

The simulator estimates each team's true strength by blending three things:

The actual win percentage
The Pythagorean expectation from point differential (weighted at 0.65 by default, because point differential is the better predictor)
A baseline the estimate is pulled toward

The pull is controlled by regressionGames. Think of it as adding a number of imaginary games played at the baseline. The NFL default is 6.

After Week 1, each team has one real game against six imaginary ones. So the current season is only about a seventh of the estimate. That's why a .936 Pythagorean number turns into something much closer to average.

Six is much smaller than you'd use in baseball. A 17-game season means every game carries real information, and by midseason I want the real record to dominate. It just shouldn't dominate after one Sunday.

Step 2: don't regress everyone to .500

If every team were pulled toward .500, all 32 would start the season with identical odds. That's useless, and it's obviously wrong.

So the baseline comes from last season. The model takes last year's point differential, shrinks it toward .500 and uses that as each team's starting point. The priorCarryover parameter sets how much survives. The default of 0.6 keeps 60% of last season's separation between teams.

That's why Jacksonville's strength estimate is .679 even though most of the weight is still on the prior. It's also why a 21-point loss doesn't sink Denver.

It also leads to this model's biggest weakness, and I'd rather say it upfront: it knows nothing about the offseason. It doesn't know about a new quarterback, a new head coach or a key injury. The prior comes only from last season's scoreboard. Early in the season that's the main way the model can be wrong. The regression settings are there so real results take over quickly as the weeks pass.

Step 3: simulate the season 20,000 times

With a strength estimate for each team, the simulator plays out every remaining game on the real schedule:

Strength uncertainty. Each simulated season redraws every team's strength from a distribution (strengthUncertainty, default 0.16). With a 17-game sample you can't be sure how good anyone is. If you set this to zero, the output becomes far too confident.
Game results. A logistic model decides each game from the strength gap. Home teams get +0.2 in log-odds, which works out to about a 55% win rate between evenly matched teams.
Ties. Each game has a 0.4% chance of ending in a tie, roughly one per season across 272 games. As in the NFL, a tie counts as half a win.
Seeding. Each simulated season is run through the NFL seeding rules: division winners, three wild cards per conference, and the No. 1 seed.

After 20,000 seasons, the playoff odds are just how often each team made it. The same run returns division odds, wild-card odds, No. 1 seed odds and a projected final record. For example, the Chiefs project to about 9.7 wins right now and the Jaguars to about 11.8.

Running it yourself

The simulator is published as an API on Apify: NFL Playoff Odds API - Monte Carlo Simulator. Standings and the remaining schedule are loaded automatically. Every parameter above is an input, so you can test your own assumptions.

curl -X POST \
  "https://api.apify.com/v2/acts/commodus67~nfl-playoff-odds-api-monte-carlo-simulator/run-sync-get-dataset-items?token=YOUR_APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "iterations": 20000,
    "regressionGames": 6,
    "pythagoreanWeight": 0.65,
    "priorCarryover": 0.6,
    "strengthUncertainty": 0.16,
    "homeFieldAdvantage": 0.2
  }'

You get one row per team. Some settings worth playing with:

priorCarryover: 0 starts every team level and shows how little one week tells you on its own.
regressionGames lower means you trust the 2026 results more, higher means you trust them less.
season runs a past season from where it stood, which is useful for backtesting.
archiveToNamedDataset saves every run to a named dataset. Run it weekly and you get a history of how the odds moved, which you can't rebuild later.

You can also pass your own market probabilities in marketProbabilities, and the output will show where the model and the market disagree.

What to watch next

Week 4 is the next checkpoint worth looking at. By then a team has played four real games against six imaginary ones, and the current season starts to matter. If the model is still far from reality for a team that changed a lot in the offseason, that's a sign priorCarryover should be lower in September.

This is a statistical model, not a set of picks. Its job is to put a number on uncertainty, not to tell you who to back.

If you like this kind of thing, I wrote about the same problem for hockey: NHL playoff odds for 2026-27 and why I don't trust my own model in September.

Shipping a statistical model to the browser: Dixon–Coles soccer predictions with no backend and no API key

Elio Liberatore — Tue, 15 Sep 2026 15:50:06 +0000

I wanted a public page where anyone could click a soccer match and see real probabilities behind it — 1X2, Over/Under, both teams to score, exact scorelines. The model already existed: a Dixon–Coles bivariate Poisson fitted on finished matches. The hard part was never the statistics. It was getting the thing onto a page that costs me nothing and exposes nothing.

Here's what I ended up with, and why the obvious approaches don't work.

Three options that all fail

Call the API from the browser. Simplest to write, and it puts my API token in everyone's DevTools. Dead on arrival.

Put a proxy in front of it. Now I'm running a server, and every visitor — including every bot — costs me a model run. A page that gets popular becomes a page that bills me for being popular. That's a bad shape for a free demo.

Pre-render everything to static HTML. Cheap and safe, but the whole point is interaction. I want you to flip the Over/Under line from 2.5 to 3.5 and see the number move. Pre-rendering every market for every line for every match is a combinatorial mess, and it's a lot of bytes to ship.

All three fail for the same reason: they treat the model's output as the thing to deliver.

The parameters are smaller than the answers

A Dixon–Coles model, once fitted, is almost nothing. Per match, it's two expected goal rates — λ for the home side, λ for the away side. Per league, it's one low-score correlation parameter, ρ. That's it. Every market on the page is arithmetic over those three numbers.

So don't ship the answers. Ship λh, λa, ρ, and let the browser do the arithmetic.

The payload looks like this:

{
  "generatedAt": "2026-09-15T15:06:00Z",
  "model": "Dixon-Coles bivariate Poisson, MLE-fitted attack/defence with exponential time decay (xi=0.0018), maxGoals=10",
  "leagues": [
    {
      "slug": "eng.1",
      "name": "Premier League",
      "rho": -0.115723,
      "historyMatches": 1141,
      "matches": [
        { "k": "2026-09-18T19:00:00.000Z", "h": "Brentford", "a": "Chelsea",
          "lh": 1.670193, "la": 1.560041, "q": 0 }
      ]
    }
  ]
}

Six keys per match, one of which (q) is just a data-quality flag. A dozen leagues and a couple hundred upcoming fixtures fit in about 23 KB of JSON, inlined in the page. The whole document — markup, styles, logic, data — is around 54 KB. No fetch, no second request, no loading state.

The recompute is twenty lines

Dixon–Coles is independent Poisson with a correction applied to the four low-scoring cells — 0–0, 0–1, 1–0, 1–1 — where real football deviates from independence. The correction is the τ function, and ρ is its single parameter:

function grid(lh, la, rho) {
  var g = [], s = 0, x, y, p, tau;
  for (x = 0; x <= MAXG; x++) {
    g[x] = [];
    for (y = 0; y <= MAXG; y++) {
      p = pois(x, lh) * pois(y, la);
      if      (x === 0 && y === 0) tau = 1 - lh * la * rho;
      else if (x === 0 && y === 1) tau = 1 + lh * rho;
      else if (x === 1 && y === 0) tau = 1 + la * rho;
      else if (x === 1 && y === 1) tau = 1 - rho;
      else                         tau = 1;
      g[x][y] = p * tau;
      s += g[x][y];
    }
  }
  for (x = 0; x <= MAXG; x++)
    for (y = 0; y <= MAXG; y++) g[x][y] /= s;
  return g;
}

An 11×11 grid of scorelines, renormalised so it sums to 1. Every market is then a sum over cells of that one grid:

function markets(g, line) {
  var p1 = 0, px = 0, p2 = 0, ov = 0, bt = 0, x, y, v;
  for (x = 0; x <= MAXG; x++)
    for (y = 0; y <= MAXG; y++) {
      v = g[x][y];
      if      (x > y)   p1 += v;
      else if (x === y) px += v;
      else              p2 += v;
      if (x + y > line) ov += v;
      if (x > 0 && y > 0) bt += v;
    }
  return { p1: p1, px: px, p2: p2, ov: ov, un: 1 - ov, bt: bt, nb: 1 - bt };
}

This is the part I like most, and it's not a performance argument. Because every market comes out of the same grid, the page is internally consistent by construction. The 1X2 probabilities, the Over/Under for every line, both-teams-to-score, and the top scorelines can't contradict each other, because they're five different sums over one object. If you've ever assembled a page like this from separate endpoints, you know how easy it is to publish a "draw" probability that disagrees with the sum of the 0–0, 1–1 and 2–2 cells sitting right next to it.

Flipping the Over/Under line from 2.5 to 4.5 doesn't fetch anything. It changes one comparison in a loop over 121 cells.

Check your reimplementation. I ran the browser's grid against the scoreline grid the model itself returns, match by match. Largest disagreement: about 2e-7 — floating-point noise. Do this before you trust a client-side reimplementation of anything; "looks about right" is how you ship a subtly wrong model.

Keeping it fresh without a server

A build script calls the model once per league, writes the parameters into the page template, and commits the result. GitHub Actions runs it on a cron; Pages serves it. Hosting cost is zero, per-visitor cost is zero, and the only recurring cost is one model run per league per day.

Three things I got wrong first, so you don't have to:

The template lives inside the build script. I edited the published HTML directly to fix something, felt good about it, and the next morning's run overwrote my fix. If a generator owns a file, the file is not the source. Obvious in hindsight; still cost me an afternoon.

Fail loudly, publish conservatively. If one league returns no fixtures, the script skips it. If every league comes back empty, it exits non-zero and publishes nothing — so a bad upstream day leaves yesterday's good numbers up instead of replacing them with a blank page. The failure mode you want is stale, not empty.

Scheduled doesn't mean punctual. My cron says 11:30 UTC. Actual runs have landed three and a half and five and a half hours late. GitHub's scheduled workflows queue on shared capacity and there is no guarantee attached to that timestamp. If your copy says "updated every morning", your copy is wrong. Put the generation timestamp on the page and let it speak for itself.

Say when the model is thin

Early in a European season, a promoted side has three or four matches of top-flight history. The fit still returns a number, and the number is confidently silly.

So the payload carries a per-match quality flag, and the page renders a LOW DATA badge plus a plain-language card explaining that one of these teams has very little history behind its rate. It costs one flag per match in the payload and it's the difference between a page that reports numbers and a page that reports numbers honestly.

Every model has a region where it shouldn't be trusted. Most interfaces hide it. Showing it costs almost nothing and is the single change most likely to make a technical reader believe the rest of your output.

What it adds up to

Model parameters, not model answers, on the wire
~23 KB of JSON, one document, no runtime fetches
No credentials in the client, because the client never calls anything
Internally consistent markets, because they're sums over one grid
Static hosting; cost doesn't scale with traffic
Honest about staleness and about thin data

The technique generalises past football. Any fitted model whose parameters are small compared to its output surface can be shipped this way — pricing curves, survival models, anything where a handful of coefficients regenerate a large interactive result set. Ask what the smallest object is that lets the client rebuild the answer, and send that instead.

Page: commodus67.github.io/soccer-predictions-demo

Model behind it: soccer-dixon-coles-match-predictor

Simulation and data, not tips. Nothing here is betting advice.

NBA play-in odds are not playoff odds: simulating the play-in tournament instead of guessing it

Elio Liberatore — Thu, 10 Sep 2026 22:26:19 +0000

In baseball, American football and hockey, "make the playoffs" is one line: finish above it and you're in. When I built an NBA version of my playoff-odds simulator, I assumed the same, and my first plan was to compare the model against the wrong market.

Basketball has a band in the middle, and getting it right changes almost every number.

Three zones, not two

In each 15-team conference:

Finish	What it means
1st – 6th	Straight into the playoffs
7th – 10th	Into the play-in tournament, where two of four survive
11th – 15th	Season over

The play-in works like this. Seed 7 plays seed 8; the winner is the 7th seed. Seed 9 plays seed 10; the loser goes home. The loser of 7 v 8 then hosts the winner of 9 v 10, and that game decides the 8th seed.

Kalshi lists these as separate markets — one for playoff qualification across all 30 teams, and one play-in market per conference — and its contract rules settle the question in one sentence: "Qualifying for the play-in tournament doesn't constitute playoff qualification."

So the play-in market is not a weaker version of the playoff market. It's a band, and the two behave almost like opposites. A title contender is a near-certainty for the playoffs and a near-zero for the play-in. A 44-win team can be close to a coin flip between the two.

Simulate the games, don't approximate them

The tempting shortcut is to say "finish 7th or 8th, you're probably in; 9th or 10th, probably not". That breaks the moment you need two numbers that agree with each other: the chance of reaching the playoffs and the chance of landing in the play-in.

So in every simulated season the model:

Plays out the remaining regular-season schedule.
Seeds each conference.
Plays the three play-in games.
Runs the full bracket: four rounds of best-of-seven series with the 2-2-1-1-1 home-court pattern.

That produces, for every team and from the same simulated seasons: top-six probability, play-in probability, playoff probability, conference finals, conference title and championship. Sanity checks come for free — the championship column sums to 1 across the league and conference finals to 4.

Basketball-specific modelling choices

Pythagorean exponent. Points scored and allowed predict future results better than record alone, but the exponent depends on the sport. Baseball uses about 1.83, hockey 2.0; for basketball I use 13.91. Plugging a baseball exponent into NBA scoring wildly compresses the gap between good and bad teams.

Uncertainty about strength itself. My first version drew game outcomes from fixed team ratings. In September it confidently told me some teams made the playoffs 100% of the time and others 0%. That's not how the NBA works. Now each simulated season redraws every team's rating once (a 0.22 spread by default), so the output is a distribution rather than one confident guess. That alone cut the average gap against the market from 15.2 to 12.9 points and removed every 0% and 100%.

The two missing games. The 2026-27 regular season is 82 games, but ESPN's schedule currently lists 80 per team: the other two depend on the NBA Cup and are scheduled later. If you simply simulate the schedule you can see, every team's projected wins sit on an 80-game scale. I simulate the missing two against an average opponent on a neutral floor.

A September snapshot

From one run on 10 September 2026:

Team	Projected wins	Top six	Play-in	Playoffs	Title
Oklahoma City	55.3	97.0%	2.8%	99.1%	23.9%
San Antonio	52.1	91.6%	7.8%	97.0%	11.8%
Boston	51.6	88.2%	11.0%	95.9%	11.6%
Toronto	44.8	51.0%	41.0%	73.7%	2.2%
Atlanta	44.4	48.2%	42.4%	71.7%	1.8%
Miami	44.3	47.9%	42.6%	71.3%	1.8%

Look at Toronto, Atlanta and Miami: roughly a coin flip to avoid the play-in, and more than 40% to end up in it. For those teams, playoff odds and play-in odds are both "live" — exactly why they need separate columns.

The number I don't trust

Against Kalshi's playoff contracts that day, most of the table lines up within a few points: Oklahoma City 99.1% in the model against 98% on the market, Miami 71.3% against 72.5%, Toronto 73.7% against 70.5%.

Then there's Charlotte: 86.5% in the model, 36% on the market. A fifty-point gap.

That is not an opportunity. Before opening night, the model knows only how last season ended, regressed towards average. It hasn't seen free agency, the draft, trades or injuries. The market has. When I first measured the model against Kalshi in September, the rank correlation was about 0.80 and the average gap about 13 points — and the largest gaps were teams whose whole case this year is the offseason.

So the simulator refuses to call anything "value" until every team has played ten games. It still reports every gap, labelled WATCH. A model that disagrees with the market by fifty points in September is telling you what it can't see, not what the market got wrong.

One market-side detail worth copying

Playoff qualification is sixteen independent yes/no contracts, so prices across the league add up to about 16, not 1. Never normalise that field to 1. And price both sides of each contract: if the model says 60% and YES trades at 75 cents, the signal is on the NO side, not "no signal".

Try it

The simulator is published as an Apify Actor: NBA Playoff Odds API — Monte Carlo Simulator & Value Bets. Standings and schedules come from ESPN and prices from Kalshi's public API, with no keys needed. Ready-made examples include play-in tournament odds by conference, championship odds from a simulated bracket, projected win totals and tracking playoff odds all season.

The season starts on 20 October. Simulation and data, not tips.

NHL playoff odds for 2026-27: 84 games, the wild card rule, and why I don't trust my own model in September

Elio Liberatore — Thu, 10 Sep 2026 22:26:00 +0000

I build Monte Carlo simulators that turn standings and schedules into playoff probabilities. After baseball, American football and soccer, I assumed hockey would be a copy-paste job with new team names.

It wasn't. Four things about the NHL break a generic season simulator, and one of them changed this summer. Here they are, followed by the part I find most interesting: what the model says a few weeks before opening night, and why most of its disagreements with the market should be ignored.

1. Standings run on points, not wins

A win is two points. An overtime or shootout loss is still worth one. Roughly 23% of NHL games go past regulation, so ranking simulated teams by wins misprices every club that lives in one-goal games.

In the simulator each game has three outcomes — regulation win, overtime or shootout win, and the mirror images — and points are awarded the way the league awards them.

There is a trap on the strength side too. Points percentage averages about .557 across the league because of the loser point, while win/loss averages exactly .500 because every game has a winner. If you estimate team strength from points percentage, every team looks slightly better than average. I estimate it from wins over games played, and from goals for and against with a Pythagorean exponent of 2.0.

2. The playoff field is not "the top eight"

Sixteen of 32 teams qualify, but not by conference rank. In each conference the top three of each division get in, and then the two best remaining teams take the wild cards regardless of division. A fourth-place team in a strong division and a third-place team in a weak one are not interchangeable.

That rule has to run inside every simulated season. It also gives you a free sanity check: across all 32 teams, playoff probabilities must sum to exactly 16. If yours sum to 15.7, something is wrong.

3. Overtime is closer to a coin flip

Three-on-three and the shootout are not sixty minutes of five-on-five hockey. A better team carries less of its edge into the extra period. I damp the strength gap by half in overtime (overtimeDamping = 0.5). Setting it to 0 makes overtime a pure coin flip; 1 treats it like regulation.

4. The season is 84 games now

The collective bargaining agreement signed in 2025 moved the NHL to 84 regular-season games from 2026-27. ESPN's event count per team shows 84 for this season and 82 for last. I never hardcoded the season length — the simulator counts the games on the schedule feed — so projected point totals landed on the right scale without a code change. If you maintain a model with 82 somewhere in it, now is the time to look.

One more data quirk: ESPN names a season by the year it ends, so 2026-27 is season=2027, and before opening night the 2027 standings tree exists but has zero teams in it. You need to fall back to the previous season for the list of clubs and divisions.

What the model says right now

Here is part of a 20,000-season run from 10 September 2026, next to the live price of Kalshi's "make the playoffs" contract for each team:

Team	Projected points	Model playoff %	Kalshi	Gap
Colorado	109.6	96.5%	91%	+5.5
Carolina	103.5	82.9%	89.5%	−6.6
Buffalo	101.6	76.3%	56%	+20.3
Edmonton	95.7	68.3%	85%	−16.7
Vegas	95.2	66.4%	85.5%	−19.1
Boston	97.0	58.3%	31%	+27.3
Pittsburgh	95.5	52.5%	29.5%	+23.0
San Jose	89.7	42.3%	67.5%	−25.2

Boston 27 points above the market. San Jose 25 below. If you believed the model, those would be the trades of the year.

Why I don't believe it (yet)

In September the model knows exactly one thing about each club: how last season ended, shrunk 40% towards average. It hasn't seen a trade, a signing, an injury, a goalie change or a new coach. The market has seen all of them.

So the biggest gaps in September are not edges. They are the offseason. Betting them is betting that the summer didn't happen.

When I first compared the model with Kalshi across all 32 teams, the rank correlation was 0.65 and the average gap was about 14 points, and the largest disagreements were precisely the teams whose summers changed the most. That is what a season-carryover model should look like before the puck drops.

Instead of hiding that, I made it a rule in the output. Until every team has played a minimum number of games (10 by default), no row is allowed to call itself value. Every gap is still reported in full, but it's labelled WATCH. After that, the current season's record takes over from last season's gradually, rather than overnight after a hot week.

The fee changes which gaps matter

Kalshi's taker fee is 0.07 × p × (1 − p) per contract. It peaks in the middle: 1.75 cents on a 50-cent contract, 0.63 cents on a 90-cent one. So a 1.5-point edge on a coin-flip contract is a losing position after fees, while the same gap on a heavy favourite isn't. Any comparison that ignores this will rank the wrong teams first.

A second trap: the playoff market is sixteen independent yes/no contracts, so prices across the league add up to about 16, not 1. If you "de-vig" it the way you would a division-winner market, you divide every probability by sixteen and manufacture huge fake edges everywhere. Division winners, on the other hand, are exclusive — exactly one team wins — and there you do strip the overround.

Watching it move

The part I'm looking forward to is not the September table. It is the path. Each run can append its 32 rows to a named dataset that keeps growing, so a daily schedule gives you, by spring, how each team's probability moved across the season next to what the market charged for it on the same day — something you can't reconstruct afterwards.

Try it

The simulator is published as an Apify Actor: NHL Playoff Odds API — Monte Carlo Simulator & Value Bets. No API keys for the data; standings and schedules come from ESPN, prices from Kalshi's public API. There are ready-made examples for projected points standings, wild card odds, Presidents' Trophy odds and tracking playoff odds all season.

Simulation and data, not tips.

Correct score, BTTS and Over/Under probabilities with Dixon-Coles: what I learned building it for MLS and Liga MX

Elio Liberatore — Thu, 10 Sep 2026 22:25:35 +0000

Most football prediction pages give you three numbers — home, draw, away — and no way to check where they came from. I wanted the opposite: one model, fitted on real results, that produces the 1X2 probabilities, the Over/Under 2.5 line, Both Teams To Score and the exact-score grid, all from the same place, so they can't contradict each other.

The model I ended up with is Dixon-Coles. This post is what it does, why it beats the simpler version most tutorials start with, and what came out when I ran it on eight leagues that don't get much attention from modellers: MLS, Liga MX, Liga de Expansión MX, the Brasileirão Série B, the USL Championship, Colombia's Primera A, Uruguay's Primera División and Norway's Eliteserien.

The starting point: independent Poisson

The classic approach gives every team an attack rating and a defence rating, adds a home advantage, and turns them into expected goals for each side of a fixture — call them λ for the home team and μ for the away team. Goals are then treated as two independent Poisson variables. The probability of a 2-1 is just P(home scores 2) × P(away scores 1).

It works surprisingly well. It also has one known blind spot: low scores. Real matches finish 0-0 and 1-1 more often than two independent Poisson draws predict, and 1-0 / 0-1 slightly less often. Anything that depends on those four cells — the draw, Under 2.5, BTTS "No" — inherits the error.

The Dixon-Coles correction

In 1997 Mark Dixon and Stuart Coles proposed a small fix. Keep the Poisson grid, but multiply the four low-score cells by a factor that depends on one extra parameter, ρ (rho):

Score	Adjustment
0-0	1 − λμρ
0-1	1 + λρ
1-0	1 + μρ
1-1	1 − ρ
anything else	1

With a negative ρ, 0-0 and 1-1 go up and 1-0 / 0-1 go down — exactly the direction the data pulls.

To see how much that matters, take a match with 1.35 expected goals for the home side and 1.15 for the away side, and an illustrative ρ of −0.13:

	Independent Poisson	Dixon-Coles
Draw	26.8%	30.2%
0-0	8.2%	9.9%
1-1	12.7%	14.4%
Home win	41.3%	39.7%
Away win	31.8%	30.2%

Same expected goals, three and a half points more on the draw. If you compare model probabilities with prices, that is the difference between seeing an edge and not seeing one.

Two things the paper adds that tutorials often skip

Time decay. A result from three seasons ago should not count as much as last weekend's. Dixon and Coles weight each match by exp(−ξ·t), where t is its age in days. I use ξ = 0.0018, which halves a result's weight after roughly a year, and fit on three seasons of history.

Fit ρ from the league itself. ρ is not a universal constant. After fitting attack, defence, home advantage and the baseline by weighted maximum likelihood, I fit ρ separately for each league. They come out different. On 6 September, Colombia's Primera A gave a home advantage of 0.349 (on the log scale) and ρ = −0.044; Norway's Eliteserien gave 0.276 and ρ = −0.015. Colombian home sides get a bigger boost, and the low-score correction matters less in Norway.

Where the data comes from

All eight leagues come from ESPN's public scoreboard endpoint:

https://site.api.espn.com/apis/site/v2/sports/soccer/<league>/scoreboard?dates=YYYYMMDD-YYYYMMDD

Two things cost me time and might save you some:

Ask for a date range, not a single day. With dates= set to one day, a smaller league often returns nothing simply because it didn't play that day, which looks exactly like missing data. A week-long range removes the ambiguity.
Filter by state, not by status name. Finished matches carry status.type.state === "post" and completed: true; scheduled ones are "pre". That is more robust than matching STATUS_FULL_TIME.

Slugs are not always what you'd guess. The USL Championship is usa.usl.1, not usa.2.

History depth is not the bottleneck. The Premier League scoreboard answers back to at least 2002-03, and MLS and Liga MX back to at least 2004-05. Three seasons is plenty.

What one prediction looks like

Here is a real row from a test run on 6 September — Atlanta United at home to Orlando City in MLS:

Field	Value
λ home / λ away	1.57 / 1.63
ρ (MLS)	−0.040
Home / Draw / Away	36.5% / 24.2% / 39.2%
Over 2.5 goals	62.1%
Both teams to score	64.1%

And from Liga MX the same day, Pumas UNAM against León: λ 1.94 against 0.94, so 60.1% / 23.0% / 16.9%. A strong home side, and the numbers say so.

Every probability comes from one score grid (0-0 up to 10-10), normalised to 1, so 1X2 sums to 1, Over + Under sums to 1 and BTTS Yes + No sums to 1. I checked that on every row of a 28-match Série B run; the error was floating-point noise.

The awkward case: promoted teams

A team with no matches in the lookback window has no rating. The honest options are to guess or to say so. I start it at league-average strength and flag every fixture it plays with dataQuality: "partial-new-team", so whoever uses the numbers can decide how much to trust them until the team has a few games on the board.

What it doesn't do

It doesn't know about injuries, suspensions, rotation, weather or a manager who has just been sacked. It treats every match in the lookback window the same apart from its age. It is a baseline, not an oracle — which is exactly what makes it useful to compare against prices.

Try it without writing the model

I packaged all of this as an Apify Actor: Soccer Match Predictions API — 1X2, Over/Under & BTTS Odds. You pick a league, it returns one row per upcoming fixture with everything above. There are ready-made examples, such as MLS correct score probabilities and Liga MX match predictions, and the rest are listed on the examples page.

If you'd rather build it yourself, the table of adjustments above and the ESPN endpoint are all you need to get started. Either way: simulation and data, not tips.