Billing API reports a healthy account while every request 400s with insufficient credits
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 42/100
Línea de trabajo
Start by reading the /alpha/billing/credits handler and the request path that returns the insufficient credits error; the payload names no source files or tests. Compare how each path derives credit availability, then check the usage limits documentation and related issue #904. Done when the billing response gives clients a reliable signal that matches whether requests can be served, with the documented behavior aligned.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
/alpha/billing/credits reports a healthy account (belowThreshold=false, both rolling windows at 0% used) while every completion request is rejected with insufficient credits. A client that automates fallback across providers therefore has no way to tell "this account can't serve requests" — it has to send a real request to find out.
Expected Behavior
If requests are refused, one of the documented fields should reflect it:
credits.belowThreshold = true, or- a new explicit flag (
canRequest/insufficientCredits), or windowLimits.exceeded/fiveHour.exceededset.
Also, https://commandcode.ai/docs/resources/usage-limits ("What happens when I run out of credits?") says requests stop once your included credits reach zero, which suggests monthlyCredits would be 0 at that point. Here they stop at 0.084.
Actual Behavior
GET https://api.commandcode.ai/alpha/billing/credits → 200:
{
"credits": { "belowThreshold": false, "creditThreshold": 0,
"monthlyCredits": 0.0840296077, "purchasedCredits": 0, "freeCredits": 0 },
"windowLimits": { "limited": true, "exceeded": null,
"fiveHour": { "used": 0, "cap": 14, "exceeded": false, "resetAt": 0 },
"weekly": { "used": 0, "cap": 35, "exceeded": false, "resetAt": 0 } }
}
GET https://api.commandcode.ai/alpha/billing/subscriptions → 200: status: "active", planId: "individual-goat", currentPeriodEnd: "2026-11-04T14:00:31.000Z".
Any request fails, including a one-token one:
POST /provider/v1/chat/completions
{"model":"deepseek/deepseek-v4.1-flash","messages":[{"role":"user","content":"hi"}],"max_tokens":1}
HTTP 400
{"message":"You have insufficient credits to make this request. Please purchase more credits to continue using the service.",
"type":"invalid_request_error","code":"BAD_REQUEST"}
x-trace-id: ab67b7089a5a839861c5a497f5d9fe96
So belowThreshold is unusable as a signal: with creditThreshold = 0 it can only trip exactly at zero. windowLimits.limited = true is not a signal either — it is true with both windows at 0% used, and windowLimits.exceeded is null, not false.
Steps to reproduce the issue
- Use an account whose included monthly credits are almost gone (
0.084here) with no purchased credits. curl -s -H "Authorization: Bearer $KEY" https://api.commandcode.ai/alpha/billing/credits→belowThreshold: false,monthlyCredits: 0.084, windows0/14and0/35.curl -s -X POST https://api.commandcode.ai/provider/v1/chat/completions -H "Authorization: Bearer $KEY" -H "content-type: application/json" -d '{"model":"deepseek/deepseek-v4.1-flash","messages":[{"role":"user","content":"hi"}],"max_tokens":1}'→ 400insufficient credits.
Command Code Version
1.88.1 (provider-API behaviour; reproduced with plain curl, no CLI involved)
Operating System
Windows
Suggested fixes
- Add an explicit
canRequest/insufficientCreditsboolean to/alpha/billing/credits, or makebelowThresholdhonour a real minimum balance instead ofcreditThreshold = 0. - Return the required amount / remaining balance in the 400 body, and a documented error code distinct from
BAD_REQUEST. - Document
windowLimits.limitedandwindowLimits.exceeded(nullvsfalse) — clients can only guess today. - Align the "requests stop once your included credits reach zero" FAQ sentence with actual behaviour.
Related: #904 (non-interactive quota readout) is also helped by making these fields trustworthy.
- Lenguaje dominante
- Sin datos de lenguaje
- Estrellas
- 4.2k
- Forks
- 377
- Merge medio
- 1 d 3 h
- PR fusionados (30 d)
- 6
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de CommandCodeAI/command-code
-
Provider /v1/messages rejects role:"system" inside messages[] — Claude Code ≥ 2.1.154 incompatibleAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
CommandCodeAI/command-code#1085 ·
Los mantenedores suelen responder en 1 día
-
Feature request: auto-reconnect remote control (/rc) after restartPosiblemente ocupada @aliarain la tomó hace 20 días. Abiertop2
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
CommandCodeAI/command-code#992 · 1 comentario · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
CommandCodeAI/command-code#933 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
CommandCodeAI/command-code#855 ·
Los mantenedores suelen responder en 1 día
-
grep tool passes empty file type to ripgrepPosiblemente ocupada @ahmadbilaldev la tomó hace 19 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
CommandCodeAI/command-code#655 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de CommandCodeAI/command-code
Issues similares
-
feature javascript
Dificultad 2/5 1-3 horas Aptitud para principiantes 61/100
mattgodbolt/jsbeeb#1833 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
DiamondLightSource/eiger-correction#2 · 1 comentario ·
-
[kunminghu-v3] Debug SBA 32/64-bit accesses hang: missing TLWidthWidget(1) on error_xbar pathAbiertomodule: backend type: bug/reported
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
OpenXiangShan/XiangShan#6938 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
PriorityNotificationQueue::wakeUpAll() loses the wake-up for a thread that is not waiting yetPosiblemente ocupada @matejk la tomó hoy. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
pocoproject/poco#5674 ·
Los mantenedores suelen responder en 2 días