This is a private collaboration: a toolkit that pulls odds across a range of major U.S. sportsbooks, treats the line at a sharp reference book as the closest thing to a true price, and works backward from there to two kinds of opportunities — a book quoting worse odds than the sharp line implies (+EV), and two books disagreeing enough with each other to lock in a riskless spread (arbitrage). Every price it flags gets sized through the Kelly criterion rather than a flat stake, so position size scales with the actual edge instead of a gut-feel bet.
De-vig, then compare
A raw sportsbook line isn’t a probability — it has the book’s margin baked into both sides of the market. The core of the toolkit is a de-vig step that strips that margin out of the sharp book’s line first, so what’s left is treated as the fair price everything else gets compared against. Every other book’s line is then measured against that fair price, not a hunch. The scanner is designed to follow whatever is in season — soccer, tennis, baseball, basketball, hockey — gets pulled through the same pipeline, with an eye toward extending the same de-vig-and-compare logic to broader prediction markets over time.
The automation layer
Built on top of the scan-and-flag core: a scheduled dispatcher that detects which sports are actually in season, tracks lines from the pre-game window through closing, and runs a nightly auto-settlement pass against final scores instead of settling positions by hand. Every scan gets archived to a local database so past opportunities are queryable rather than lost the moment a line moves, and a companion importer backfills that archive from historical records. Every API key touching the system is redacted before anything reaches a log line.
What it deliberately doesn’t do
There’s a Discord alerting integration wired in — the toolkit can push a formatted alert the moment it flags a +EV or arbitrage opportunity — but it ships dry-run: alerts render and get logged, nothing sends. Placing a bet automatically was never built, and that’s the actual design decision. Everything past “here’s an opportunity, here’s the size the math says to bet” stays a human action. The engineering story is the tested automation around that boundary, rather than a claim that a script beats sportsbooks.
Why
The interest is the statistics — finding a real, quantifiable edge in slightly mispriced markets — and then the separate, equally interesting problem of building reliable automation around a domain I care about: scheduling, archival, redaction, alerting, tests, all the unglamorous infrastructure that turns a one-off script into something that runs unattended without leaking a key or silently breaking when a season starts.