Skip to content

feat(meta): record Meta subscription usage and pass it to Muse - #4

Merged
ntindle merged 1 commit into
mainfrom
feat/meta-subscription-usage
Oct 8, 2026
Merged

ntindle merged 1 commit into
mainfrom
feat/meta-subscription-usage

Conversation

@ntindle

@ntindle ntindle commented Oct 8, 2026 •

Copy link
Copy Markdown
Owner

Meta has no usage endpoint. It reports the account's subscription windows in a response.subscription_usage event after response.completed on every Responses stream. The proxy dropped it: the Responses framer stops at the terminal event, so the Muse CLI never got its quota through the proxy, and nothing recorded it, so the management API showed no quota for Meta credentials.

What changes

  • Recorded: the Meta executor (streaming and buffered paths) records the event as X-Meta-* quota signals: window and weekly used percent, window length, reset times (unix seconds), and the tier id. They appear under quota in the management auth-files list, and soonest-reset reads them like Claude's and Codex's.
  • Forwarded: the Responses framer still passes this one event after the terminal event, which is where the Muse CLI reads it. Every other late frame is dropped as before, and nothing passes after an error terminal.
  • Kept across reloads: a saved credential file is reloaded by the watcher, and that reload replaced the in-memory auth, erasing its passive quota observation. The file never stores it. The reload now keeps the newest observation. This affected every provider.
  • FORK.md documents it, and fork-check.sh guards the five one-line hooks in upstream files and now covers internal/runtime/executor.

Evidence

  • The event, verified on 2026-10-08: a logging proxy between Muse 1.4.3 and api.meta.ai showed it on every /v1/responses stream, including Muse's background reminder calls: {"type":"response.subscription_usage","subscription":{"tier":"…","window":{"used_percent":0,"window_duration_mins":300,"resets_at":1791465557},"weekly":{"used_percent":5,"resets_at":1791763200}}}. Direct requests with different client headers all got it.
  • Before: the same request through the deployed hub (fe83ecf) ended at response.completed.
  • After, on a scratch instance of this branch on rust-builder (localhost, same Meta account, separate from tower):
    • the stream ends … > response.completed > response.subscription_usage;
    • auth-files shows the six X-Meta-* signals with observed_at;
    • Muse 1.4.3 pointed at the instance through endpoint_transport raised usage/changed after one turn;
    • the first request's observation survives the reload its own save triggers. Without the reload fix it was lost.
  • Tests: fork-check.sh passes in full on Go 1.26.8. go test ./... -count=1 passes, 100 packages. New TestFork* tests cover the parser, both executor paths, signal acceptance (Meta only), the reload, soonest-reset windows, and the framer (forwarded after completed, flushed undelimited, dropped after an error).

Not deployed. Tower keeps running fe83ecf until the image is updated.

Companion T3 Code change that reads these signals: pingdotgg/t3code#17151 (follow-up to #17082).

🤖 Generated with Claude Code

Meta has no usage endpoint. It reports the account's session window and weekly
usage in a response.subscription_usage event after response.completed on every
Responses stream. The proxy dropped that event: the Responses framer stops at the
terminal event, so the Muse CLI never saw its quota through the proxy, and nothing
recorded it, so the management API had no quota for Meta credentials.

- The Meta executor records the event as X-Meta-* quota signals, which the
  management auth-files list exposes under quota and soonest-reset reads.
- The Responses framer still forwards the event after the terminal event; every
  other late frame is dropped as before.
- Reloading a credential file keeps the passive quota observation. The file never
  stores it, so a reload used to erase it for every provider.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant