[Feature]: Surface rate-limit headroom from response headers for API-key providers (OpenAI, Anthropic API, xAI, Groq, Mistral)

Aperta
  • Qualcosa non va?
#8,291 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@lidge-jun ci sta già lavorando.

Dal 7/11/2026.

  • #8297 di @lidge-jun — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend-api-design

Direzione di ricerca

Start with the provider adapter and quota bar paths, then inspect src/providers/mistral-transport.ts for existing Mistral header parsing and the Anthropic rate-limit parsing mentioned in the issue. Trace how proxied response headers and quota readings are stored and displayed. Done means timestamped per-provider, account, and model windows are shown for the listed providers, missing values stay unknown, and readings become stale after reset.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

account-pool enhancement provider
Area

Provider adapters

What are you trying to accomplish?

For API-key providers that have no balance endpoint usable with an inference key, see current rate-limit headroom (remaining requests and tokens in the current window and when it resets) in the quota bar, without OpenCodex making extra upstream calls.

What prevents this today?

OpenCodex already sees these headers on every proxied response but only uses some of them for retry classification or the Claude OAuth subscription windows. For OpenAI sk- project keys, Anthropic API keys, xAI, Groq and Mistral, the dashboard shows nothing about remaining limits, and a missing reading cannot be told apart from "no limit".

What should OpenCodex do?

Record the last seen rate-limit headers per (provider, key account, model) from responses OpenCodex already proxies and expose them as passive, timestamped quota windows:

  • OpenAI: x-ratelimit-limit/remaining/reset-requests and -tokens (reset values are durations such as 6m0s; convert to absolute time).
  • Anthropic API key: anthropic-ratelimit-requests-*, -input-tokens-*, -output-tokens-*, -tokens-* (RFC 3339 resets). Reuse the existing Anthropic header parsing where possible.
  • xAI and Groq: the OpenAI-shaped x-ratelimit-* family (Groq requests = per day, tokens = per minute), read defensively.
  • Mistral: x-ratelimit-*-minute/-month already parsed in src/providers/mistral-transport.ts.

Show each window with its age ("as of 2 min ago") and mark it stale after the reset time passes. An absent header renders as unknown, never as 0 remaining. No header values containing identifiers are logged.

Example usage or interface

Quota bar: OpenAI API req 4,980/5,000 · tok 1.9M/2M (resets 6m) · 1 min ago.

Alternatives or workarounds

Balance/spend endpoints exist but need a different credential: OpenAI Usage/Costs API (sk-admin- key), Anthropic Admin API (organization admin key, unavailable to individual accounts), xAI management key (/v1/billing/teams/{team_id}/prepaid/balance). These could be an explicit opt-in later; this issue covers the zero-credential passive signal only. Gemini API keys expose no remaining-quota header or endpoint at all (only Cloud Monitoring with GCP IAM), so Gemini stays "unknown" by design.

Additional context

Docs: OpenAI rate limits (https://platform.openai.com/docs/guides/rate-limits), Anthropic rate limits (https://docs.anthropic.com/en/api/rate-limits), Groq rate limits (https://console.groq.com/docs/rate-limits). Prior-art rule from CLIProxyAPI, CodexBar and claude-code-router: header first, endpoint second; never let a missing reading become zero.

Lingua principale
TypeScript
Stelle
16.9k
Fork
1.3k
Merge medio
20h 9m
PR unite (30g)
690

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di lidge-jun/opencodex

Tutte le issue di lidge-jun/opencodex

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.