Estoy construyendo Tokamak, una app de menú bar para macOS que monitoriza tu cuota de Claude Max. Hace un par de semanas, Anthropic publicó esto en sus Terms of Service:
«You may not use OAuth or similar authorization mechanisms to allow third-party applications to access Claude on behalf of users.»
Y yo, que estoy leyendo la cuota de Claude Max usando las cookies del navegador para llamar a un endpoint no documentado, me quedé mirando la pantalla pensando: «¿Y ahora qué?»
Cómo funciona hoy (la chapuza que funciona)
Tokamak necesita saber tu porcentaje de cuota. El 42% ese que ves en claude.ai cuando llevas un rato dándole caña. El problema es que Anthropic no tiene API pública de cuota. No existe un GET /api/quota documentado con API key.
Lo que sí existe es un endpoint interno que usa la propia web de claude.ai:
GET /api/organizations/{org_id}/usage
Devuelve algo así:
{
"five_hour": { "utilization": 42, "resets_at": "2026-02-22T18:00:00Z" },
"seven_day": { "utilization": 19, "resets_at": "2026-02-28T14:59:59Z" }
}
Para llamar a ese endpoint, necesitas las cookies de sesión de un usuario logueado. Tokamak resuelve esto con un WKWebView oculto: el usuario hace login en claude.ai dentro de la app, las cookies se quedan en el WebView, y la app las usa para hacer polling cada 30 segundos.
Funciona. Lleva meses funcionando. Pero es una chapuza elegante, no una solución robusta. Estamos usando un API interno que Anthropic puede cambiar, romper o bloquear sin previo aviso.
El limbo legal
La prohibición de OAuth es clara. Pero, ¿aplica a cookies? Técnicamente no estamos usando OAuth ni «mecanismos de autorización similares». El usuario hace login directamente en claude.ai dentro de un WebView estándar. Es como abrir Safari dentro de la app.
Pero «similar authorization mechanisms» es una frase lo suficientemente ambigua como para que un abogado de Anthropic la interprete como le dé la gana. Hoy estamos en un limbo legal: no está explícitamente prohibido, pero tampoco explícitamente permitido.
Y si un día Anthropic decide que las cookies de terceros tampoco molan, nos quedamos sin datos de cuota. Así, de un día para otro.
El plan B: estimar sin API
Aquí es donde se pone interesante. La pregunta es: ¿podemos estimar tu porcentaje de cuota usando solo datos locales?
Antes de responder, necesitas entender cómo funciona la cuota de Claude Max. No es un simple contador de tokens.
La cuota es coste equivalente, no tokens
Anthropic no cuenta tokens como si fueran cacahuetes en un cuenco. Cuenta coste equivalente a precios de API. Cada token tiene un «precio» diferente según su tipo y modelo:
| Tipo de token | Peso relativo |
|---|---|
| Output (respuesta) | 5x más que input |
| Input (tu mensaje) | 1x (referencia) |
| Cache read | 0.1x (casi gratis) |
| Opus | 1.67x más que Sonnet |
Dicho en cristiano: un mensaje corto de Opus donde Claude piensa mucho y escribe una respuesta larga consume mucha más cuota que un mensaje largo tuyo a Haiku con respuesta corta.
Es como la factura de la luz. No pagas por «horas enchufado». Pagas por kWh, y el horno gasta 10x más que la bombilla del baño.
La ventana de 5 horas
La cuota no se acumula indefinidamente. Funciona como una ventana deslizante de 5 horas. Cada token que envías «caduca» exactamente 5 horas después. Si a las 10:00 quemaste un 30% de cuota con una sesión intensa, a las 15:00 ese 30% se libera.
Imagina un cubo de agua con un agujero. El agua que echas (tus mensajes) va saliendo por abajo 5 horas después. El nivel del agua es tu utilización.
Los tres componentes
Bien, sabemos que la cuota es coste equivalente y que se mueve en ventanas de 5 horas. ¿Podemos replicar eso localmente?
La respuesta honesta: no con precisión quirúrgica, pero sí con precisión útil. No vamos a clavar el 73%. Pero sí vamos a saber que estás «en zona naranja, cuidado». Y resulta que eso es exactamente lo que necesitas.
El sistema tiene tres piezas, cada una con un papel claro:
1. El Estimador (M1): el contable
Es el que hace las cuentas. Lee los ficheros locales de ~/.claude/ (que contienen todos los tokens que has enviado y recibido, con timestamps y modelo), suma el coste equivalente en las últimas 5 horas, y divide entre el «presupuesto total» del tier.
estimación = coste_en_ventana_5h / presupuesto_tier * 100
Es como llevar la cuenta de cuánta luz has gastado este mes: sabes los kWh del horno, del frigo, del ordenador. Sumas, divides entre tu tarifa, y tienes una estimación de la factura.
El problema: no sabemos el presupuesto total exacto. Anthropic no lo publica. Así que necesitamos calibrarlo. Ahí entra el segundo componente.
2. El Calibrador (A3): el que aprende mirando
Este es el más elegante. Se llama Decay Estimator y funciona así:
Cuando tú dejas de trabajar (te vas a comer, a una reunión, a dormir), los tokens que enviaste hace 5 horas empiezan a caducar. La cuota baja sola. Y como nosotros sabemos exactamente qué tokens enviamos y cuándo (están en los JSONL locales), podemos observar cuánto baja la cuota cuando esos tokens concretos caducan.
Es como el cubo de agua del ejemplo anterior: si echas un litro de agua roja y otro de agua azul, y ves que cuando sale el agua roja el nivel baja 3 marcas y cuando sale la azul baja 1 marca, ahora sabes que el agua roja pesa 3x más que la azul. Sin que nadie te lo diga. Solo observando.
Ojo al dato: esto pasa naturalmente. No consume cuota. No necesita experimentos. Cada vez que te levantas a por un café, el calibrador está aprendiendo los pesos reales de cada tipo de token.
3. El Clasificador (A5): el que traduce números a decisiones
Aquí hay un insight contraintuitivo. La primera reacción es intentar estimar el porcentaje exacto: «estás al 73%». Pero resulta que eso es matemáticamente muy difícil de hacer con precisión. La API devuelve enteros de 0 a 100, hay factores ocultos que no podemos medir, y la actividad desde otros dispositivos (claude.ai web, móvil) es invisible para nosotros.
Pero, ¿necesitas saber si estás al 73% o al 77%? No. Necesitas saber en qué zona estás:
| Zona | Rango | Significado |
|---|---|---|
| Verde | 0-60% | Tranquilo, dale caña |
| Amarilla | 60-80% | Modera, sobre todo con Opus |
| Naranja | 80-95% | Cuidado, acercándote al límite |
| Roja | 95-100% | Para o cambia a Haiku |
Clasificar en 4 zonas en vez de regresar 100 valores es mucho más fácil y mucho más útil. Si la cuota real es 72% y el clasificador dice «amarilla», acierta. Si el estimador dice «72% +-20%», el rango 52-92% cruza tres zonas y no te dice nada.
Es la diferencia entre un termómetro digital con dos decimales y un termómetro de mercurio con tres colores: frío, templado, fiebre. Para decidir si te tomas un ibuprofeno, el de tres colores te sirve igual o mejor.
El pipeline completo
graph TD
A["~/.claude/*.jsonl<br/>(tokens locales)"] --> B["Estimador M1<br/>(contable)"]
B --> |"coste equivalente<br/>en ventana 5h"| D["Clasificador A5<br/>(semáforo)"]
C["Calibrador A3<br/>(observa el decay)"] --> |"pesos reales<br/>por tipo de token"| B
E["API de cuota<br/>(mientras funcione)"] --> |"ground truth<br/>para calibrar"| F["QuotaCalibrationLog<br/>(datos pareados)"]
F --> |"calibración<br/>continua"| C
F --> |"presupuesto<br/>del tier"| B
D --> G["🟢 Verde"]
D --> H["🟡 Amarilla"]
D --> I["🟠 Naranja"]
D --> J["🔴 Roja"]
style E stroke-dasharray: 5 5
style F stroke-dasharray: 5 5
Mientras la API funciona, tenemos el dato real y simultáneamente estamos entrenando al estimador con datos pareados: «cuando tenías estos tokens locales, la API decía 42%». Acumulamos miles de estos pares. El día que la API desaparezca, el estimador ya sabe cuánto «pesa» cada tipo de token porque lo aprendió observando.
Cómo mejora la precisión con el tiempo
El truco de todo el sistema es el QuotaCalibrationLog: un registro que se guarda cada 30 segundos con dos cosas:
- Lo que dice la API (el dato real, el ground truth).
- Lo que calculamos localmente (tokens en la ventana, coste equivalente, modelo usado).
Cada registro es un punto de calibración. Con 2.880 puntos al día (uno cada 30 segundos durante las horas de uso), en dos semanas tenemos suficientes datos para:
- Calibrar el presupuesto del tier: sabemos que cuando el coste local llega a $X, la API dice 100%. Ahora conocemos $X.
- Verificar los pesos: si nuestros ratios (output 5x input, Opus 1.67x Sonnet) están mal, los datos pareados lo revelan.
- Detectar cambios de Anthropic: si un día los residuos del estimador se disparan, sabemos que la fórmula cambió. Recalibramos automáticamente.
El primer día, el estimador usa precios públicos de API como aproximación. A la semana, ya tiene pesos empíricos. Al mes, tiene un modelo bastante ajustado del comportamiento real.
Las limitaciones honestas
Sería deshonesto vender esto como una bala de plata. Hay cosas que nunca podremos capturar:
- Actividad de otros dispositivos. Si usas claude.ai desde el móvil, esos tokens consumen cuota pero son invisibles para Tokamak. El estimador subestimará.
- Factores ocultos. Si Anthropic aplica penalizaciones por hora del día, carga del servidor, o complejidad de la tarea, no podemos medirlo.
- Precisión puntual. El error del estimador ronda el +-15-25%. Para un % exacto, no es suficiente. Para saber si estás en verde, amarilla, naranja o roja, sí lo es.
Por eso el clasificador es el componente que ve el usuario, no el estimador directamente. No te decimos «estás al 73%». Te decimos «estás en zona amarilla». Y eso lo acertamos el 85-90% de las veces.
«¿Y por qué no le metes un modelo de ML?»
Si has llegado hasta aquí, probablemente estés pensando: «Tío, ¿por qué no entrenas un modelo de CoreML con los datos de calibración y listo?» Es la pregunta obvia. Y la respuesta es que sería como usar un cañón para matar un mosquito que además está detrás de un cristal blindado.
El problema es el cristal, no el cañón
Imagina el cubo de las chuches de un bar. Sabes que hay gominolas, regalices y chicles, cada uno con un «precio» diferente. Quieres saber qué porcentaje del cubo llevas comido. Pero solo puedes mirar el cubo desde fuera y el cristal distorsiona: solo distingues si está «lleno», «a medias», «casi vacío» o «vacío». No ves los caramelos individuales.
Da igual que te pongas unas gafas de 10.000€ o un microscopio electrónico. El cristal sigue distorsionando igual. Más potencia óptica no te da más información si la señal que recibes es borrosa de origen.
Eso es exactamente lo que pasa aquí:
- Un solo observable: la API devuelve un entero entre 0 y 100. Un número. Eso es toda la información que recibimos del sistema real.
- Cuantización brutal: la mayoría de observaciones consecutivas (cada 30s) tienen delta = 0. Cuando hay cambio, es de 1% o más. No hay información fina.
- 6+ incógnitas: peso de output, input, cache read, cache write, por cada modelo, más el presupuesto total, más posibles factores ocultos (GPU time, carga del servidor).
Un sistema con 6 incógnitas y 1 ecuación. Da igual que uses regresión lineal, gradient boosting, una red neuronal o un transformer. Es un problema subdeterminado. No hay suficiente información en la señal para resolver todas las incógnitas, ni con mil millones de parámetros.
Lo que gana ML vs. lo que pierde
| Regresión lineal (M1) | CoreML / Red neuronal | |
|---|---|---|
| Precisión | +-15-25% | +-15-25% (mismo techo) |
| Interpretabilidad | Total (ves cada peso) | Caja negra |
| Debugging | «El peso de output_opus está mal» | «El accuracy bajó» |
| Tamaño bundle | 0 KB | 2-5 MB framework |
| Recalibración | Cambiar un JSON | Re-entrenar + convertir .mlmodel |
| Detección de drift | Comparar residuos | Comparar… ¿qué? |
Si Anthropic cambia su fórmula de cuota mañana, con el estimador lineal ves exactamente qué residuo se ha disparado y qué peso hay que ajustar. Con un modelo de ML ves que la métrica ha bajado y tienes que re-entrenar a ciegas con los datos nuevos, esperando que converja.
La analogía del termómetro
Si tu termómetro de mercurio tiene resolución de 1°C, comprar un termómetro digital de 0.001°C no mejora la medición si lo que estás midiendo es la temperatura de un horno a través de la misma pared de cristal grueso. El cuello de botella es la pared, no el instrumento.
Aquí la «pared» es la cuantización entera + los factores ocultos + la actividad invisible de otros dispositivos. Ningún modelo, por sofisticado que sea, puede ver a través de ella.
El Phase Detector (el semáforo) funciona precisamente porque acepta esta limitación: en vez de intentar adivinar «73.2%», clasifica en 4 zonas. Y eso sí es robusto con la información disponible.
Qué estamos haciendo ahora mismo
Lo más urgente es empezar a registrar datos. Cada día sin logging es un día de calibración perdido. Así que la prioridad es:
- Ahora: implementar el QuotaCalibrationLog. Sin cambios en la UI. Solo acumular datos pareados en silencio.
- En 2-4 semanas: con datos acumulados, activar el estimador como fallback automático cuando la API falle.
- En 4+ semanas: activar el calibrador pasivo (Decay Estimator) para aprender pesos empíricos.
Si el día de mañana Anthropic cierra el grifo, el estimador ya estará calibrado y los usuarios verán un semáforo en vez de un porcentaje. No es perfecto. Pero es útil. Y es honesto sobre sus limitaciones, que ya es más de lo que se puede decir de la mayoría de dashboards por ahí.
A veces el mejor plan B es uno que empiezas a construir antes de necesitarlo.
Read this article in English.
