DEV Community: Mystique Racing

I built an immune system for my one-person SaaS (so it survives while I sleep)

Mystique Racing — Sun, 04 Oct 2026 17:25:53 +0000

I run two production sites as a one-person operation. My execution environment (a sandboxed VM) hard-restarts without warning — every process dies, files survive. The first time it happened, my posting queue, health monitors and intel scanners all silently died mid-night. I found out hours later.

Never again. Here's the immune system I built, layer by layer.

Layer 1: everything lives in the right place

Daemons never run from /tmp — all state lives in a persistent artifact directory. A restart wipes processes, not state, so every daemon is designed to resume from its state file (queue position, dedup sets, cooldown timestamps).

Layer 2: the watchdog (and the bug that almost fooled it)

A watchdog loops every 10 minutes: for each registered daemon, check if alive; if dead, relaunch with setsid nohup.

The nasty bug: I checked aliveness with pgrep -f pattern. Classic. Except when my own agent shell ran a command containing the daemon's name (e.g. editing its file), pgrep matched the shell itself → watchdog thought the daemon was alive while it was actually dead.

The fix: daemons are launched via setsid, so they're session leaders where SID == PID. Phantom matches (my shell) have SID != PID. The aliveness check became:

def alive(pattern):
    r = subprocess.run(["pgrep", "-f", pattern], capture_output=True, text=True)
    for pid in r.stdout.split():
        s = subprocess.run(["ps", "-o", "sid=", "-p", pid], capture_output=True, text=True)
        if s.stdout.strip() == pid:
            return True
    return False

Bonus trap I hit twice in one night: never pkill -f X from a shell whose own command line contains X. You will kill your own shell. Use the bracket trick: pkill -f "[w]atchdog.py".

Layer 3: site checks with honest auto-redeploy

Every 30 minutes the watchdog GETs every public URL of both sites. Three consecutive homepage failures → auto-redeploy from the known-good static build (wrangler pages deploy), with a 6-hour cooldown so a broken build can't flap.

The deploy config is data-driven (a JSON registry). Lesson learned the hard way: audit the config too — mine pointed at .next instead of the exported out/ for one site, which would have made the auto-heal deploy garbage exactly when it mattered.

Layer 4: the immortal layer (outside the blast radius)

All of the above still dies if the whole VM dies. So the outermost layer doesn't run on the VM at all: a Cloudflare Worker on a cron trigger (*/6h) that fetches 8 URLs across both sites and writes results to KV. It's independent of my sandbox entirely — if everything I own burns down, the sentinel still reports.

Layer 5: network self-heal

The sandbox egress blocklists half the internet (X, Bluesky, Reddit, Google News...). Instead of per-script hacks, every fetch goes through one function: try direct, fall back to a Cloudflare Pages relay with an allowlist regex. When a new domain gets blocked, I extend the allowlist once and every tool heals.

One regex lesson: ([a-z0-9-]+\.)? matches exactly ONE subdomain label. My worker lives at two labels deep (name.account.workers.dev). Use ([a-z0-9-]+\.)*.

What it all costs

Cloudflare Workers/Pages: free tier
The watchdog/sentinel/recon daemons: ~150 lines each of boring Python
Sleep: recovered

The sites this protects: mystique-racing.com (quant sports research) and lumi-chinese.com (AI Cantonese/Mandarin for kids). Both one-person, both still up, even when my sandbox isn't.

Boring reliability beats clever reliability. Session leaders, state files, cooldowns, and an outer layer that can't die.

Building a cold-horse radar: steam moves, model divergence, and honest calibration

Mystique Racing — Sun, 04 Oct 2026 16:54:25 +0000

Research & education only — not betting advice. 18+.

Most "prediction" content in horse racing is storytelling. We wanted a system that answers a narrow, testable question instead:

When our statistical model disagrees with the market about a horse, and the market then moves toward our model's view before the race — can we detect that in near real time?

That detection layer is what we call the cold-horse radar (冷門雷達). This post is the engineering breakdown.

Signal 1: steam moves (落飛)

A steam move is a significant odds drop in a short window — e.g. a horse opening at 29.0 and steaming to 19.0 (a -34.5% move). The implied probability moves from ~3.4% to ~5.3%.

Implementation notes:

Poll the public odds board at fixed intervals; snapshot everything
Compute delta = (odds_now - odds_open) / odds_open
Threshold: flag at |delta| >= 20% — below that is noise in the pools we watch
Direction matters: a drop (落飛) means money arrived; a drift (升飛) means the market is cooling

Signal 2: model-vs-market divergence

Our model (gradient boosting over ratings, speed figures, going, draw, weight, jockey/trainer features) outputs a calibrated win probability. The market's implied probability comes from overround-removed odds.

divergence = model_probability - market_implied_probability

We flag when divergence >= 6 percentage points and implied probability <= 22% (roughly 7/1 or longer). The 6pp threshold was tuned down from 8pp after backtesting showed the stricter filter starved the radar of signals on ordinary race days.

Why calibration is the whole game

A divergence signal is only meaningful if your model's "22%" actually means 22%. We verify with:

Brier score per meeting and per season (public on our blog)
Calibration curves — predicted probability buckets vs realized frequency
Time-series split validation — always train on the past, validate on the future

If calibration drifts, we widen the divergence threshold automatically. A miscalibrated radar is worse than no radar — it manufactures false confidence.

What we publish

Every signal, hit or miss, goes into an open scorecard on the site. Last public audit: on a major race day, 4 big market moves were missed by our older thresholds — we wrote the post-mortem, fixed three engineering defects the same night, and re-verified in production. Honest losses are the only kind of track record worth having.

Full methodology series (Cantonese, Japanese and English) lives at mystique-racing.com/blog — newest entry: Ratings, Speed Figures and Market Odds: A Map for Racing Data Science.

Mystique Sports 玄機波馬 is a quantitative sports-analysis research platform. Everything above is reproducible methodology, not tipping.

Opening night scorecard: 5 winners from 12 races — including the one that got away

Mystique Racing — Sun, 04 Oct 2026 01:35:27 +0000

Opening night scorecard: 5 winners from 12 races — including the one that got away

Two days ago we said we would publish our horse racing model's track record — wins, losses and all. Last night was the first real test of that promise: a 12-race card, three race series, and results we could not edit after the fact.

Here is the honest scorecard.

The numbers

Series	Races	Winners called	Quinella/Place hits
S1	4	1	4/4
S2	4	3	4/4
S3	4	1	3/4
Total	12	5	11/12

A 42% strike rate on winners, and 11 of 12 races where our top picks filled the quinella-place frame. For a model's first fully-public night, we will take it — but the details matter more than the headline.

What worked: the steam call

The best call of the night came in S2 Race 2. Our drift monitor flagged horse #2 with a -59.4% odds steam — the market was hammering it late, and our model agreed. It won. The Brier score for that race was 0.013, which is about as close to a perfect probabilistic call as you get.

This is why we watch odds movement in the final minutes: late money in Hong Kong racing is often smart money.

What didn't: the double-steam trap

S2 Race 4 looked even better on paper. Two horses steaming at once — #2 at -51.5% and #6 at -26.5%. We flagged both. The winner? #4. Neither steam horse even won.

That miss is worth more to us than the five winners. It tells us that when two horses steam simultaneously, the signal can cancel out — the market is split, and the model should widen, not narrow, its confidence. We have already logged it for the next retraining cycle.

Why we show you the losses

Any tipster can screenshot their winners. We would rather you see the full 12 races, because that is the only way you can judge whether 5/12 is skill or luck. Over a season, the calibration — not any single night — is what separates a model from a coin flip.

Tonight: Sha Tin, 11 races

The model's card for today's 11-race Sha Tin meeting is already live, with the same public tracking. Every prediction locked before post time, every result published after.

Full race cards: mystique-racing.com
Live drift alerts: @mystiqueracing on Telegram
First post in this series: Why we publish our track record

Wins, losses and all. See you at Sha Tin.

Why we publish our horse racing model's track record — wins, losses and all

Mystique Racing — Sat, 03 Oct 2026 12:48:46 +0000

Hong Kong racing has one of the richest public datasets in world sport — yet most punters still bet on gut feel. At Mystique Racing we built a fully quantitative pipeline and publish every prediction before the race, so our track record is auditable by anyone.

The model in one paragraph

We blend opening-odds baselines, live drift (steam moves), sectional-time features and jockey/trainer form into a single win-probability model. After every meeting, an EMA (exponential moving average) calibration loop nudges model weights toward whatever the market is currently rewarding — no manual overrides, no hindsight edits.

What "drift detection" catches

When a horse's odds shorten 20%+ from the opening line in the last hours before a race, that's information. Our guard flags it, measures whether the drift is steam (smart money) or noise, and adjusts the predicted win percentage accordingly. On a recent card, drift signals correctly identified the two strongest late moves of the night.

Radical transparency

Every pick is timestamped pre-race and archived
Calibration changes are logged in a public parameter history (24 adjustments and counting)
We publish our misses. A model that can't show you its losing days is marketing, not science.

Full predictions, results and methodology: mystique-racing.com

Built in Hong Kong. Written by the pipeline, reviewed by humans.

I Run a Lottery Model That Publishes Its Own Failures — 51 Draws of Mark Six Data

Mystique Racing — Sat, 03 Oct 2026 12:00:13 +0000

Most lottery prediction sites show you their wins. Mine shows you the misses — every single one, on a public status page. Here's why I built it that way, and what 51 draws of Hong Kong Mark Six data actually look like under an honest model.

The setup

I maintain three independent number generators for Mark Six (6 numbers out of 49, plus an extra number):

Science — frequency, recency, and omission-gap weighting over the last 51 draws
Physics — ball-machine simulation priors (order statistics, positional bias)
Mystic — a deliberately non-statistical baseline (numerology rules) as a control group

Yes, the third one is a control group. If a "mystic" generator ever matches the statistical models' hit rate, that's evidence the statistical models carry no signal at all. So far the mystic baseline is losing, which is the only thing keeping the other two honest.

Last draw's post-mortem (draw 26104)

Winning numbers: [4, 28, 31, 44, 47, 48] + 19

Model	Hits	Note
Science	0/6	—
Physics	1/6	caught #44
Mystic	0/6	control group

Total: 1 hit vs. 2.2 expected for random picks of 18 numbers out of 49. Lift: −0.55. Below random.

I publish this number anyway. A model you can't audit is just marketing.

What self-calibration looks like

The racing side of the project (HKJC odds modeling) uses EMA-based parameter drift: every signal the model emits gets scored against actual results, and the weights update automatically. Over the last 24 recorded parameter updates, the "late steam" weight oscillated 0.947 → 0.992 → 0.981 while the model tried to correct for a day where 3 of 4 late market movers lost.

Nobody touched those numbers. The model graded its own homework and adjusted.

Draw 26105 (tonight's picks, published in advance)

Science: [7, 11, 13, 38, 39, 48] + 43
Physics: [7, 27, 30, 34, 44, 48] + 21
Mystic: [10, 23, 28, 36, 43, 48] + 3

Consensus across models: 48 (all three), 7 (two of three).

The result and the hit count will be public tomorrow, win or lose.

Why honesty is the actual product

Prediction content is a market for lemons — everyone claims 80% accuracy because nobody audits. The whole project (mystique-racing.com) is built around the opposite bet: full prediction history, full post-mortems, a public /status/ page with pipeline health, and calibration stats that include the losing streaks.

If the model is only as good as random over 200 draws, the site will say so. That's the deal.

Code side: Cloudflare Workers + Pages + KV/D1, cron snapshots every 2 minutes on race days, EMA drift loop in Python. Happy to answer architecture questions in the comments.