Expose explicit model-to-rate-limit bucket mapping through app-server

Start with codex-rs/app-server/src/request_processors/account_processor.rs and the account/rateLimits/read schema, including its rateLimitsByLimitId snapshots. Trace how model catalog entries and backend limit_id values are exposed, then define and document an explicit join while preserving existing fields; done means selectable models have supported shared or model-specific mappings without name inference or quota consumption.

What variant of Codex are you using?

Codex App / CLI app-server

What feature would you like to see?

Problem

Codex already exposes structured quota snapshots through account/rateLimits/read. The current implementation also returns rateLimitsByLimitId, including additional model-specific buckets when the backend provides them.

The missing piece is a supported mapping from selectable model IDs to the quota bucket or buckets that apply to them.

For example, public reports show a model-specific bucket such as:

• model: gpt-5.3-codex-spark
• limit ID: codex_bengalfox
• limit name: GPT-5.3-Codex-Spark

A client can display the returned buckets, but it should not need to hard-code that opaque limit ID or infer model applicability from limitName. This becomes especially ambiguous when a model consumes both a shared Codex bucket and a model-specific bucket.

Requested feature

Expose an explicit model-to-rate-limit mapping through a supported app-server schema.

Two possible shapes:

1. Add quota bucket IDs to each model returned by the model catalog:

{
  "id": "gpt-5.3-codex-spark",
  "rateLimitBucketIds": ["codex", "codex_bengalfox"]
}

2. Or add model applicability to each entry in account/rateLimits/read:

{
  "rateLimitsByLimitId": {
    "codex_bengalfox": {
      "limitId": "codex_bengalfox",
      "limitName": "GPT-5.3-Codex-Spark",
      "appliesToModels": ["gpt-5.3-codex-spark"],
      "primary": { "usedPercent": 25, "resetsAt": 1730947200 }
    }
  }
}

The exact schema is open for discussion. The important requirement is that clients can join the model catalog to quota snapshots without private endpoint knowledge or hard-coded bucket names.

Expected behavior

• Existing rateLimits and rateLimitsByLimitId fields remain backward compatible.
• Every selectable ChatGPT-authenticated model can be associated with its effective shared and/or model-specific quota buckets.
• Shared buckets identify all applicable models, or the model catalog explicitly references the shared bucket.
• Unknown or unavailable mappings are represented explicitly rather than inferred from display names.
• Desktop, IDE, CLI, and custom app-server clients can show the correct remaining quota and reset time before model selection.
• Reading the mapping does not consume model quota.

Why this is useful

This enables accurate model pickers, low-quota warnings, quota-aware fallback, and agent safety policies while keeping rate-limit accounting and model routing owned by Codex.

Additional information

Existing foundation:

• account/rateLimits/read already exposes structured snapshots and rateLimitsByLimitId.
• codex-rs/app-server/src/request_processors/account_processor.rs indexes backend snapshots by limit_id.
• The TUI already forwards additional snapshots from rateLimitsByLimitId.

Related but not duplicate:

• #20310 requests CLI/SDK access to usage status.
• #24927 requests agent-accessible quota safety policies.
• #23150 and #33216 demonstrate the model-specific Spark bucket and the need to distinguish it from the shared Codex bucket.

This request is specifically for a supported model ID ↔ quota bucket mapping.