Repository navigation
aggregator(quota): /quota attention item lags the pass-through read — Meta weekly attention says 98% while the fresh read and the same payload's pool row say 99% #5101
Description
Found by the pool-quota steward (run 132, 2026-11-03) during the step-6 PM page-truth check after the PR #5080 pass-through landing.
Read (source of truth): quota-current.json gatherer tick 2026-11-03T19:30:08.572Z, source openchamber-quota; meta measuredAt 2026-11-03T19:30:13.527Z — 5h 2%, weekly 99% (reset Sun Nov 8 6:00 PM CST). Live probe at ~19:40Z agrees: weekly 99%.
Page disagreement: GET http://localhost:4870/api/quota.json (same 19:30 tick) — pools[meta] weekly percent is 99 (correct pass-through), but the payload's attention array carries {label: "Meta Model API · Muse API High Usage — weekly", detail: "98% of limit used", severity: 98}, and the /quota HTML attention strip likewise renders "98% of limit used". 98% was the PREVIOUS tick's value (18:30Z read), so the attention item appears to be computed from a stale source (prior tick or a dated quota-view observation) instead of the fresh read the pools now pass through.
Expected: post-#5080, every percentage on /quota — attention items included — derives from the same fresh OpenCode quota read as the pool rows, with measuredAt/source freshness carried through.
All other pools matched the read pool-for-pool this run (12/12 pool ids, windows/state/freshness identical). Steward made no quota-view edit to compensate, per the 2026-11-03 pass-through ruling; recording the diff here instead.
Acceptance criteria
- The /quota attention item reflects the same value as the pass-through read within the same refresh cycle (the lag described in the issue is gone, verified against a live Meta weekly state change or a fixture)
- No regression in the other /quota fields (verified against the aggregator's existing quota tests or a manual read comparison)
Activity
dezren39 commentedon Nov 3, 2026
Intake review
Fleet monitor intake pass (2026-11-03T20:55:07Z): verified OPEN, no
held/user/ownedlabels.Related (title-search of merged PRs):
Notes: No merged PR explicitly resolves this issue; it reads as still live. Acceptance criteria appended to the body. Priority: priority/normal — stale attention signal, misleading but not blocking. Effort: effort/s.
Risks / suggested approach: Work from the evidence in the body first; reproduce at current main before changing anything, and route the fix through the queue if it grows past the effort class above.
dezren39 commentedon Nov 3, 2026
Steward refresh (pool-quota-steward 133rd run, 2026-11-03T21:15Z read): the attention lag persists and has widened. The fresh pass-through read (quota-current.json generatedAt 2026-11-03T21:15:03.342Z, source openchamber-quota) puts Meta weekly at 100% (walled; the same payload's own meta pool row also renders 100%, state walled), while the /api/quota.json attention array still reads "Meta Model API · Muse API High Usage — weekly — 98% of limit used" (severity 98) — the value from the 18:30Z tick, now two ticks stale. All 12 pool rows otherwise match the 21:15 read pool-for-pool on windows/state/freshness. No quota-view prose was edited to compensate, per the pass-through ruling.
dezren39 commentedon Nov 3, 2026
Steward refresh 2026-11-03T21:33Z (134th pool-quota-steward run): the attention lag persists and is now three ticks stale. Fresh read (quota-current.json generatedAt 2026-11-03T21:30:10.316Z, source openchamber-quota): meta weekly = 100% (pool walled/closed until Sun Nov 8 6:00 PM CST), and the same /api/quota.json payload's own meta pool row says weekly 100%. The payload's attention array still reads "Meta Model API · Muse API High Usage — weekly — 98% of limit used" (severity 98) — 98% was the 18:30Z tick's value. All 12 board pools otherwise match the 21:30 read pool-for-pool (windows, state, measuredAt freshness verified programmatically). No quota-view prose edited to compensate, per the pass-through ruling (PR #5080).
dezren39 commentedon Nov 3, 2026
Steward refresh — 135th run, 2026-11-03T22:56Z board fetch against the fresh 22:45:15Z gatherer read (source openchamber-quota, heartbeat ok).
Read-vs-page diff (unchanged in kind, still open): the /api/quota.json payload's own meta pool row agrees with the read — weekly 100% (walled, resets Sun Nov 8 6:00 PM CST), 5-hour 4% — but the payload's attention array still carries: "Meta Model API · Muse API High Usage — weekly — 98% of limit used" (severity 98). The 98% figure is now at least four ticks stale (it was the 18:30Z tick's value; the read has said 100% on every tick since the weekly walled).
Everything else in the payload matches the 22:45:15Z read pool-for-pool (12/12 board rows verified programmatically this run: windows, state, measuredAt + source identical; claude renders its error as freshness with the dated fallback weekly 68% standing, which is correct pass-through behavior). No quota-view prose edited — per the pass-through ruling this is an aggregator-side lag in the attention derivation only.
dezren39 commentedon Nov 4, 2026
Pool-quota steward, 136th run (2026-11-04T00:33Z) — step-6 PM page-truth refresh:
The Meta disagreement has changed shape. The board no longer disagrees with a 100% read; the READ itself now carries no Meta windows:
usedPercentare both null. The laptop live route (/api/quota/meta, probed 00:25Z and 00:30Z) agrees: ok:true with null windows./api/quota.jsonrenders meta as state "near" with the weekly window standing at 98% (the stale dated fallback — 98% was the 18:30Z tick's value), and the attention array still reads "Meta Model API · Muse API High Usage — weekly — 98% of limit used" (severity 98).So the page is presenting a five-plus-tick-old 98% as the pool's current state while the fresh read says nothing at all. All other 11 pools matched the 00:15Z read pool-for-pool this run (windows, state, freshness). No quota-view prose was edited to compensate, per the pass-through ruling (PR #5080). The read-side regression itself is reported on #3347.
dezren39 commentedon Nov 4, 2026
Steward 137th run (2026-11-04T01:50Z): the meta page-vs-read disagreement PERSISTS unchanged. The 01:45:19Z read reports meta with NULL windows (state ok); /api/quota.json still renders meta from the stale dated fallback — weekly 98%, state "near" — and the attention array still carries "Meta Model API · Muse API High Usage — weekly: 98% of limit used". The last verified read was weekly 100% (2026-11-03T22:45Z tick), so the page understates a CLOSED pool as near. All other 11 pools match the read pool-for-pool (verified programmatically). No quota-view prose edited — pass-through era: this remains an aggregator fallback-promotion observation, tracked here.
dezren39 commentedon Nov 4, 2026
Pool-quota steward 138th run (2026-11-04T02:30Z tick): the Meta disagreement persists a fourth consecutive tick set. The OpenCode quota read (quota-current.json generatedAt 2026-11-04T02:30:10Z, source openchamber-quota) again returns the meta pool state ok with NULL rolling/weekly windows (measuredAt 02:30:15Z), while /api/quota.json stands the meta row at weekly 98% from the stale dated fallback (state "near"), and the attention array likewise carries Meta weekly at 98%. All 11 other board pools match the 02:30Z read pool-for-pool on windows/state/freshness. Last verified Meta read remains 2026-11-03T22:45Z (5h 4% / weekly 100%); the pool is proceeded-on as CLOSED on the weekly until Sun Nov 8 6:00 PM CST. No quota-view prose edited — this is the read-vs-page fallback standing, recorded per the steward step-6 duty.
dezren39 commentedon Nov 4, 2026
Pool-quota steward, 139th run (2026-11-04T03:30Z): board-vs-read comparison against the fresh 03:15:02Z hub read — 11/12 pools match pool-for-pool (windows/state/freshness verified programmatically). The lone disagreement is unchanged: META — the read reports state ok with NULL windows (read regression, see code#3347), while the page stands at the stale dated fallback weekly 98% (state "near"; attention array also 98%). No quota-view prose edited (pass-through era: this is recorded as a read/fallback observation, not a display fix). Claude error renders correctly (error as freshness, dated fallback weekly 68% standing). Deepseek board row renders the fallback dated observation ¥44.63 (2026-10-25) vs live ¥44.29 flat — fail-soft fallback working as designed (deepseek absent from the hub read).
dezren39 commentedon Nov 4, 2026
Steward refresh 2026-11-04T04:35Z (140th run): the board's Meta row STILL disagrees with the read. Against the fresh 2026-11-04T04:30:12Z gatherer read (windows null, state ok, measuredAt 04:30:15.499Z), /api/quota.json renders meta weekly 98% (state near) from the stale dated fallback, and the attention array likewise carries 98%. All other 11 pool ids match the read pool-for-pool (verified programmatically), including the newly walled openai.alternate (weekly 100% / 5h 87%, state walled — page and read agree). No quota-view prose edited; this is the standing read-vs-page diff, refreshed not duplicated.
33 remaining items
dezren39 commentedon Nov 4, 2026
agent-note:v1
task: 9490
lane: code-q (repo-queue-worker-shift-q)
state: handed_off (execution lane: opencode)
Re-verified fresh 2026-11-04T17:30Z: issue #5101 OPEN, no hard-stop labels, no PR found for #5101. Stale parked labels repaired to the claimed set (queue/claimed + status/in-progress + work/assigned). Handing task 9490 to the opencode claimant to implement the live.ts usage() overlay fix per the packet.
dezren39 commentedon Nov 4, 2026
Steward run 154 (2026-11-04T18:24Z): board-vs-read check against the fresh 18:15:03Z read — 11/12 pools match pool-for-pool; Meta remains the lone disagreement: the read's windows are null while the page renders the stale dated fallback weekly 98% (state "near"; the attention item agrees with the row at 98%). Everything else is identical, incl. popesdrew walled at 5h 100% / weekly 40% / monthly 20%, openai.main weekly 33%, and the Turso SaaS storage figure 85.146%. No quota-view prose edited (pass-through per #5080).
dezren39 commentedon Nov 4, 2026
Steward run 155 (2026-11-04T19:2xZ): the Meta board disagreement persists,
now in the stale-read rendering.
quota-current.json, last good tick 2026-11-04T18:30:15Z —the gatherer is down since 18:45Z, see fix(quota-plane): quota-gatherer failing every tick since 2026-11-04T18:45Z — auth.openCodeLocalCredentialSource is not a function #5638): Meta windows null.
/api/quota.json, fetched ~19:26Z): Meta row state "stale",weekly 98% dated fallback, and the attention item still reads
"Meta Model API · Muse API High Usage — weekly — 98% of limit used".
the dated fallback while the freshest read reports null windows.
No quota-view prose edited by the steward.
dezren39 commentedon Nov 4, 2026
Steward 156th run (2026-11-04T20:2xZ): with the gatherer down (#5638), the board remains in fail-soft — the meta pool row renders the stale dated fallback (weekly 98%, state "stale", freshness measuredAt 2026-11-04T18:30:20.764Z) while the source read (quota-current.json) reports null meta windows. The standing read-vs-page disagreement is unchanged; no quota-view prose edited to compensate.
dezren39 commentedon Nov 4, 2026
Pool-quota steward, 157th run (2026-11-04T21:26Z): board still in fail-soft stale mode while the gatherer is down (#5638). /api/quota.json renders all 12 pool rows state "stale" (claude "error") on dated fallback windows; the Meta row + attention item still show the stale weekly 98% fallback against the read's null windows (measuredAt 2026-11-04T18:30:20Z, source openchamber-quota). Literal pool-for-pool match vs the frozen 18:30Z read remains 0/12 on window values — the designed fallback for an unmeasurable read, unchanged in shape from the 156th run. No quota-view prose edited. This refreshes only when the shape changes or the gatherer recovers.
dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
opencode, so this task is handed off to the opencode claimant, which launches the bound opencode session. Checkpointed stagehanded_offon task 9490.dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off
ses_e5e5638f021ffexnGOBXOzs3JMdezren39 commentedon Nov 5, 2026
🤖 Agent note · picked up
ses_e5e5638f021ffexnGOBXOzs3JM/quotaattention overlay fix and regression coverage from task 9490.usage()branches; preserve overlay semantics and thresholds.dezren39 commentedon Nov 5, 2026
🤖 Agent note · blocked
ses_e5e5638f021ffexnGOBXOzs3JM