Repository navigation
Description
Problem
The Meta (Muse Code High Usage) pool's percentage read rests on POST https://api.meta.ai/muse-code/key (subs_usage), which Meta's server currently does not populate — and has a proven history of not populating in non-exhausted states too (51 consecutive null probes 2026-10-28→11-02 while the console showed 9%→100%). Determination with full evidence: #3347 comment 6650593668. The key endpoint is a valid subscription-active/tier signal but cannot be the system of record for percentages.
The faithful source is the dev.meta.ai portal API (the #1301 exporter's source, retired by #5040 in favour of the key endpoint — that trade should be reversed for percentages).
Fix: laptop-side portal fetcher for the gatherer
On the existing ~15-min gatherer tick, from the LAPTOP (same egress/device as the session, per the 2026-10-26 console investigation's Phase 1 design):
- Cookie capture: read the
llama_dev_sesscookie (plusdatrfor the same host) fordev.meta.aifrom the live Helium profile via CDP (Storage.getCookiesagainst the laptop Helium debug port). The session is in the desktop Helium's default profile, which currently runs without a debug port — the capture step needs Helium launched/attached with--remote-debugging-port(or an equivalent profile-copy launch) at capture time. Cookie value goes directly into the gatherer's secret handling — never into a file, log, or this repo. Expected lifetime ~1 year (captured cookie expiry 2027-10-27); treat 401/Not authenticatedas failure classsession-expired→ row goes stale-with-reason per the fix(quota-gatherer): ok-but-null retains last-known (no-data); Command Code explicit ask + plan windows (#5704) #5719 retention behaviour, never zeros.- Note (2026-11-04): the Oct-era profile copy at
~/atlas/helium-chatgpt-profile-copyno longer authenticates (401 on/api/auth/me) — do not reuse it; capture from the live profile.
- Note (2026-11-04): the Oct-era profile copy at
- Reads (cookie-auth GETs, base
https://dev.meta.ai, team1073226932208501= "My Team"):GET /api/portal/teams/{team_id}/subscription-quota→{subscription_quota: {tier: "Muse Code High Usage", as_of, window_weighted_used, window_weighted_limit: "100000000000", window_duration_secs: 18000, window_resets_at, weekly_weighted_used, weekly_weighted_limit: "300000000000", weekly_resets_at}}— used/limit are stringified integers in weighted units; % = used/limit; the 18000s window is the rolling window, plus the weekly window. Proven live payload 2026-10-27 (window 1.02%, weekly 8.83%; resets matched the key endpoint's boundaries exactly).GET /api/portal/teams/{team_id}/billing-banner→{kind, remaining_minor_units, currency}— free credits remaining (minor units = cents; $148.57 at last read).- Map into the existing meta row shape (
meta:high-usage): rolling + weekly windows with usedPercent + resetsAt, free credits as the balance figure. The portal's own note applies: "new usage can take up to an hour to appear" — carryas_ofas measuredAt.
- Keep the key-endpoint fetcher as a cross-check, not the source: its
is_subs_active/subs_tier_name/require_paymentremain the cheapest active/tier signal, and an inference-path 429 (quota exhausted, with reset) corroborates a 100% weekly. If portal and key-endpoint disagree about exhaustion, prefer the portal's percentages and record the disagreement in the row's reason. - Testing: fixture tests from the captured 2026-10-27 payload shape (stringified weighted units, % derivation, reset mapping) + the session-expired and portal-error classes; oracle = the recorded payload + a live console read at verification time.
Acceptance
- Two consecutive gatherer ticks carry a fresh ok meta entry with real (non-null) rolling + weekly percentages sourced from the portal API.
- The laptop live route (
/api/quota/meta) and the hub entry agree. - A forced session-expired test (bad cookie) yields the
session-expiredstale-with-reason row, not zeros and not a silent null. - fix(quota-plane): Meta quota read path dead on both routes — hub file-export 'no-console-page' (16 ticks) + live /api/quota/meta null windows (20 probes) #3347's remaining acceptance (recovered read recorded in the pool-change ledger by the next steward pass) can be satisfied.
Related: #3347 (root-cause determination), #1301 (original exporter, closed), #5040 (source switch being partially reversed), #5719 (retention behaviour), #5101 (board stale-fallback display).
Acceptance criteria
- The gatherer's Meta percentage read comes from the dev.meta.ai portal API (
subscription-quota) fetched laptop-side on the existing gatherer tick; both the rolling (18000s) and weekly window percentages are computed from used/limit. - The cookie is captured from the live Helium profile at capture time and passes only through the gatherer's secret handling — it appears in no file, log, or repo content.
- A 401 /
Not authenticatedresponse is failure classsession-expired: the row goes stale-with-reason per fix(quota-gatherer): ok-but-null retains last-known (no-data); Command Code explicit ask + plan windows (#5704) #5719 retention, never zeros. - The key endpoint remains only as a subscription-active/tier signal; it is no longer the system of record for percentages.
Activity
developing-today commentedon Nov 5, 2026
CODE-1742
dezren39 commentedon Nov 5, 2026
Intake review
subs_usage.--remote-debugging-port, or profile-copy launch) is the first thing to prove.subscription-quota; then wire it into the gatherer tick behind the existing Meta row, keeping the key endpoint as the subscription-active signal only.dezren39 commentedon Nov 5, 2026
Auth-renewal requirement (Drew's standing rule, 2026-11-05 01:10 CST — provider browser-auth auto-renewal): the restored portal fetcher must NOT depend on a manually captured
llama_dev_sesscookie with a silent expiry. The restore design must include cookie auto-renewal as a built-in: on cadence and on auth failure (401), re-capture/refresh the portal session cookie automatically from the standing signed-in laptop Helium profile via CDP (the capture step this issue already names, run by the fetcher itself rather than by a human lane), verify with a livesubscription-quotaread after renewal, and raise an alert BEFORE hard expiry when renewal fails (the fetcher's state must name the cookie's remaining horizon, not just fail at zero). A one-shot manual capture is the bootstrap, not the mechanism. Inventory + tracking: see the provider browser-auth auto-renewal tracking issue filed 2026-11-05 and ~/memory/topics/provider-auth-renewal-2026-11-05.md.dezren39 commentedon Nov 5, 2026
Correction / supersession (2026-11-05, Drew's quota single-source order, tracked on #6125): this restore should NOT land as a gatherer-side fetcher. Drew's rule: "dashboard and all other sources should rely on opencode quota subcommand only, 1 single source for quota info" — and any reading the subcommand can't yet produce gets implemented IN THE PROVIDER, never scraped gatherer-side.
So the portal-API fetcher designed here moves INTO the meta provider's quota implementation in the opencode fork, behind the new
opencode quotasubcommand. The gatherer's only quota input becomes the subcommand's output. The portal-API design itself (dev.meta.ai portal API, cookie auth, weighted units — proven 2026-10-27) stands and is the implementation spec for the provider-side port; the auto-renewal requirement recorded here (cookie must auto-renew per Drew's 2026-11-05 standing rule) carries into the provider credential machinery. This issue stays open as the design record; implementation + acceptance live on #6125.dezren39 commentedon Nov 5, 2026
Meta quota measurement — diagnosis + blocker (2026-11-05, 'fix meta' directive):
Root cause: both read paths (this issue's provider portal read; the laptop file-export) ride the single Helium dev.meta.ai session, and that session is logged out. Verified twice today: a fresh-tab CDP probe of
/api/portal/teams/1073226932208501/subscription-quotareturns HTTP 401{"error":"Not authenticated"}(same as the exporter's last document, 2026-11-04). The provider read currently returnsok:false 'Quota fetch timed out after 30000ms'; the gatherer's Meta row is retained-from-failed-tick (measuredAt 2026-11-04T18:30:20Z, null windows). Last good read remains 2026-11-03 21:00Z.Compounding defect, fixed in passing: the pre-existing dev.meta.ai tab had a hung renderer — trivial CDP evaluates timed out on it — which is why both consumers timed out instead of failing fast on the 401. That tab is closed.
Also found:
meta-quota-export.service/.timerwere renamed to.backupon 2026-11-01; the exporter has been unscheduled since. The renewal build (OpenDesign-keeper pattern, per the requirement recorded on this issue) must restore scheduling, not just the session.Blocker — one Drew-only step: re-login was driven through auth.meta.com (email door, account identifier accepted) to the emailed-code challenge: a login code was sent to Drew's email at ~09:31 CST and the laptop Helium tab is parked on the 'Check your email' page. Once the code is entered there, the session lands and the remaining steps (fresh-read verification on both paths, keeper build, exporter timer restore, gatherer confirmation, registry entry) proceed.
Merge pull request #6315 from developing-today/feat/meta-renewal-keeper
developing-today commentedon Nov 5, 2026
Fix-meta complete — measurement restored 2026-11-05.
/api/portal/teams/1073226932208501/subscription-quotareturns HTTP 200 in the Helium page context, and the exporter independently read the same state. Faithful exhausted read — weekly 300,549,363,810 / 300,000,000,000 (100.18%), resets 2026-11-09T00:00Z; 5h window unused; free credits $148.57.meta-quota-export.service/.timermoved back from their.backupnames (renamed 2026-11-01), timer active + enabled, first run Result=success —latest.jsonfresh with statusok(2026-11-05T16:30Z), ticking every 15 min.window_resets_at, which the live portal omits while the 5h window is unstarted — soopencode quota --json metapublished ok-but-percentless results and the gatherer retained last-known (no-data: provider reported ok but no window carried a percentage). Fixed, regression-tested (live payload shape), and merged: developing-today-forks/opencode PR laptop-untracked-review: bare git commit sweeps pre-staged work into its commits — the junk-ignore commit also lands the newly tracked files and any unrelated staged edit #1751, merge24784651b. Percentages land inquota-current.jsonon the first gather tick after a fork build from main ≥ that merge deploys (the fork-deploy lane's in-flight track); until then the gatherer keeps retaining the last-known row, which is the designed response to a percentless read.b830347c2a) addspm-stack/aggregator/src/meta-renewal.ts— the opendesign-renewal pattern adapted to a browser-only session: watch the exporter probe every tick, re-arm the exporter units (including restoring.backuprenames), take a fresh probe, and alert inmeta-renewal.jsonfrom the first bad tick. Verified in production on a live tick:status=valid. Registered in~/memory/topics/provider-auth-renewal-2026-11-05.md.dezren39 commentedon Nov 5, 2026
agent-note:v1 — task 10442 (triage, #6079) TRIAGED CONFIRMED by lane code-u at main c26e058 (2026-11-05, includes PR #6262 merge).
Evidence at current main:
Routing: follow-up implementation enqueued as task 10642 (small_fix, repo-health-code-pilot, dedupe repo-health:v1:fix:developing-today/code:issue:6079) carrying the issue's fix section verbatim in scope: laptop-side portal fetcher beside src/meta-renewal.ts wired into gather-quota.ts, team 1073226932208501 subscription-quota + billing-banner, session-expired failure class per #5719 retention, key endpoint demoted to cross-check, fixture tests from the 2026-10-27 payload shape.
Blockers/ordering recorded: the only runtime prerequisite is the live Helium session on the laptop being reachable over CDP at capture time (the Oct-era profile copy no longer authenticates — do not reuse it, per the issue body). No code blocker. Also noted: this issue carried a stale status:done label while open and unimplemented; removed during this triage's label sync.