serve (gpt-5.5) requests not charged against ChatGPT subscription usage — accounts usage stuck at 0% + additional_rate_limits not displayed

Summary

Requests coming through vicoop-codex serve (and the vicoop-bridge baseline agent) actually call the model and return valid responses, yet the usage is never charged against the ChatGPT subscription usage windows. vicoop-codex accounts usage stays pinned at 0% used for both the 5h and weekly windows even immediately after real traffic.

Investigation shows this matches a usage-accounting bug class reported upstream in openai/codex — specifically the path where a third-party client hits the responses endpoint directly. Separately, we also found a display bug where accounts usage ignores additional_rate_limits.

Environment

• vicoop-codex 0.5.1 (provider host, run continuously as a systemd --user service: serve -p 0 -H 127.0.0.1)
• 2 accounts enrolled, selection strategy burn-rate
  • Account A — plan pro (active)
  • Account B — plan prolite
• Models advertised by /models: gpt-5.5, gpt-5.4, gpt-5.4-mini, gpt-5.3-codex-spark, codex-auto-review
• Model actually used: gpt-5.5 (= serve's default model, see analysis below)

Symptom / Measured data

Live single-request test: model=gpt-5.5 returned a valid response ("PONG"), usage = {prompt 27, completion 19, total 46, reasoning 11}. So this is not a mock / dry-run / zero-backfill. The active account's last_used_at also updated right after the traffic → requests genuinely go out on a real account and get processed.

Load test to rule out the "too small, rounds to 0%" hypothesis — 8 sequential gpt-5.5 requests (~637–757 tokens each, ~5.4K tokens total), before/after on the active (pro) account windows (accounts usage --json raw):

Metric	before	after
primary (5h) used_percent	0	0
secondary (weekly) used_percent	0	0
additional_rate_limits[GPT-5.3-Codex-Spark]	0 / 0	0 / 0
credits.approx_local_messages	[0,0]	[0,0]
primary reset_after_seconds	16717	16571 (decreases only by wall-clock, no re-anchor)

→ ~5.4K tokens were actually consumed, yet nothing moved on any meter. The key signature: reset_after decreases only by wall-clock time with no window re-anchor — i.e. the backend "acknowledges" the request but never increments used_percent.

Code-path analysis

1. src/commands/serve.ts — ROUTE_PATH = "/v1/chat/completions" → calls postUpstream (src/client/responses.ts).
2. src/client/responses.ts postUpstream → fetchCodexBackend("/responses", …) (store:false, SSE).
3. src/client/backend.ts:3 CHATGPT_CODEX_API_BASE_URL = "https://chatgpt.com/backend-api/codex" — the same …/codex/responses endpoint the official Codex CLI uses. Headers are identical too (Authorization: Bearer, ChatGPT-Account-ID, OAI-Product-Sku: codex, originator: codex_cli_rs).
4. Default model: resolveDefaultModel in src/client/default-model.ts picks ids.find(id => !rejected.has(id)) from the advertised /models list, i.e. the list head = gpt-5.5. So any request without an explicit model (the baseline agent) goes out as gpt-5.5.

In short, the call path itself is identical to the official Codex, yet usage is still not recorded.

Related upstream reports (openai/codex)

Open issues with a matching symptom exist:

• #17455 "Usage not decreasing at all" — many parallel Codex CLI runs, 5h/weekly didn't drop even 1%, Web usage breakdown also showed no activity. "Codex does recognize usage — the 5h reset window counts down, but the limit stays at 100%" → exactly our signature. → Closed as a duplicate of #17764.
• #17764 "Quota & Credit Accounting Bug" — weekly 0% / 5h stuck at 100%, credits not charged despite active use. Via OpenCode (third-party integration). Reporter: unclear whether root cause is the Codex backend accounting or the integration layer. Status: OPEN, no official root cause / fix. ← Same structure as ours: a third-party calling the responses path directly.
• Same accounting-instability family: #21708, #15094, #23994, #6658.

Conversely, per the official docs/app, gpt-5.5 is supposed to count against the plan limit (help, pricing), and in the official app there are in fact many opposite reports of gpt-5.5 draining the limit too fast (#19215, #19571). → So this is not "gpt-5.5 is free" but rather a backend / integration-layer accounting bug where usage is dropped on the third-party responses path, which is what the evidence supports.

Note: the GPT-5.3-Codex-Spark (metered_feature: codex_bengalfox) bucket we saw in the raw payload showing up as a separate window is consistent with the docs (Pro-only research preview, separate usage limit).

Related finding (split out → #24)

accounts usage ignores the upstream additional_rate_limits[] (e.g. GPT-5.3-Codex-Spark / codex_bengalfox) and only shows the top-level 5h / weekly windows. That's a separate, independently-fixable display bug — tracked in #24. (In this investigation that bucket was also 0, so it didn't hide any consumption here.)

Impact

• Operationally confusing: "requests are processed but the subscription quota never drops." Usage-based monitoring / limit enforcement becomes meaningless.
• If the root cause is the OpenAI backend (responses-path accounting), it can't be fixed client-side and needs upstream-issue tracking.

Proposed actions

1. Track upstream: comment on openai/codex #17764 with our repro data (third-party responses path + reset window counts down + used_percent stuck at 0 + 8 requests / ~5.4K tokens with no effect) to add signal.
2. Display patch (tracked separately in #24): have src/client/usage.ts parse additional_rate_limits[] and surface it in accounts usage (per-model / per-feature windows), so it's verifiable once accounting is fixed.
3. (Optional) metering-verification path: set --default-model to a metered codex model (gpt-5.3-codex-spark) and measure whether usage drops on the same path. Caveat: if the same responses path drops it the same way, the result is inconclusive — need to also check additional_rate_limits in accounts usage --json.

---

Sensitive data (emails, account IDs, tokens, router key) intentionally omitted. See internal channel for the raw repro data.

Start with src/commands/serve.ts, src/client/responses.ts, src/client/backend.ts, and src/client/default-model.ts to trace the requests endpoint and default model. Compare the observed behavior with upstream openai/codex issue #17764, including the reset window and usage fields. Done means identifying an actionable client-side cause or documenting the upstream dependency and repro clearly.