[Feature]: Show Mistral API and Vibe budget usage from /v1/billing/budget

Aperta
  • Qualcosa non va?
#8,290 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.

  • #8295 di @lidge-jun — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
56/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
api, backend

Direzione di ricerca

Start with src/providers/quota/vendor-probes-key.ts and src/providers/mistral-transport.ts, then inspect how existing key probes cache results and how their quota data reaches the dashboard and provider quota report. Implement the two Mistral billing requests and the distinct 402 quota state; verify both budget windows, plan label, reset times, and unavailable handling for zero budgets or missing permission.

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

Descrizione

enhancement provider
Area

Provider adapters

What are you trying to accomplish?

See how much of my Mistral plan is left (API budget and Vibe Code budget, with reset date and plan name) in the dashboard quota bar and provider quota report, the same way OpenRouter, DeepSeek, Moonshot, Z.ai and MiniMax keys already show a balance.

What prevents this today?

The Mistral provider has no quota probe. src/providers/mistral-transport.ts reads x-ratelimit-*-minute/-month headers only to classify a 429 as temporary vs unknown; nothing surfaces remaining budget, so a plan key (for example one created from Vibe Code CLI) silently hits its monthly budget and then fails with 402.

What should OpenCodex do?

Add a key-scoped Mistral quota probe in src/providers/quota/vendor-probes-key.ts (canonical https://api.mistral.ai base URL only):

  1. GET https://api.mistral.ai/v1/billing/budget with the configured key (x-api-key or Authorization: Bearer, both verified to return 200 with a standard inference key on 2026-11-07). Response shape: {api_budget, vibe_budget} where each is {usage_percentage (0-100), initial_budget, currency|null, reset_at (ISO), payg_enabled}, plus top-level mirror fields.
  2. GET /v1/billing/subscription for plan_name (FREE / INDIVIDUAL / EDU / TEAM), payg_enabled, vibe_payg_enabled, enterprise, cached with the budget.
  3. Render two windows: "API budget" and "Vibe budget", each as percent used with reset time and the currency amount (usage_percentage × initial_budget of initial_budget). Label the plan. When initial_budget is 0 or the currency is null, show the window as unknown, never as 0% left.
  4. Cache like the other key probes (about 5 minutes, manual refresh), treat 401/403 (missing see_org_inference_usage permission) as "quota unavailable for this key", and never log the key.
  5. Map Mistral 402 responses to an out-of-budget quota state distinct from 429 rate limiting.
Example usage or interface

Dashboard Providers / quota bar: Mistral API 0% · Vibe 2% (resets Dec 1) · Education. ocx provider quota report shows the same two windows.

Alternatives or workarounds

The Admin API (/v1/admin/usage, /spend-limit, /rate-limit) is Enterprise-only and rejects standard keys. Console routes under admin.mistral.ai/api/billing/v2/* need a browser session cookie and already drifted once. X-RateLimit-Remaining is documented only in prose, is absent from the OpenAPI spec, and covers per-minute limits, not the plan budget.

Additional context

Sources: Mistral OpenAPI spec https://docs.mistral.ai/openapi.yaml (billing_api_public_get_budget, billing_api_public_get_subscription, security DashboardContextAuth); 402-on-exhausted-balance in https://docs.mistral.ai/admin/billing-usage/billing. Live check on 2026-11-07 with an Education plan key returned 200 with exactly the spec's fields. Prior art: CLIProxyAPI declarative quota_probe (internal/api/handlers/management/plugin_quota.go), CodexBar.

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.