Límite semanal de uso de Claude Code

• Se introdujo un límite semanal de uso para el servicio Claude Code de Anthropic
• Aplica tanto a usuarios gratuitos como de pago
• Los usuarios quedan sujetos a una restricción en la cantidad máxima de consultas o volumen de tokens procesados por semana
• La introducción del límite busca evitar el uso indebido del servicio y garantizar la estabilidad de los recursos del sistema
• Los desarrolladores y startups deben poner más atención a la gestión de recursos al usar la API

---

Resumen de la introducción del límite semanal de uso de Claude Code

Se aplica una nueva política de límite semanal de uso al servicio Claude Code ofrecido por Anthropic

• Se establece para todos los usuarios (gratuitos y de pago) un límite determinado de consultas o uso de tokens
• Este límite se introdujo para prevenir el uso indebido del servicio, ofrecer un servicio justo y asegurar la estabilidad de los recursos de infraestructura
• El límite se restablece cada semana y, si se supera, no será posible seguir usando el servicio durante esa semana

Principales impactos para desarrolladores y startups

• Aumenta la necesidad de planificar el uso al utilizar Claude Code en el desarrollo de productos
• Los servicios integrados con la API ahora requieren implementar lógica de gestión automatizada o alertas por exceso de límite
• Si se realizan generación masiva de código, análisis o llamadas repetidas, cobra mayor importancia la optimización del uso de recursos

Conclusión

• La introducción de la política de límite semanal de uso de Claude Code tiene como objetivo la sostenibilidad y la mejora de la calidad del servicio
• Las startups y los profesionales de TI necesitan verificar el límite semanal y planificar su uso al integrar sistemas existentes y diseñar servicios

[GN⁺]

Opiniones de Hacker News

• Probablemente no llegue al límite semanal, pero me inquieta que el límite sea semanal y no algo como una ventana de 36 horas.
  Si lo alcanzas, ya no puedes usarlo por el resto de la semana.
  Es incómodo quedarse tanto tiempo sin una herramienta a la que ya te acostumbraste.
  Alguien podría decir que dependo demasiado de Claude, pero lo mismo pasa con otras herramientas como ripgrep.
  No pasa nada si no puedo usarlo unos días, pero una semana es demasiado.
  Y también llama la atención que dijeran que solo afecta a “menos del 5% de los usuarios”.
  Normalmente este tipo de avisos dice que afecta a menos del 1%, pero Anthropic está diciendo que 1 de cada 20 personas va a pasarse del límite.

  • Así se siente exactamente el límite de 100 veces por semana de o3 en el plan ChatGPT Plus.
    Ni siquiera puedes saber cuánto llevas usado, y como es un recurso importante, instintivamente terminas racionándolo.
    Al final no aprovechas bien el plan y terminas usando modelos como o4-mini.
    Preferiría un límite diario.
    Aunque quizá la intención del límite semanal sea justamente hacer que la gente se contenga aunque no lo alcance.

  • Es triste ver que los desarrolladores terminen dependiendo de servicios en línea propietarios.
    Antes podías hacer todo con herramientas FOSS y no tenías que quedar atado a una empresa o servicio específico pagando una suscripción mensual.
    Ahora algunos están como agricultores de Monsanto, pagando cada mes por herramientas y olvidándose de cómo trabajar sin ellas.

  • Yo llego al límite Pro con sonnet varias veces al día, como 3 veces.
    Si uso Claude code y claude al mismo tiempo, se acaba en 30 minutos.
    Y eso sin correr multiagentes 24/7 ni tener varias ventanas abiertas.
    Ni siquiera me considero un usuario del 5% superior, pero tampoco me sorprendería quedarme sin límite el miércoles.
    Apenas estaba intentando usar más el chat de Claude, pero si no puedo confiar en que estará disponible por varios días, entonces no tiene sentido.

  • Anthropic dijo que 1 de cada 20 personas cae en el límite, pero no creo que haya tanta gente compartiendo cuentas o usando automatización 24/7.

  • Si llegas al límite, no es que no puedas usarlo durante toda esa semana; solo no puedes usarlo por el tiempo restante.
    Como tú mismo dijiste que probablemente no lo alcanzarás, si llegara a pasar sería más bien en las últimas 36 horas de la semana.
    También existe la opción de pagarlo por API.

• No sé cómo vaya a evolucionar esto a largo plazo, pero no me gusta tener que sentir cada vez que uso un LLM que estoy gastando un recurso limitado.
  La gente está acostumbrada a los planes ilimitados.
  El modelo de cobro actual se siente forzado e incómodo.

  • Lo ilimitado funciona bien para todos los servicios que son “tan baratos que no vale la pena medirlos”.
    Internet, SMS y cosas así pueden funcionar así porque su costo directo es muy bajo,
    pero los LLM todavía tienen un costo directo bastante alto cada vez que se ejecutan.

  • No estoy de acuerdo con una estructura que espera un uso constante durante todo el mes.
    Yo normalmente lo uso a lo largo del mes, pero a veces concentro varios días de sesiones de 11 horas, y en esos casos probablemente chocaría con el límite.
    Por eso usar la API directamente se siente mejor, porque el límite está dado por la profundidad de tu cartera.
    Con algo como OpenRouter también puedes esquivar las limitaciones del modelo por suscripción.
    Últimamente Gemini 2.5 Pro me está funcionando mejor que Claude para trabajo de código.
    También me da curiosidad qué otras opciones competitivas en costos hay.
    https://docs.anthropic.com/en/api/rate-limits#rate-limits

  • Mi opinión es que este tipo de herramientas debería dejar de vender acceso limitado con planes tipo “20 dólares al mes” o “200 dólares al mes” y además hacer difícil calcular los límites.
    Deberían pasar por completo a un modelo de cobro por uso; eso sí sería realmente amigable para el usuario.
    Podrían ofrecer una capa gratuita, como 20 usos gratis para probar, o una tarifa escalonada que vaya subiendo por tramos de consumo, y cobrar a los usuarios extremos según el costo real.
    Así los usuarios de bajo consumo podrían usarlo barato y al mismo tiempo ganar participación de mercado.
    Si ofrecen mejor precio que OpenRouter, la gente se quedará en ese ecosistema en lugar de irse a herramientas de terceros.
    Si la herramienta es realmente buena, los usuarios se quedarán incluso con cobro por uso.
    El problema es que los proveedores quieren subsidiar a los usuarios para ganar cuota de mercado, pero al mismo tiempo bloquear los abusos y el uso extremo.
    La solución completa sería un modelo totalmente por uso, sin costo de entrada.
    Pero si hacen eso, la gente que se suscribe y usa poco podría salir perdiendo, así que supongo que al equipo comercial no le gustaría.
    Además, eso haría más fácil que la gente compare precios y se cambie de un lado a otro, sin sentirse amarrada uno o dos meses.

  • A largo plazo, creo que los LLM locales van a superar a los mejores LLM en la nube de 2025, y que el 99% del trabajo cotidiano se hará de forma ilimitada en local,
    con acceso a la nube solo para problemas realmente complejos.
    Los LLM van a volverse más eficientes, y el costo de GPU, memoria y almacenamiento va a seguir bajando y volviéndose más accesible.
    Ahora solo estamos en una etapa de transición y por eso se ve incómodo.

  • Incluso si es un recurso limitado, me parecería bien si al menos pudiera saber cuánto he usado.
    Lo incómodo es no poder ver el progreso.

• Me confunde la diferencia entre Max 5x y Max 20x.
  En mi correo dice: “la mayoría de los usuarios de Max 20x pueden usar Sonnet 4 entre 240 y 480 horas por semana, y Opus 4 entre 24 y 40 horas”.
  En el anuncio oficial dice: “la mayoría de los usuarios de Max 5x pueden usar Sonnet 4 entre 140 y 280 horas por semana, y Opus 4 entre 15 y 35 horas”.
  La verdad habría esperado que el límite fuera más del doble en proporción al precio, pero en Opus 4 solo hay una diferencia de 5 a 9 horas.
  ¿No debería ser al menos el doble, si cuesta el doble?

  • Si de verdad es así, me bajo de Max 20x al plan más bajo de inmediato.
    En Australia estoy pagando 350 dólares al mes.

  • Yo me cambié a 20x porque siempre chocaba con el límite de Opus, y ahora resulta que casi no hay diferencia entre 20x y 5x.

  • Por eso dejé de usar MAX y bajé a Pro, y uso o3 y otros modelos por API.
    Al principio no necesito tantas horas, así que con unos 10 dólares por proyecto puedo usar o3, Gemini y Opus.
    Salen modelos nuevos cada pocos días y no quiero quedarme atado a un solo proveedor.

  • En la práctica no es que tengas el doble de uso, sino que solo te dan mayor prioridad cuando hay congestión.

  • Si el material de marketing no coincide con la realidad, ojalá alguien lo investigue con datos reales y haga una demanda colectiva.

• Entiendo que incluso pagando 200 dólares al mes quizá no sea suficiente.
  Entonces deberían ofrecer un plan lo bastante amplio para poder usarlo sin preocuparse por el límite.
  No hay nada que rompa más el flujo que un mensaje de “¡se acabó el tiempo!”.
  Hasta preferiría un sistema de créditos donde al menos pudiera ver cuánto llevo gastado y pagar más si hace falta.
  La idea de “espera mientras se enfrían las GPU” no ayuda a la productividad.
  Si corres varios agentes, “35 horas” se queda cortísimo.
  También es raro que la herramienta misma esté diseñada para fomentar ese modo de uso.

  • Si cambian a un plan suficientemente amplio para todos y aun así rentable, igual podría pasar que todos se vayan con la competencia.
    Desde un punto de vista estratégico, quizá incluso tenga sentido hacer que los usuarios dependan de la herramienta e ir subiendo el precio poco a poco.

  • No creo que “correr varios agentes” sea un caso de uso normal dentro de un plan personal.
    En esos casos siempre se ha esperado que pagues el uso por API directamente.
    Que lo permitieran dentro de un precio fijo era más bien una generosidad del servicio, y desde el principio lo anunciaron como “límites más altos”, no como “ilimitado”.

  • La API tiene límites mucho más flexibles, prácticamente casi no tiene restricciones.
    Claude también puede usarse en Aws y gcp, con límites, créditos y tarifas distintas en cada caso.

  • Hay que optimizar la política pensando en los “buenos usuarios”, no diseñarla alrededor de los “malos usuarios”.

  • Simplemente usa la API.

• Viéndolo en general, me parece un cambio positivo para proteger el sistema cuando algunos usuarios corren muchos agentes 24/7,
  y así permitir que más personas puedan seguir usándolo de forma consistente.
  Eso sí, es incómodo que no muestren “cuánto uso te queda”.
  No sé qué porcentaje llevo, pero al menos sería útil recibir avisos intermedios, por ejemplo al llegar a la mitad, para poder planear mejor.
  Que no den esa información hace pensar: “¿será que no quieren que podamos medirlo?”.
  No es que quiera llevar una contabilidad exacta; solo quiero tener una idea aproximada de dónde estoy.

• Según la cuenta de Reddit de Anthropic,
  un usuario consumió decenas de miles de dólares en LLM con un plan de $200.
  La empresa está desarrollando una solución separada para usuarios avanzados,
  pero por ahora los nuevos límites buscan una experiencia más justa y evitar compartir cuentas y la reventa.
  Por eso nosotros no podemos tener un “buen servicio”.

  • En una startup donde trabajé antes también ofrecieron una opción ilimitada.
    Al principio creíamos que nadie podría usar tanto, pero en la práctica había demasiados usuarios encontrando formas creativas de exprimir los límites del servicio.
    Había cuentas conectadas a servicios 24/7 haciendo solicitudes hasta el 95% del límite continuamente.
    Usaban muchas IP distintas e incluso aparecían patrones que claramente no parecían humanos.
    Al principio lo aceptas como casos atípicos, pero cuando esas cuentas empiezan a crecer de forma exponencial,
    resulta que en realidad había varias empresas creando múltiples cuentas para hacer balanceo de carga.
    Si miras la gráfica de ganancias y pérdidas promedio por usuario, esas cuentas solo dejan pérdidas enormes mientras consumen recursos al máximo, y al final eso obliga a cambiar la política.
    Pierdes a esos “clientes”, pero la mayoría de los usuarios normales no se ve afectada.
    De hecho, el servicio completo mejora.
    Es una experiencia por la que pasa cualquier startup de alto consumo.

  • Puede que en realidad la empresa esté vendiendo el servicio a pérdida.

  • ¿Con los límites actuales todavía no pueden frenar este abuso por cuenta? No lo entiendo bien.

  • Ayer alguien estaba presumiendo eso en Twitter.
    Dijo que había consumido $13,200 con una cuenta de $200, corriendo 4 o 5 agentes solo con Opus, 24/7, haciéndose llamadas recursivas entre sí.
    Eso claramente es abuso y sí debería ser objeto de medidas.
    Pero tampoco sé cómo se supone que un proveedor de inferencia debería frenarlo.
    Cursor ya la tiene más difícil porque añade una prima adicional sobre Anthropc/OpenAI,
    y Anthropic está en una situación parecida, solo que aquí no hay una opción premium.
    Si permites por ejemplo hasta 500 dólares de costo real mensual por 20 dólares, en la práctica estás dando un descuento del 95%, y una estructura así jamás va a aguantar.
    Seguir subsidiando eso solo hace crecer más el sentimiento de “tenemos derecho a esto” en la comunidad.
    Se siente como si te quitaran algo a lo que ya te habías acostumbrado, pero la realidad es que incluso solo por capex/opex ya no da, y si sumas I+D mantener el modelo se vuelve todavía más difícil.
    Así que en la práctica lo único que pueden hacer es “seguir cambiando la estructura de precios mientras los usuarios se van con la siguiente empresa que subsidie más generosamente”.
    Habría sido mejor presentar este tipo de política desde el principio como un trial y explicar con transparencia cuánto subsidio estaban poniendo.
    La gente probaría el modelo y algunos se quedarían; aunque otros se fueran, al menos habría menos molestia.
    Si realmente fueran transparentes con la estructura de capex, costos operativos y desarrollo,
    la gente entendería que estamos hablando de algo comparable a contratar a un senior engineer incansable.

• Este correo habría sido mucho más útil si incluyera por mes información como “en qué meses llegaste al límite” (Aug 2024, Jan 2025, May 2025, etc.).
  No tengo idea de si estoy en el 5% superior.
  De hecho, un límite para el 1% me parecería razonable, pero en SaaS un 5% ya es una porción enorme de los usuarios reales.

• Este tipo de servicios necesita una tarifa medida por consumo.
  Todas las empresas de AI están chocando con el mismo problema.
  Las suscripciones de costo fijo están diseñadas para que el usuario no piense en el costo.
  Pero una minoría muy pequeña de usuarios avanzados lleva la suscripción al límite absoluto,
  y hasta se han creado servicios como Terragon específicamente para optimizar ese tipo de uso.
  Por eso las empresas siguen bajando los límites, y los usuarios terminan preocupándose aún más por el costo.
  Cursor ya ajustó sus límites varias veces, y ahora Anthropic va por el mismo camino.
  En el fondo, ya no quieren seguir subsidiando al 10% superior de usuarios extremos.
  Ojalá existiera un plan web con cobro por uso directamente desde la interfaz.

  • La API existe, así que puedes generar tus propios tokens y usar Claude Code directamente sin necesitar un plan aparte.

  • Me recuerda a la época del hosting compartido en los años 90.

  • Si ofrecen un plan web medido por consumo, tendrían que mostrar qué tan caro es realmente dar soporte a la inferencia, y eso sería incómodo.
    Hoy por hoy, ejecutar AI a niveles de productividad reales sigue siendo extremadamente caro.

• No podemos disfrutar de un buen servicio por culpa de “patrones avanzados de uso como correr Claude 24/7 en segundo plano”.

  • Pero las empresas de AI anuncian precisamente eso: “la AI trabaja sola; el desarrollador puede tomar café o dormir mientras ella resuelve el trabajo”.
    Sí hubo desarrolladores que usaron el servicio exactamente de esa manera.
    Ahora echarles la culpa por hacerlo se siente raro.

  • Esa parte sí me dio risa.
    Suena como un “destructor benevolente del mundo” intentando acelerar un poco más la muerte térmica del universo.

  • Creo que este problema era totalmente predecible.
    Seguro que ya lo habían considerado a fondo cuando definieron el precio inicial.
    Solo que probablemente no querían retrasar el lanzamiento, así que la implementación se fue aplazando, y ahora la están aplicando para ajustarse a la realidad.

  • Sin importar cómo pongas el precio, la gente va a intentar exprimir su plan al 100%.
    Yo soy suscriptor Max y aun así me topo con el límite seguido.
    Se siente raro que me limiten incluso cuando solo estoy intentando usar lo que ya pagué.

  • Eso es exactamente lo que pasa en un experimento de precios.
    Si las restricciones son laxas, tarde o temprano aparecen usuarios extremos, la empresa vende algo como si fuera sostenible cuando no lo es, y luego termina quitando el “beneficio” más adelante.

• Tal vez sea una idea fuera de lugar, pero me puse a pensar en límites adaptativos.
  Opción 1: al principio dejarte usarlo de forma explosiva por un periodo corto y luego ir reduciendo gradualmente la velocidad, con posibilidad de volver a un pico después de un cooldown.
  Así el usuario puede tener un periodo corto de productividad máxima y el servidor también puede descansar.
  Opción 2: como los datos móviles, donde tienes cierta cantidad de solicitudes a velocidad completa y luego entras en throttling, con la opción de pagar extra si necesitas más.
  Ese modelo además generaría ingresos adicionales.
  Opción 3: asignación adaptativa de recursos en infraestructura y red.
  Las tareas que no usan GPU podrían bajar de prioridad, o procesarse más lento a nivel de red, o distribuirse entre distintos servidores según el uso con k8s y similares.
  Y más allá del debate sobre los límites, también ayudaría rastrear cuáles son las solicitudes que realmente disparan los costos, para corregir rutas de código o estructuras de infraestructura ineficientes y así recuperar margen.
  Vale la pena destacar que incluso optimizaciones pequeñas de código pueden darle muchísimo aire al sistema.