Price war monitor did something

Four alerts, and nothing happened that morning

Everything in that picture is correct. Here is the same thing as the monitor sent it:

The dashes are not missing data. At the time, notify() sent the ending edge as a bare is no longer contested with no numbers attached, which left an alert nobody could diagnose afterwards. That one is now fixed and deployed — the ending alert carries the same figures as the start.

The strange part is what the database says about those runs. The 02:25 and 10:25 checks — two of the four that sent alerts — wrote no price rows at all, for any model. The price table is a change log, so a row exists only when something actually moves. Nothing moved. The monitor announced a war starting and a war ending on two runs where no price on the board had changed.

The baseline is one row, and it was a week old

contested() watches a single field, the cache-read floor, and its deciding term is divergence: how far the cheapest seller has pulled away from the median across sellers now, divided by that same ratio at the start of a seven-day window. Clear 1.5× with enough floor movement and the model counts as contested.

“The start of the window” is one row — the most recent price change older than seven days. That single point is the entire denominator.

DeepSeek moved to peak and off-peak pricing on 16 August, with peak hours at 01:00–04:00 and 06:00–10:00 UTC. Off-peak, DeepSeek’s own endpoint is the cheapest seller of its models. At peak its prices double, a reseller undercuts the doubled sheet, and the floor changes hands. Four times a weekday, the floor toggles between two values.

So on 24 August the denominator was a row from 17 August, and which row it was depended on the hour:

Every hour the window’s left edge advances by an hour, and every few hours it crosses one of 17 August’s peak boundaries. The baseline flips between a peak row and an off-peak row, the divergence flips between 2.55× and 1.27×, and the flag flips with it. The alerts were never about that morning’s prices. They were tracking the previous Monday’s clock, on a seven-day delay.

I replayed contested() against the stored history to be sure, and it reproduces all four alerts exactly — the right models, the right runs, and every number in the Discord messages, down to the 26 seller changes.

One detail worth keeping: the 06:25 run fired at 06:25:34, two seconds past the cutoff it had to cross. A few seconds of scheduling jitter the other way and that alert lands an hour later.

Meanwhile, an actual price war

While the monitor was reporting two wars that were not happening, one that was happening went unmentioned. This is DeepSeek V4 Pro’s uncached input floor over the preceding three days:

Forty percent in three days, with StreamLake cutting roughly every hour and Baidu stepping in twice to take the floor off it. Across all 72 hourly checks in that stretch, the monitor said nothing at all.

The reason is one line of the detector: it only ever scores the cache-read price. That was a deliberate choice — cache reads are most of what a coding agent sends, so they decide the economics — but it means input and output can collapse in plain sight and the flag will never move. Cache read barely budged while those two fell off a cliff.

A note about the weekend

DeepSeek’s pricing page says peak hours apply Monday through Friday. In the log the toggle is plainly there on Saturday 22 August, on all three DeepSeek models, at the usual boundaries — and absent on both Sundays I have. One Saturday and two Sundays is thin evidence, so this is a thing to watch rather than a rule, but the published clause does not match what the prices did.

What I would change

The ending-alert fix is done. The real defect is the baseline: anchoring divergence to whichever row happens to be seven days old means anything on a repeating schedule will ring forever, on a one-week delay, without a single new price movement. Comparing against the median ratio across the window instead of its first point would fix it, as would requiring the flag to hold for several consecutive runs. Both change what counts as a war, so they are Asuwa’s call — and the Python reference implementation has to change in step.

Until then, the rule I would use: if a contested flag names a model with scheduled pricing, check what its baseline row was before believing it.