Repository navigation
sync-models: existing entries are never reconciled when limit.context already matches — a wrong limit.output and stale variants survive every sync #1799
Description
Bug
bin/sync-models.mjs — the "existing model" update branches judge drift by limit.context only, so two kinds of drift are never reconciled and the sync reports the config up-to-date while it stays wrong:
bin/sync-models.mjs:543(antigravity-agy / antigravity-ls):if (prov.models[baseId].limit?.context !== limits.context)— the wholelimitobject is replaced only whencontextdiffers. Ifcontextalready matches, a wrong or stalelimit.output(the sync's own desired values come fromdefaultLimits,bin/sync-models.mjs:488-492: claude 64000, gpt-oss 16384, otherwise 65536) is kept forever.bin/sync-models.mjs:538: variants are written only when the existing entry has none (&& !prov.models[baseId].variants). If a model's effort set changes upstream (an effort dropped or added), an existingvariantsmap is never updated: stale efforts stay offered and new efforts never appear.bin/sync-models.mjs:583(openai-codex): the same shape —if (codexProv.models[m.slug].limit?.context !== 1000000)— so a codex entry with the right context but any otheroutputthan the sync's 128000 is never corrected.
Because no edit is recorded for these cases, the run's summary counts no update, and a later run sees the same state and again does nothing: the sync does not converge.
Evidence (verified this run)
Laptop probe ~/git/fleet/probe-2026-10-28-laneB-syncmodels/probe.mjs (node v24; source bin/sync-models.mjs sha256 5e21fe06… on the laptop, identical to sandbox main e91098f1; all three condition strings asserted present verbatim, then the two branches copied verbatim and run over fixtures):
A control context-drift: changed=true limit={"context":1048576,"output":65536}
B agy output-drift: changed=false limit={"context":1048576,"output":9999} (desired output 65536)
C agy variants-drift: changed=false variants=["low"] (desired high,medium)
D codex output-drift: changed=false limit={"context":1000000,"output":1} (desired output 128000)
E control codex context-drift: changed=true limit={"context":1000000,"output":128000}
BUG CONFIRMED: output-limit and variants drift are never reconciled when context matches
Controls A/E show the branches do fire when context differs (and fix output only as a side effect of replacing the whole object); B/C/D show that with context already correct, nothing ever fires.
Why it matters
sync-models is the tool that keeps the opencode config's model entries honest against the live catalogs. An entry whose output limit was set wrong — by a hand edit, an older sync with different defaults, or a changed defaultLimits — is silently permanent, and the operator is told "All providers are already up-to-date". The same holds for the reasoning-effort variants a model is offered with: once written, they are frozen at whatever the first sync saw.
Acceptance criteria
- The agy/ls update branch reconciles the full desired state: if the existing
limitdiffers fromdefaultLimits(id)incontextoroutput, the limit is replaced (one edit, counted as an update); if the existingvariantsdiffer from the variants built from the current effort set, they are replaced the same way. - The codex update branch likewise fires when
outputdiffers from 128000, not only whencontextdiffers from 1000000. - Regression tests in
bin/sync-models.test.mjs(verbatim-extraction style, as forparseJsonc): output-only drift is corrected, variants drift is corrected, and an already-correct entry records no edit. - A genuinely up-to-date entry still produces no edits and no count changes (no write churn on every run).
Found by new-issue-creator-code-b. Dedup: gh issue list --search 'sync-models' (open + closed) on 2026-10-28 shows only #704 (parseJsonc), #591 (Nix store path), #1754 (provider-catalog-sync, a different script) and unrelated mentions — nothing on limit/variants reconciliation.
Activity
developing-today commentedon Oct 28, 2026
CODE-738
dezren39 commentedon Oct 28, 2026
🤖 Agent note · filed
e91098f1that bin/sync-models.mjs's existing-entry branches (agy/ls :538/:543, codex :583) judge drift by limit.context only: a wrong limit.output and a stale variants map record no edit and are never reconciled. Laptop probe (source sha256 5e21fe06… = main; three condition strings asserted verbatim; branches copied verbatim over fixtures): controls with context drift changed=true; output-only drift changed=false (output stayed 9999 vs desired 65536; codex stayed 1 vs 128000); variants drift changed=false (stale [low] kept vs desired high,medium).queue-packets/packet-1799.json(repo-health-code-pilot, triage); probe~/git/fleet/probe-2026-10-28-laneB-syncmodels/(laptop)dezren39 commentedon Nov 1, 2026
agent-note:v1 — holder: repo-worker-code (OpenChamber scheduled lane), since 2026-11-01. Picked up queue task 2674 to revalidate the reported sync-models drift on current main before routing or closing with evidence.
8 remaining items
dezren39 commentedon Nov 1, 2026
agent-note:v1 — state=picked-up; task=5044; worker=repo-worker-code; at=2026-11-01T22:20:16Z. Queue task claimed; current issue is open with no hard-stop labels and no competing open implementation PR. Revalidating the implementation on fresh main before edits.
dezren39 commentedon Nov 1, 2026
agent-note:v1 — state=blocked; task=5044; worker=repo-worker-code; at=2026-11-01T22:21:14Z. Packet defect: current main retired antigravity-agy and antigravity-ls on 2026-10-30, but this packet and #1799 still target their reconciliation. No edits made; needs corrected scope or a separate confirmed codex-only task.
developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 5044 (small_fix, blocked, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03