Abriste Claude Code a las 9am, le diste un refactor, y al mediodía te dijo que habías alcanzado tu límite de uso. En un plan de pago. Es una de las quejas más comunes en el issue tracker de Claude Code ahora mismo, y la causa casi nunca es un error de facturación. Es la estructura de la cuota, más algunos comportamientos por defecto que la queman en silencio.
La forma más rápida de vaciar un plan de Claude Code es correr Opus en tareas rutinarias mientras tres subagentes se ramifican detrás de ti. Cada uno representa varios múltiplos del gasto de tokens que crees estar usando.
Esta es una guía de solución de problemas para el límite del plan de suscripción: el muro "Has alcanzado tu límite de uso" en Pro y Max. Si estás con una API key y recibes un 429 Rate Limit Reached, es una falla distinta con arreglos distintos.
EL DIAGNÓSTICO EN 30 SEGUNDOS
Ejecuta dos comandos y luego compara tu síntoma
Dos comandos te dicen todo. Ejéctalos, y luego compara tu síntoma con la causa de abajo.
Ejecuta estas dos comprobaciones
| # | Command | Check |
|---|---|---|
| 1 | /usage | Consumo frente al límite de sesión de 5 horas y al(s) límite(s) semanal(es) |
| 2 | /context | Qué está cargado en la ventana actual. Mira la línea "MCP tools" |
| Síntoma | Causa más probable | Arreglo más rápido |
|---|---|---|
| Límite agotado al mediodía, barra de sesión alta | Opus como modelo por defecto en tareas rutinarias | /model a Sonnet |
| Sesión al 2% pero "límite alcanzado" | Tope semanal agotado, no la sesión | Espera el reinicio de 7 días o pasa a API |
| El límite se vacía durante runs de agentes | Ramificación de subagentes (~7x tokens) | Fija subagentes a Sonnet/Haiku en el frontmatter |
| Cuota agotada antes de escribir mucho | Servidores MCP cargando definiciones enormes | /context, luego recorta servidores sin uso |
| Factura o cuota sube de noche | Loops de auto-accept / en segundo plano | Limita el effort, mata tareas en segundo plano inactivas |
Si tu uso está bajo control y solo quieres margen ahora, salta a la ruta de pago por uso. Todo lo que hay entre aquí y allá trata de hacer durar un plan.
CUÁNDO ARREGLAR, CAMBIAR O PARAR
No todo límite vale la pena combatirlo
Define tu estrategia antes de gastar una tarde optimizando. La decisión correcta depende enteramente de si estás golpeando el tope de sesión o el tope semanal.
Arréglalo en la sesión cuando
/usage muestra el tope de sesión de 5 horas al máximo durante ráfagas pesadas pero la barra semanal todavía tiene margen. Usa Sonnet por defecto, compacta con agresividad y recorta MCP. Normalmente te mantendrás dentro de la ventana de sesión después de eso.
Cambia de modelo cuando
Un único flujo de trabajo impulsado por Opus es todo el problema. Fijar los subagentes y el modelo por defecto a Sonnet a menudo duplica o triplica cuánto dura el plan, sin ningún otro cambio.
Cambia de facturación cuando
/usage muestra el tope semanal de todos los modelos agotado y el reinicio de 7 días está a días de distancia. Ninguna optimización en sesión trae de vuelta un tope semanal antes de tiempo. En ese punto o subes de nivel o pasas a pago por uso.
Deja de optimizar cuando
Ya recortaste MCP y ruteaste modelos y /usage aún se vacía rápido. Tu volumen real superó el plan, y la ruta de pago por uso es la respuesta.
Comprobación rápida
Si tu tasa de errores y reintentos es baja y solo golpeas el tope durante ráfagas pesadas ocasionales, los arreglos en sesión son suficientes. Si golpeas el muro todos los días a media tarde, tienes un problema de modelo de facturación, no un problema de higiene.
POR QUÉ EL LÍMITE SE VACÍA TAN RÁPIDO
Dos topes, no uno
La razón principal por la que la gente se sorprende es que Claude Code aplica dos límites independientes, y el semanal es invisible hasta que muerde.
El límite de 5 horas es una ventana de sesión rotativa que empieza con tu primer mensaje y se reinicia cinco horas después. El límite semanal es un tope separado de 7 días, y en los planes Max hay dos: uno para todos los modelos y otro solo para Sonnet, según los propios documentos de uso de Anthropic.
Estos se reinician en relojes distintos. Un fin de semana pesado puede dejarte con tope de sesión el lunes con margen semanal de sobra, o con tope semanal con sesiones de sobra. Golpear un tope semanal bloquea el uso hasta su reinicio de 7 días incluso si tu sesión actual de cinco horas todavía tiene asignación. Esperar cinco horas no hace nada.
Otra cosa que confunde: Anthropic dejó de publicar números fijos de prompts por ventana y horas por semana. Lo que publica ahora es capacidad relativa. Max 5x ($100/mes) da 5x el uso por sesión de Pro, y Max 20x ($200/mes) da 20x. Así que no hay una cifra pública de tokens para presupuestar. Tienes que leer /usage y aprender tu propio techo.
Cómo interactúan los dos topes
primer mensaje
|
v
ventana de sesión de 5 horas empieza
|
v
¿tope de sesión? -- sí --> bloqueado hasta el reinicio de sesión (5h)
|
no
v
¿tope semanal de todos los modelos? -- sí --> bloqueado hasta el reinicio de 7 días
| (incluso con margen de sesión)
no
v
¿tope semanal solo-Sonnet? (solo planes Max)
|
sí --> Sonnet bloqueado; otros modelos pueden continuar
|
no --> sigue trabajandoSi /usage muestra tu sesión baja pero aún golpeas un muro, es el tope semanal. Hay un issue conocido de Claude Code donde la barra de sesión marca 2% mientras el límite se dispara al 32% semanal. El arreglo ahí es confiar en el número semanal, no en la barra de sesión.
LOS ESTADOS DEL LÍMITE
Qué significa cada estado
Estos no son códigos de error HTTP, son los estados de límite que Claude Code muestra. Leerlos correctamente te dice si esperar, cambiar de modelo o cambiar de facturación.
| Estado que ves | Lo que significa | Alcance | Cuándo se libera |
|---|---|---|---|
| "Has alcanzado tu límite de uso" | Tope de sesión de 5 horas alcanzado | Sesión actual, todos los modelos | En el reinicio rotativo de 5 horas |
| "Límite semanal alcanzado" | Tope de 7 días para todos los modelos alcanzado | Todos los modelos, todas las sesiones | Solo en el reinicio de 7 días |
| "Límite semanal de Sonnet alcanzado" (Max) | Tope de 7 días solo-Sonnet alcanzado | Solo Sonnet, otros modelos continúan | Solo en el reinicio de 7 días |
| "Límite alcanzado" con % de sesión bajo | Casi siempre el tope semanal disparándose | Semanal, no sesión | Solo en el reinicio de 7 días |
| Barra de sesión atascada al 100% con uso liviano | Bug de visualización conocido | Cosmético, revisa /usage por la verdad | Reinicia o confía en los números de /usage |
La trampa es la cuarta fila. La gente ve una barra de sesión fresca, lee "límite alcanzado" y abre un bug. En casi todos los casos es el tope semanal, que la barra de sesión no muestra. Ejecuta /usage y lee la línea semanal antes de asumir que algo está roto.
SÍNTOMA, CAUSA, ARREGLO
Todo el artículo en una tabla
Cada causa mapea a una sección de arreglo abajo.
| Síntoma | Causa | Arreglo |
|---|---|---|
| El plan se vacía antes del almuerzo | Opus es el modelo por defecto | Fija Sonnet como defecto con /model, reserva Opus para tareas difíciles |
| "Límite alcanzado" con sesión al 2% | Tope semanal agotado | Lee los números semanales en /usage, espera el reinicio o pasa a API |
| Se vacía más rápido durante trabajo de agentes | Los subagentes heredan Opus y corren contextos separados (~7x) | Rutea el modelo de cada subagente en su frontmatter |
| La cuota se quema antes del trabajo real | Definiciones de tools MCP ~33% de una ventana de 200k | Recorta servidores, deja que MCP Tool Search cargue en diferido |
| El contexto sigue refacturándose | Prefijo de caché invalidado a mitad de sesión | Fija tools y modelo al inicio, /compact y /clear con disciplina |
| Picos de noche | Loops de auto-accept y en segundo plano corren solos | Fija el effort por prompt, mata tareas en segundo plano inactivas |
La mayoría de los reportes de "mi límite está roto" mapean a una de estas filas. El patrón de tope semanal disparándose con sesión baja explica una gran parte de la confusión, porque la barra de sesión y el tope semanal son números distintos y solo uno de ellos es visible por defecto.
LOS ARREGLOS
Cómo hacer durar un plan
Cuatro arreglos centrales manejan la mayoría de los vaciamientos. La ruta de escalación (pago por uso + monitoreo) cubre el resto.
Arreglo 1: Usa Sonnet por defecto, reserva Opus para lo difícil
Cambiar tu modelo por defecto es la palanca más grande. Opus cuesta varias veces más por turno que Sonnet, y Sonnet más que Haiku. A tasas de API eso es Opus 4.8 a $5/$25 por millón de tokens de entrada/salida, Sonnet 4.6 a $3/$15, y Haiku 4.5 a $1/$5. La brecha real por turno es más amplia que la proporción de etiqueta una vez que se cuenta el razonamiento más pesado de Opus.
Usa Sonnet como tu defecto de trabajo y saca Opus solo para las partes genuinamente difíciles: decisiones de arquitectura, debugging complicado, cualquier cosa donde una respuesta incorrecta te cueste una hora. Usa /model para cambiar. Para la mayoría de ediciones, refactors y escritura de tests, la salida de Sonnet es difícil de distinguir y estira tu tope semanal varias veces más.
Cambia también el effort de razonamiento
El razonamiento por defecto quema aproximadamente 2x los tokens de medium para la mayoría de tareas. Fija el effort por prompt en lugar de dejarlo en un global alto, y reserva effort alto para problemas que genuinamente lo necesiten.
Arreglo 2: Evita que los subagentes quemen Opus en paralelo
La ramificación de subagentes es el vaciamiento más silencioso porque no aparece mientras escribes. Cada subagente corre sus propias peticiones de API en una ventana de contexto fresca. No hereda tu sesión, así que relee lo que necesita y factura sus propias llamadas. Los equipos de agentes pueden usar cerca de 7x los tokens de una sesión estándar. Un desarrollador que reventó Max 20x encontró que el 85% del uso venía de sesiones pesadas en subagentes.
La trampa: la mayoría de las configuraciones hacen que cada subagente herede el modelo de la sesión principal, que suele ser Opus. Así que cada worker paga precios de Opus en tareas que no necesitan calidad de Opus. Rutea cada worker explícitamente en su frontmatter:
--- name: test-writer model: sonnet # no el Opus del padre ---
Solo el ruteo de modelos corta la línea de subagentes aproximadamente 30%. Para trabajo mecánico como renombrado, ediciones repetitivas o búsqueda en docs, baja esos workers a Haiku.
El costo más sigiloso: las relecturas
Como un subagente arranca en frío, releé archivos que el padre ya cargó. Mantén los prompts de subagentes acotados para que no reescaneen medio repo. Un worker al que se le dice "arregla el test que falla en auth_test.py" lee un archivo; un worker al que se le dice "mejora la cobertura de tests" lee veinte.
Arreglo 3: Recorta los servidores MCP antes de que se coman tu ventana
Los servidores MCP te cobran antes de hacer nada. Siete servidores MCP conectados pueden consumir 67.300 tokens de definiciones de tools, lo que es 33,7% de una ventana de contexto de 200k, al inicio de la sesión. El catálogo de cada tool corre 200 a 800 tokens de prosa más esquema, multiplicado a través de aproximadamente 50 tools por servidor. Ese overhead va en cada turno, así que compone contra tu tope semanal rápido.
Audita y deshabilita
Ejecuta /context y mira la línea "MCP tools". Deshabilita cualquier servidor que no hayas usado en dos semanas. Usa configuración a nivel de proyecto para que solo carguen los servidores relevantes al repo actual.
Deja que Tool Search difiera
El MCP Tool Search de Claude Code auto-difiere la carga de tools cuando las descripciones activas de tools MCP superan el 10% del presupuesto de contexto. Después de que entra en acción, la línea "MCP tools" en /context debería caer fuerte. Confirma que funciona justo ahí.
Si corres un puñado de servidores full-time, /context es la auditoría más rápida que tienes. Un resultado común es encontrar dos o tres servidores que olvidaste que conectaste, cada uno costándote silenciosamente cinco cifras de tokens por sesión.
Arreglo 4: Mantén la caché caliente con disciplina de /compact y /clear
La higiene de contexto protege tu caché de prompt, y una caché caliente es la mayor parte de tu ahorro. El caching de prompt corta el costo de entrada cacheada drásticamente. Tasas de acierto de caché de ~90% son sanas en el TTL por defecto de 5 minutos y suben a ~97-99% en el TTL de 1 hora. Lo que lo mata: añadir o quitar un tool a mitad de sesión invalida el prefijo cacheado y fuerza una relectura completa. Fija tus tools y modelo al inicio de la sesión.
Luego gestiona la ventana deliberadamente:
/compact
Alrededor del 50% de uso o después de cada tarea discreta, para que los turnos viejos se resuman en lugar de reenviarse completos en cada turno.
/clear
Entre piezas de trabajo no relacionadas. Empezar una ventana fresca supera a arrastrar una hora de contexto rancio a una tarea nueva.
Vigila los loops de auto-accept y en segundo plano
Un loop desatendido que sigue re-prompteando puede vaciar una sesión de noche mientras duermes. Limita el effort y mata tareas en segundo plano inactivas antes de alejarte.
ARREGLOS POR NIVEL DE PLAN
Dónde debería enfocarse cada nivel primero
Los mismos vaciamientos aplican en todo plan, pero la palanca correcta cambia según subes de nivel.
Nivel Free / Pro
En Pro tienes el margen semanal más ajustado, así que la disciplina de modelos importa más. Usa Sonnet por defecto, evita la ramificación de subagentes por completo (es la forma más rápida de vaciar un tope pequeño), y corre /compact temprano. Pro tampoco puede apoyarse en Opus para trabajo rutinario sin pagarlo dos veces. Si golpeas el muro semanal aquí, o te toca Max o te toca facturación de API medida para los días pesados.
Nivel Max 5x / Max 20x
Los planes Max tienen el margen para correr subagentes, pero es justo ahí donde los usuarios de Max se queman. El único arreglo más grande específico de Max es rutea el modelo de cada subagente en el frontmatter para que dejen de heredar Opus. Max también lleva el segundo tope semanal solo-Sonnet, así que si cambias todo a Sonnet para salvar el tope de todos los modelos, mira también la línea de Sonnet en /usage. Puedes agotar el tope de Sonnet mientras el tope de todos los modelos aún tiene margen.
Nivel Team / Enterprise
En planes basados en seats, el uso saca de un pool que se reinicia en una ventana rotativa. Los arreglos aquí son organizacionales: una convención compartida de ruteo de modelos para que todo el equipo use Sonnet por defecto, una configuración de MCP recortada commiteada en el repo para que nadie cargue diez servidores, y una API key de respaldo para los días en que el pool se seca. Para equipos que golpean el techo del pool regularmente, un gateway medido te da un carril de desborde sin renegociar seats.
PATRONES DE FALLA COMUNES
Los comportamientos que vacían la cuota más rápido de lo que la gente espera
No hay historial de outages público para límites de plan porque no es un problema de servicio caído. Es un conjunto de comportamientos que se repiten.
| Patrón | Cómo se ve | Por qué vacía rápido |
|---|---|---|
| Opus por defecto | El plan se vacía a primera tarde en ediciones rutinarias | Opus cuesta varias veces Sonnet por turno |
| Ramificación de subagentes | La cuota se hunde durante runs de agentes, bien mientras escribes | Cada subagente corre su propio contexto, ~7x tokens |
| Sobrecarga de MCP | Cuota agotada antes de que empiece el trabajo real | Las definiciones de tools pueden ser ~33% de la ventana al inicio |
| Cache thrash | El uso de tokens se mantiene alto incluso en turnos chicos | Cambios de tool a mitad de sesión invalidan el prefijo cacheado |
| Límite fantasma | "Límite alcanzado" con barra de sesión casi vacía | Tope semanal disparándose, a veces un bug de visualización |
| Loop nocturno | Cuota agotada en la mañana, nadie en el teclado | Un loop de auto-accept siguió re-prompteando desatendido |
El patrón de límite fantasma explica una gran parte de la confusión, porque la barra de sesión y el tope semanal son números distintos y solo uno de ellos es visible por defecto.
EL CAMBIO DE FACTURACIÓN DE JUNIO 2026
Qué pasó en realidad
No cambió nada, pero el susto fue real y vale la pena entenderlo.
Anthropic anunció que el uso del Agent SDK y claude -p saldría de tu suscripción a un crédito mensual separado denominado en dólares facturado a tasas estándar de API: $20 para Pro, $100 para Max 5x, $200 para Max 20x, sin arrastre.
Luego, antes de la fecha efectiva del 15 de junio, Anthropic lo pausó. Esas superficies siguen sacando de tus límites de suscripción Pro y Max exactamente como antes. No hay crédito que reclamar y tus límites no cambiaron. Anthropic dice que está retrabajando el plan y dará aviso anticipado antes de cualquier revisión futura.
Lo que esto significa para ti: no reestructures tu flujo de trabajo alrededor de un pool de crédito que aún no existe. Los arreglos de arriba apuntan a los límites que realmente están vivos hoy.
| Fecha (2026) | Cambio | Estado |
|---|---|---|
| 6 de mayo | Límites de 5 horas duplicados (Pro/Max/Team/Enterprise), throttling en horas pico removido | Vigente |
| 13 de mayo | Límites semanales subidos 50% hasta el 13 de julio (promo) | Vigente, por tiempo limitado |
| 15 de junio | Agent SDK y claude -p movidos a un pool de crédito separado | Pausado, no entró en vigor |
CUANDO EL PLAN AÚN NO ES SUFICIENTE
La ruta de pago por uso
Si /usage muestra tu tope semanal agotado y no puedes esperar el reinicio, la única salida real de un techo de plan es la facturación medida.
Las suscripciones son más baratas a un volumen de herramienta primaria diaria. A esa carga los mismos tokens cuestan aproximadamente 2 a 2,5x más a tasas crudas de API que la tarifa plana de $100 de Max 5x. Pero las suscripciones te frenan en seco en el tope semanal, y el pago por uso no tiene tope semanal alguno.
Para trabajo bursty, headless o impredecible, la facturación medida gana de lejos. Un gateway compatible con OpenAI te permite apuntar Claude Code (o cualquier cliente OpenAI-SDK) a una sola key, facturada por token sin techo de plan, y cambiar entre modelos de Claude, GPT y Gemini sin juggle de cuentas de proveedor:
# apunta Claude Code a cualquier gateway compatible con OpenAI que elijas export ANTHROPIC_BASE_URL="https://your-gateway.example/v1" export ANTHROPIC_API_KEY="your-key" # Claude Code ahora factura por token, sin tope semanal
En código, el string del modelo tiene la misma forma que usarías en cualquier lado — una key, cambia a opus/gpt/gemini libremente:
client.chat.completions.create(
model="anthropic/claude-sonnet-4.6",
messages=[{"role": "user", "content": "refactoriza este módulo"}],
)El tradeoff honesto
Si eres un usuario pesado diario dentro de los límites de un plan, mantén la suscripción. La facturación medida se gana su lugar cuando tu uso es lo suficientemente picudo que nunca llegarías al valor mensual de una suscripción, o cuando sigues golpeando el muro semanal y el reinicio está demasiado lejos para esperar.
ALTERNATIVAS CUANDO ESTÁS TOPEADO
Cuando el muro semanal golpea a mitad de tarea
Las formas realistas de seguir, ordenadas por cuándo es cada una la decisión correcta.
| Opción | ¿Tope semanal? | ¿Una key, muchos modelos? | Mejor para |
|---|---|---|---|
| Gateway compatible con OpenAI (pago por uso) | No | Sí (Claude/GPT/Gemini) | Trabajo bursty, headless, multi-modelo; escapar del muro semanal |
| Anthropic Max 20x | Sí | No (solo Anthropic) | Uso pesado diario que cabe en un plan |
| API key directa de Anthropic | No | No (solo Anthropic) | Automatización solo-Anthropic, jobs de CI |
| Esperar el reinicio | n/a | n/a | Usuarios livianos cerca del final de una ventana de 7 días |
Un límite de plan no es un bug para abrir. Es un presupuesto que puedes leer. Ejecuta /usage, usa Sonnet por defecto, y el muro que golpeabas al mediodía se mueve al fin de semana.
CÓMO MONITOREAR TU USO
Tres comandos, sin herramienta externa
El punto de todo esto es no volver a sorprenderte. Tres comandos te dan todo lo que necesitas.
/usage
Tu dashboard. Revísalo al inicio de una sesión y de nuevo antes de cualquier run pesado de agentes. Lee tanto la línea de sesión como la semanal — la semanal es la que embosca a la gente.
/context
Muestra qué está cargado ahora. Si la línea "MCP tools" es grande, tienes una oportunidad de recorte antes de gastar un solo turno en trabajo real.
/cost
Reporta el valor en dólares de la sesión actual a tasas de API — la forma más rápida de sentir cuán cara es de verdad una sesión pesada en Opus.
Construye el hábito de un /usage y /context rápido al inicio de la sesión. Dos segundos de lectura previene el bloqueo antes del almuerzo que te trajo aquí.
QUÉ ENSEÑA ESTO EN REALIDAD
Un presupuesto que no puedes ver del todo es un presupuesto que no puedes planear
Los arreglos de arriba hacen durar un plan. La lección es que el límite que te muerde es el que no es visible por defecto.
Puedes leer esto de dos formas. La estrecha: cambia a Sonnet, recorta MCP, rutea subagentes, sigue. La útil: una herramienta cuyo techo real es un número semanal que no muestra por defecto te seguirá sorprendiendo hasta que construyas el hábito de leerlo.
Vemos esto en casi cada stack de IA que auditamos. Un equipo compra seats, golpea un muro semanal invisible a mitad de sprint, y culpa a un bug de facturación — cuando el problema real es que nadie leyó /usage y el modelo por defecto era Opus. El muro de límite de Claude Code es una instancia específica de un problema general: los presupuestos que no son observables no se gestionan.
Lee el número oculto
La barra de sesión es visible; el tope semanal no. El que te bloquea es el que tienes que ir a buscar. Haz de /usage un reflejo al inicio de sesión, no un post-mortem.
Los defaults son decisiones de presupuesto
Opus por defecto y subagentes heredando Opus son decisiones de gasto tomadas una vez, al instalar. Audítalos deliberadamente, no por accidente — un default que nunca revisaste es una fuga que nunca notarás hasta el muro.
Empareja la facturación con la forma del trabajo
Las suscripciones ganan para uso diario estable; la facturación medida gana para picos. El error es forzar un modelo sobre un patrón de uso al que no encaja, y luego optimizar lo equivocado.
Si tu uso te sigue sorprendiendo, el límite no está roto — tu visibilidad sobre él sí.
FAQ
Preguntas que recibimos sobre esto
¿Por qué mi límite de uso de Claude Code se agota tan rápido?+
Normalmente Opus por defecto, ramificación de subagentes, o sobrecarga de MCP. Opus cuesta varias veces más por turno que Sonnet. Los subagentes corren sus propias ventanas de contexto a aproximadamente 7x los tokens de un solo hilo. Siete servidores MCP pueden comerse un tercio de tu ventana antes de escribir. Ejecuta /usage y /context para saber cuál.
¿Cuál es la diferencia entre el límite de 5 horas y el límite semanal?+
El límite de 5 horas es una ventana de sesión rotativa. El límite semanal es un tope de 7 días, y los planes Max tienen dos (todos los modelos y solo-Sonnet). Se reinician en relojes distintos, así que puedes golpear uno con el otro abierto de par en par.
¿Golpear el límite semanal me bloquea incluso si mi sesión de 5 horas está fresca?+
Sí. El tope semanal bloquea el uso hasta su reinicio de 7 días sin importar el margen de sesión. Esperar cinco horas no ayuda.
¿Cómo reviso cuánto uso me queda?+
/usage muestra el consumo de sesión y semanal, /context muestra qué está cargado, y /cost muestra el valor en dólares de la sesión a tasas de API.
¿Cambió Anthropic la facturación de Claude Code el 15 de junio de 2026?+
No. El cambio planificado de pool de crédito del Agent SDK se pausó antes de entrar en vigor. Los límites de suscripción no cambiaron.
¿Cambiar de Opus a Sonnet hará que mi plan dure más?+
Significativamente. Opus es varias veces más caro por turno. Usa Sonnet por defecto con /model y reserva Opus para tareas difíciles.
¿Por qué dice "límite de uso alcanzado" cuando mi sesión está al 2%?+
Eso es el tope semanal disparándose, no el tope de sesión. Ocasionalmente es un bug de visualización conocido donde la barra de sesión salta a 100% con uso local bajo. Confía en los números semanales en /usage.
¿Puedo usar mi plan Claude Pro y una API key al mismo tiempo?+
Sí. Muchos desarrolladores corren con la suscripción día a día y cambian Claude Code a una API key medida los días que agotan el tope semanal, y vuelven después del reinicio. La base URL y la key son variables de entorno, así que el cambio son dos líneas.
Sobre FACTA
FACTA ayuda a startups y equipos en etapa de crecimiento a convertir IA en sistemas de producción que siguen corriendo — no demos que impresionan una vez.
Diseñamos la arquitectura alrededor de las partes que de verdad se rompen bajo uso real: controles de costo que puedes ver, ruteo de modelos que por defecto va al tier barato, facturación de respaldo, observabilidad. La infraestructura aburrida que mantiene a un sistema vivo después del lanzamiento.
Liderados por Matías Baglieri y Carolina Fogliato, nos enfocamos en una sola cosa:
Liderazgo en IA que construye. No solo aconseja.
Deja de golpear muros invisibles. Haz tu gasto en IA observable.
Cuando un tope semanal muerde a mitad de sprint y nadie lo vio venir, el problema no es el límite — es que tu gasto no es observable y tus defaults no se eligieron a propósito. FACTA diseña la capa de ruteo de modelos, control de costos y respaldo que mantiene tu stack de IA predecible entre planes, proveedores y los cambios disruptivos para los que no recibiste memo.
Explorar Automatización de IA