Cómo ver el saldo de crédito de tus APIs de IA sin abrir cinco paneles de control

Tres preguntas distintas detrás de una sola palabra

"Crédito" abarca tres cosas que no se comportan igual, y confundirlas es lo que te sorprende a mitad de una tarea.

Un saldo prepagado es dinero que ya pagaste, y se descuenta con cada solicitud. No se reinicia: solo baja hasta que lo recargas. DeepSeek y Moonshot funcionan así.

Una cuota del plan es una fracción de una ventana de uso: un plan de programación que te da una cantidad por cada 5 horas, por semana o por mes, y se renueva cuando la ventana se reinicia. Kimi Code, el plan de programación de MiniMax y el plan de programación GLM de Z.ai funcionan así.

Aquí un porcentaje significa algo distinto que un porcentaje de un saldo. Si una ventana se reinicia el domingo por la noche, estar al 90% el lunes a las 09:00 es una situación mucho peor que estar al 90% el domingo a las 17:00, porque el reinicio queda a casi una semana en lugar de a unas horas.

El gasto es simplemente lo que ha costado una clave hasta ahora, sin ningún tope. Es la respuesta directa cuando no hay un límite sobre el cual calcular un porcentaje, y eso es justo lo que le pasa a OpenRouter con una clave sin tope.

Qué expone realmente cada proveedor

DeepSeek publica GET https://api.deepseek.com/user/balance, que se autoriza con una clave de API normal como bearer token. Devuelve balance_infos[], una fila por moneda.

Cada fila trae total_balance (lo que realmente puedes gastar), topped_up_balance (crédito que pagaste) y granted_balance (crédito promocional), como cadenas decimales en unidades enteras de la moneda. La separación entre pagado y otorgado importa, porque el crédito otorgado suele ser el primero en vencer.

Moonshot (la Kimi Open Platform) responde GET /v1/users/me/balance en api.moonshot.ai para la plataforma internacional y en api.moonshot.cn para la de China. Devuelve available_balance junto con cash_balance y voucher_balance. Una clave pertenece a una sola plataforma y no funciona en la otra.

Una advertencia antes de construir algo encima: la respuesta no trae ningún campo de moneda. La moneda se deduce del host que respondió, CNY para el host de China y USD en los demás casos. Es una deducción, no algo que el servidor declare.

Kimi Code es una suscripción, no un monedero. GET https://api.kimi.com/coding/v1/usages devuelve una cuota de uso de 7 días y ventanas de límite de uso más cortas. La bolsa mensual de "Total usage" del sitio de Kimi sale de otro endpoint web, autenticado con cookie, así que una clave de API sola no te da esa cifra.

MiniMax usa una clave de plan de programación que empieza con sk-cp-. Llama a GET /v1/token_plan/remains en api.minimax.io para la versión global o en api.minimaxi.com para la plataforma de China. Una ruta más antigua, /v1/api/openplatform/coding_plan/remains, todavía responde en algunas cuentas. Lo que devuelve es la capacidad restante del plan por ventana, no dinero.

OpenRouter tiene un endpoint documentado y pensado justo para esto: GET https://openrouter.ai/api/v1/key devuelve los limit, limit_remaining y usage de la propia clave que hace la llamada, todos en USD. Si la clave tiene un límite de gasto, obtienes un porcentaje real.

Z.ai (y BigModel, su plataforma de China) expone la cuota del plan de programación en /api/monitor/usage/quota/limit, en api.z.ai o en open.bigmodel.cn. Este endpoint no aparece en la referencia de API publicada de Z.ai. Es el que llama el plugin de uso de código abierto de la propia Z.ai, así que es código de cliente publicado por el proveedor y no una interfaz prometida, y puede cambiar sin aviso.

Su respuesta también mezcla dos bolsas distintas: la cuota de tokens o crédito del plan, y una cuota mensual aparte que cuenta las llamadas a herramientas MCP, como la búsqueda web. No son intercambiables. Leer la segunda como si fuera la primera es una forma fácil de creer que tu plan casi se acabó cuando no es así.

Leerlos tú mismo

Para un par de ellos no necesitas ninguna herramienta. Ambos son GET simples con un bearer token, así que basta con esto en la terminal: curl -H "Authorization: Bearer $DEEPSEEK_API_KEY" https://api.deepseek.com/user/balance te da la cifra de DeepSeek y curl -H "Authorization: Bearer $OPENROUTER_API_KEY" https://openrouter.ai/api/v1/key te da la de OpenRouter.

Pasa cualquiera de los dos por jq y tendrás una función de shell que puedes asignar a un alias en un minuto. Es una buena respuesta para uno o dos proveedores.

Lo que no escala es el uso diario. Cada clave tiene que vivir en algún lugar que tu shell pueda leer, normalmente un dotfile o una variable de entorno exportada. Tienes que acordarte de ejecutarlo, y la respuesta solo está tan al día como la última vez que lo hiciste. Con los proveedores cuyos endpoints no están documentados, además mantienes un scraper sobre algo que puede cambiar sin una línea en el changelog.

La otra opción gratuita es el panel de control de cada proveedor. Siempre es el número oficial, y muestra lo que una clave de API no puede: facturas, fechas de vencimiento del crédito otorgado, desgloses por clave. Es el lugar correcto para una conciliación mensual.

Es poco práctico para "me voy a quedar sin saldo a mitad de tarea", una pregunta que haces diez veces al día y quieres responder sin salir de lo que estás haciendo.

Qué hace el Token Meter de MXterm Pro con ellos

Los seis se añadieron al Token Meter en la 1.0.22. En Configuración → Token Meter hay una fila por proveedor.

Pega una clave de API y elige una región donde el proveedor tenga varias (Moonshot internacional/China, MiniMax global/China, Z.ai global/China; las claves de Moonshot y de Z.ai solo funcionan en su propia región). Ese proveedor entra entonces al popover con su saldo, sus ventanas de cuota o su gasto, actualizado en segundo plano. El popover lista todos los proveedores que configuraste, y en Configuración → Token Meter puedes fijar uno arriba (Claude Code por defecto). Mira también la página del Token Meter y la documentación del Token Meter.

El único chip de la barra de título muestra la cuota más restringida de todas, coloreada según qué tan cerca está del límite. Por el motivo que se explicó en la primera sección, un saldo o una cifra de gasto nunca cuenta como porcentaje ni se convierte en barra. Sin ninguna cuota y sin Claude Code ni Codex instalados, el chip muestra el saldo más bajo en USD como dinero.

Cada fila indica qué antigüedad tiene su lectura y qué salió mal: clave rechazada, proveedor inaccesible, límite de solicitudes o una respuesta que no se pudo leer. Si el proveedor es inaccesible o limita la consulta, la fila conserva la última lectura buena y dice que está desactualizada, en vez de hacer pasar un número viejo por actual. Una clave rechazada o una respuesta ilegible muestra ese mensaje en su lugar.

Dónde viven las claves y qué nunca sale

Estos son los detalles, porque "lo guardamos de forma segura" no es una afirmación que nadie pueda comprobar.

Una clave pegada va al almacén de credenciales de tu propio sistema operativo. En macOS, es un elemento de Keychain que MXterm creó por su cuenta, con servicio MXterm Pro y cuenta account-usage.<provider>. La versión de Windows está preparada para usar el almacén de credenciales de Windows, pero eso está sin verificar allí. En la versión actual no se escribe en los archivos propios de la app ni en el almacenamiento del navegador.

El campo donde pegas la clave es un input no controlado, a propósito. La clave vive en ese input del DOM y en ningún otro lugar hasta que Guardar la entrega al backend, que entonces vacía el campo. El estado de la app no la contiene.

Un segundo archivo sin secretos en el directorio de datos de la app, account-usage.json, recuerda solo tres cosas por proveedor: si hay una clave guardada, sus últimos cuatro caracteres y la región. La barra de título lo consulta en cada carga, así que la app puede saber qué configuraste sin una sola llamada al almacén de credenciales. Sin nada configurado, el Token Meter no hace ninguna llamada al almacén de credenciales ni ninguna llamada de red.

En la versión actual cada clave va solo a los hosts HTTPS de su proveedor, fijados en el código de la app. No se siguen las redirecciones, así que un bearer token no puede desviarse a otro host. No hay una URL base que puedas configurar para apuntar una clave a otro lugar.

El texto de error es una categoría fija, no una respuesta cruda: "credenciales no válidas", "inaccesible", "ilegible" o "límite de solicitudes". Todos los tipos de datos que guardan un secreto muestran [redacted] cuando se imprimen para depurar. Lo único de una clave guardada que muestra la app es … más sus últimos cuatro caracteres, y solo cuando es lo bastante larga como para que cuatro caracteres no revelen nada.

Lo que deliberadamente no hace

A un medidor que lee credenciales hay que juzgarlo tanto por lo que rechaza como por sus funciones. Estas decisiones se tomaron de forma explícita.

Sin claves de administración. Una respuesta de OpenRouter que dice venir de una clave de administración o de aprovisionamiento se rechaza como inválida, porque esas claves pueden crear y eliminar claves de API. La app tampoco llama nunca al endpoint de créditos de la cuenta, que solo admite claves de administración.

Sin cookies del navegador ni credenciales guardadas por otras apps. Las únicas credenciales que se leen son las que pegaste y, solo para Kimi, el archivo de token propio de la CLI de Kimi Code: se lee, nunca se escribe, nunca se renueva, porque pertenece a la CLI.

Algunas herramientas crean un archivo de device id cuando falta. MXterm no lo hace, porque no escribe en el directorio de otro programa. Si ese archivo no está, la ruta por la CLI simplemente no está disponible y el proveedor figura como no configurado.

Sin saturar. A cada proveedor se le consulta como máximo una vez cada cinco minutos. Un 429 lo deja en pausa quince. Un 401 o un 403 lo deja en pausa hasta que cambies la credencial, en lugar de reintentar una clave rechazada con un temporizador. El sondeo de la app solo corre mientras haya al menos un proveedor configurado: una clave guardada o los archivos de credenciales de la CLI de Kimi Code.

Identidad propia, con una excepción. La app se identifica con un User-Agent que nombra a MXterm y su versión. El encabezado de origen de MiniMax lleva el nombre propio de MXterm, y OpenRouter no recibe ningún encabezado de atribución.

La excepción es la ruta de la CLI de Kimi Code. Ahí el token propio de la CLI se envía con la identidad de plataforma de la CLI (X-Msh-Platform: kimi_code_cli) y su device id, junto con la versión de MXterm.

La salvedad que conviene decir claro

El análisis de respuestas de MXterm Pro se escribió y se probó con fixtures y ejemplos de la documentación, no con respuestas reales capturadas de cada proveedor.

Así que si un proveedor renombra un campo que el parser necesita, la fila muestra "no se pudo leer la respuesta" en lugar de un número equivocado. Ese es el modo de fallo que quieres. Aun así, no tomes nada de esto como fuente contable.

Para dinero que tiene que ser exacto (una factura, un presupuesto, un contracargo), ve al panel de control del proveedor. Para "esta clave está a punto de quedarse sin saldo mientras trabajan tres agentes", una lista que se actualiza sola en la esquina de la ventana es la mejor herramienta.