usage anchor lacks provider identity: silent drift when provider changes under an unchanged base_url

[pm25coder]

Reader feedback (Dev.to comment 3dicj by heinrichneb, source link at bottom): the anchor now dies on a deliberate switch, but what about the provider changing underneath the same base_url? Gateway reroutes, silently updated model versions: the hostname slug says 'same provider', the tokenizer disagrees anyway, and the anchor looks healthy while it drifts.

Verified against current master (11245ba):

• The usage anchor is a tuple (real prompt_tokens, local estimate) only - daemon.py:2597-2599. It never records which provider/model produced the real number.
• Invalidation runs on exactly one path: an explicit model switch where api_model != old_model (daemon.py:3566-3571) calling _invalidate_usage_anchors_on_switch (daemon.py:2974).
• A provider change underneath an unchanged base_url/model alias (gateway reroute, silent model update) therefore keeps the old provider's real prompt_tokens as the projection base. If the new provider reports tokens differently, the auto-compact projection under-counts - the emrg: usage-anchored auto-compact + stable system prefix for prompt cache (rants 2026-08-23T13:28:50, 13:54:14) #946 failure mode (148K estimated vs 222K real, gate never fired) can recur with no declared switch and no signal.

Reader's suggestion: a drift threshold that forces a re-anchor even when no switch was declared - the anchor falsifiable by its own number, not only by announced events. E.g. compare each new real prompt_tokens against the anchored base; on deviation beyond a threshold, re-anchor and append an anchor_drift event (the drift-measurement machinery from #995/#1013 could be reused).

Secondary suggestion: add a README metric - median time from reader-found boundary to merged fix (the 50-min loop claim becomes a measured number).

Source: https://dev.to/pm25coder/50-minutes-from-issue-to-merged-fix-when-the-readers-find-the-boundary-you-shipped-past-20g5 (comment 3dicj, 2026-08-26T20:43Z)

[argszero]

Verified against master (11245ba) — the gap is real and confirmed:

• The anchor is a bare (real prompt_tokens, local estimate) tuple; no provider/model identity recorded (daemon.py _usage_anchors).
• Invalidation fires only on an explicit model switch (api_model != old_model).
• _record_anchor_drift measures drift only after an anchor-LOSS window (post-compact / post-switch re-anchor) — a healthy-looking anchor under a silent provider change is never falsified.

The reader's suggestion (drift threshold falsifying the anchor by its own number) is the right shape. Since the local estimate is provider-independent (character-based), the bias ratio real/est is roughly constant per provider — an abrupt shift beyond a threshold is a reliable silent-tokenizer-change signal.

Fix submitted in PR #1029: per-round bias-shift detection before the anchor overwrite — on deviation beyond 25% it appends a countable anchor_provider_drift event (prev/new real+est, signed bias_shift, model, provider) and re-anchors on the new real number (natural overwrite). No declared switch needed.

[argszero]

Status update: the secondary suggestion from this issue (README metric for median reader-find-to-merged-fix latency) is now implemented and merged on master (PR #1030, commit 1940119) — the new scripts/reader_fix_latency.py measures it as a reproducible median across closed issues with merged fix PRs (currently ~38 min across 3 samples, matching the previously anecdotal claim).

The primary fix (silent provider/tokenizer drift detection) is in PR #1029 — per-round bias-ratio shift detection with a countable anchor_provider_drift event. It is CI-green and under review; it will close this issue when merged.