Gasté accidentalmente 1.5 millones de yenes en Claude: Configuración esencial para evitar un desastre de facturación con IA

Para evitar que ocurran accidentes similares.

¡Me encantaría que todos leyeran esto para que nuestros 1.5 millones de yenes tengan algún sentido!!! 🥺

Haz esto por ahora

• Establecer límites de uso mensual de la organización de Claude Team (obviamente)
• Establecer límites por servicio para Claude Code Review
• Cambiar el disparador de Claude Code Review de "por push" a "una vez"
• Si puedes transmitir los registros de transacciones de la tarjeta de crédito a un canal específico, échales un vistazo de vez en cuando (así me di cuenta esta vez)
• Implementar a fondo barreras de protección y medidas de control

Configuración del límite de uso mensual de la organización de Claude Team

Desde https://claude.ai/admin-settings/usage

En Enterprise, puedes establecer límites aún más detallados que solo mensuales, así que vale la pena aprovecharlos.

Límite por servicio de Claude Code Review

Desde https://claude.ai/admin-settings/usage

Cambiar el disparador de Claude Code Review de "por push" a "una vez"

Desde https://claude.ai/admin-settings/usage

Lo que pasó

En una tranquila tarde de sábado, una sensación de inquietud recorrió la organización.

Se estaban drenando 1.5 millones de yenes en Claude Code Review. 😇

Por qué pasó

Para ir al grano, estaba ocurriendo lo siguiente:

Claude Code Review se ejecuta

↓

Se añaden comentarios de revisión

↓

El agente de IA (Codex/Claude, etc.) determina si es necesario corregir

↓

El agente de IA corrige y hace commit/push si es necesario

↓

Claude Code Review se ejecuta de nuevo al recibir el push

↓

El rebase/force push se propaga a los Stacked PRs siguientes

↓

Claude Code Review también se ejecuta en los PRs siguientes

↓

Se repite hasta el infinito ♾️

En el repositorio que estamos desarrollando, hemos introducido Claude Code Review, que revisa automáticamente el código de los PRs de GitHub. Además, esta vez estábamos usando agentes de IA para manejar cambios relativamente grandes dividiéndolos en múltiples PRs y apilándolos linealmente de upstream a downstream. (A esta serie de PRs se le llama Stacked PR). Además, Claude Code Review es un servicio de pago por uso basado en el consumo de tokens.

Stacked PR

feat/branch-1 (PR 1)

↓

feat/branch-2 (PR 2)

↓

feat/branch-3 (PR 3)

↓

…

↓

feat/branch-N (PR N)

Mirando hacia atrás, el costo promedio de estas revisiones fue de $25.81 por revisión 😱

Incluso en el blog oficial de Anthropic, se explica que Code Review busca revisiones profundas y será más caro que opciones ligeras como la GitHub Action de Claude Code, pero nunca imaginé que fuera tanto...

Esta vez, para hacer cambios a gran escala, creamos múltiples Stacked PRs mientras usábamos varios agentes de IA localmente. Claude Code Review se ejecuta en el momento en que se crean estos PRs. Normalmente, un humano revisaría el contenido de la revisión y decidiría si abordarlo, pero en esta ocasión, asumiendo que un humano haría la verificación final, delegamos la respuesta principal—incluyendo la decisión de si abordar la revisión—al agente de IA.

Análisis profundo del problema

1. Avanzar con funciones complejas usando múltiples Stacked PRs

Esta tarea implicaba cambios relativamente grandes. Los dividimos en múltiples PRs porque poner todo en un solo PR dificulta la revisión y hay que considerar el orden de lanzamiento. Dividir los PRs no fue el error. El problema fue que eran Stacked PRs lineales.

En los Stacked PRs, si corriges un PR upstream, los PRs downstream deben incorporar esos cambios. En otras palabras, hacer push al upstream provoca una propagación de rebase/push hacia el downstream.

Esta estructura era incompatible con la configuración de Claude Code Review que se dispara en cada push.

2. Dejar la respuesta a la revisión completamente a la IA

Como las revisiones se ejecutaban en cada push y los comentarios de revisión aumentaban, asignamos las siguientes tareas al agente de IA:

• Revisar los comentarios de revisión no resueltos
• Decidir si abordarlos o saltarlos
• Si se abordan, corregir y pasar las pruebas locales
• Hacer commit/push
• Responder a los comentarios de revisión y resolverlos
• Monitorear revisiones adicionales durante un tiempo después del push

El objetivo original era que la respuesta de la IA a las sugerencias estuviera completa para cuando yo realizara la verificación de funcionamiento y la revisión.

Si nos hubiéramos asegurado de que un humano tomara la decisión final sobre la política de respuesta a los comentarios de revisión, probablemente podríamos haberlo evitado.

3. Siguió ejecutándose incluso después del horario laboral

Estuve ejecutando y monitoreando el proceso anterior incluso después del horario laboral, pero debería haberlo detenido al menos al terminar el trabajo. Este es un punto de reflexión total.

Como usé el agente de IA local bajo suscripción, la sensación de que los costos de API estaban aumentando en ese momento era débil. Por otro lado, Claude Code Review ejecutándose en el lado de GitHub estaba consumiendo el uso de la organización de Anthropic. En la consola de Anthropic, el costo promedio para el repositorio objetivo se mostraba como $25.81/revisión. Subestimar esta sensación de costo fue también uno de los puntos de reflexión.

Creé una situación en la que la IA de pago por uso se ejecutaba durante mucho tiempo mientras había una brecha entre el costo local percibido y el costo real facturado.

Lo que salió mal

1. Tomar a la ligera la configuración de "disparar en cada push" para revisiones costosas

Esta vez, la configuración de la consola de Anthropic era que las revisiones se ejecutaran en cada push. Si bien la función de revisar en cada push es conveniente, las sugerencias pueden ser frecuentes con cada cambio, por lo que los disparadores deben considerarse cuidadosamente.

2. Juzgar mal la compatibilidad entre Stacked PRs y revisiones automáticas

Los Stacked PRs son una forma efectiva de dividir los PRs en unidades revisables. Sin embargo, corregir un PR upstream requiere un rebase de los PRs downstream. Y hacer push al PR downstream también disparaba una revisión allí. Lo que habría sido una revisión por PR se propagó a N PRs en un Stacked PR, y se ejecutaron revisiones por esa cantidad.

3. Delegar el juicio, la corrección y el push a la IA

Usar IA para organizar comentarios de revisión o correcciones locales es muy conveniente. Sin embargo, esta vez le dimos demasiada autoridad. El bucle de ver un comentario de revisión, abordarlo, hacer push y monitorear de nuevo debería haberse operado con confirmación humana explícita.

4. Hacer del límite de la organización la última línea de defensa

Como resultado, se acercó al límite de la organización, y fue ahí donde notamos la anomalía. Tener un límite en sí mismo fue bueno. Sin embargo, $10,000 era demasiado alto para una última línea de defensa. Además, debido a la influencia del uso adicional habilitado y el momento de la facturación, el costo acumulado mensual de la organización superó los $10,000 en casi un solo día. Necesitábamos barreras de protección que se detuvieran mucho antes.

Resumen

Derretí 1.5 millones de yenes en un día con Claude Code Review. Actualmente estoy enviando una solicitud de reembolso. La causa fue que, mientras Claude Code Review estaba configurado para dispararse en cada push, la combinación de correcciones/push del agente de IA y la cadena de rebase de los Stacked PRs creó un bucle de revisiones y correcciones.

Esta vez, aprovechamos demasiado la conveniencia del desarrollo impulsado por IA y descuidamos la seguridad y las barreras de protección de costos. Hasta ahora, era una fase en la que solo nos dejaban usar IA, por lo que varios agentes se proporcionaban relativamente baratos, pero creo que estamos entrando en una fase en la que nos cobrarán adecuadamente como negocio ahora que conocemos los beneficios.

Ahora estamos reinventando la organización de desarrollo para la era de la IA. https://supateam.com/ Nos aseguraremos de aprovechar esta experiencia.