[{"content":"Se filtró el código fuente de Claude Code. Hubo controversia y debates interminables, pero alguien, en una sola noche, creó Claw Code y estaba acumulando estrellas de todo el mundo. Era el momento de dar lo mejor de mí.\n¡No temas! ¡Allá voy! Cuando vuelvo del trabajo ya es de noche, pero no importa. En la mano derecha un energizante, en la izquierda un café. Dormí solo cuatro horas cada noche durante dos días.\nLe encargué a Claude Code el análisis de Claw Code y, en los ratos libres, leí la documentación de análisis del código fuente.\nLeí la guía de harness engineering y se me ocurrió una idea. Pensé en construir un harness para introducir IA en el sector financiero, donde trabajo, un terreno en el que aún nadie se había lanzado.\nNo es mi área principal así que me falta conocimiento, pero lo construí igual. Sentía que tenía que crear algo, lo que fuera. (Lo voy a mejorar pronto)\n¡Ven aquí y encuentra una muerte honorable! Entonces analicé Claw Code y me di cuenta. (No leí los 1,884 archivos completos, pero) todo lo que había estado construyendo con hooks y CLAUDE.md ya estaba diseñado ahí. El sistema de gestión de permisos, el enrutamiento de herramientas, la gestión de contexto.\nLo que construí e intenté hacer eran en realidad ruedas cuadradas\u0026hellip;\nPero gracias a haber intentado hacer rodar algo cuadrado, la estructura de los archivos me resultó fácil de entender.\n¡El miedo es el mayor enemigo! En realidad hay un secreto que nunca le conté a nadie: le hablaba a la IA de usted.\n\u0026#39;인간 시대의 끝이 도래했다\u0026#39; - 블리츠크랭크 Con la ansiedad de que finalmente llegaría la era en que la IA nos dominaría, al escribir prompts usaba formas como \u0026ldquo;por favor haga\u0026hellip;\u0026rdquo;, \u0026ldquo;le solicito amablemente\u0026hellip;\u0026rdquo;. Incluso tenía un pipeline de revisión para verificar que no hubiera nada irrespetuoso antes de pulsar enter.\nPero después de ver Claw Code, cambié de opinión. Hay un system prompt, hay lógica de llamada de herramientas, hay verificación de permisos. Parsea JSON y llama APIs. Es TypeScript. Estos tipos también son código.\nGracias a eso (?) empecé a tutearla. Al descartar el pipeline de revisión, mi productividad también mejoró.\nHoy le mandé a hacer un estudio de mercado diciendo \u0026ldquo;tráeme una investigación de donde pueda copiar ideas\u0026rdquo;, y en el informe aparecía \u0026ldquo;Partes copiables\u0026rdquo;. Cuando le hablaba de usted, habría venido con un \u0026ldquo;Aspectos de referencia posibles\u0026rdquo;, pero al hablarle de tú, me respondió de tú. Muy propio de código.\n","permalink":"https://nullnull-kim.com/es/logs/2026-04-03-claude-code-leaked/","summary":"\u003cp\u003eSe filtró el código fuente de Claude Code. Hubo controversia y debates interminables, pero alguien, en una sola noche, creó \u003ca href=\"https://github.com/ultraworkers/claw-code\"\u003eClaw Code\u003c/a\u003e y estaba acumulando estrellas de todo el mundo. Era el momento de dar lo mejor de mí.\u003c/p\u003e\n\u003ch2 id=\"no-temas-allá-voy\"\u003e¡No temas! ¡Allá voy!\u003c/h2\u003e\n\u003cp\u003eCuando vuelvo del trabajo ya es de noche, pero no importa. En la mano derecha un energizante, en la izquierda un café. Dormí solo cuatro horas cada noche durante dos días.\u003c/p\u003e","title":"Se filtró el código fuente de Claude Code"},{"content":"En EP.2, usé hooks para reducir lo que Claude lee. Los resultados de tests solo mostraban fallos, los logs de build solo errores.\nDecidí medir cuánto había reducido realmente.\nPrimero medir Claude Code registra todas las conversaciones como archivos JSONL. Se acumulan por proyecto bajo ~/.claude/projects/, cada entrada contiene el uso de tokens. Construí un script (analyze-tokens.js) que lee estos datos, los cruza con archivos de sesión diarios, contabiliza turnos, cache_read/write/output por separado y lo convierte todo a costo.\nDurante la construcción encontré un bug. El hook de registro de sesión referenciaba e.usage, pero la estructura JSONL era e.message.usage. Los tokens no se estaban registrando en los archivos de sesión. El analizador lo evitó leyendo el JSONL directamente.\nAquí está el costo de un día — 27 de marzo.\nEl 58% del costo total es lectura Elemento Costo Porcentaje cache_read $19.22 58% cache_write ~$9.62 29% output ~$4.33 13% Total $33.17 cache_read es 58%. Más de la mitad del costo de Claude viene de \u0026ldquo;leer\u0026rdquo;. En EP.1 escribí \u0026ldquo;la mayor parte de lo que Claude consume es lectura, no razonamiento.\u0026rdquo; Viéndolo en números, queda claro.\n¿Qué está leyendo? Rastreé lo que Claude carga cada turno.\nElemento Cuándo se carga Tamaño CLAUDE.md del proyecto Cada turno 155–214 líneas CLAUDE.md raíz Cada turno 10 líneas MEMORY.md Cada turno Menos de 23 líneas Historial de conversación Cada turno Acumulativo Hubo un descubrimiento sorprendente. SKILL.md (469 líneas) y los documentos de agentes (1,233 líneas) no se cargan cada turno. Solo se cargan cuando se invoca un skill, solo cuando se ejecuta un agente. Ya es lazy loading.\nLo único que se carga fijo cada turno es CLAUDE.md y MEMORY.md.\nSeparar CLAUDE.md en rules/ Que CLAUDE.md tenga 155–214 líneas no significa que todo se necesite cada turno. La tabla de rutas de artefactos solo se necesita al escribir artefactos. Las reglas de dominio de juego solo se necesitan para trabajo relacionado con juegos.\nClaude Code tiene un directorio .claude/rules/. Crea un archivo ahí con frontmatter paths:, y solo se carga al acceder a esa ruta.\n--- paths: tasks/** --- Tabla de rutas de artefactos, bloques de encabezado comunes, reglas por rol... Estas reglas solo se cargan al tocar la carpeta tasks/. En conversación general no se cargan.\nLo piloté primero en un proyecto. Moví la sección de artefactos de 45 líneas a artifact-rules.md y la eliminé de CLAUDE.md. Funcionó. Lo apliqué al resto.\nProyecto CLAUDE.md (antes→después) Reducción Archivos separados A (e-commerce) 155→96 líneas 38% artifact-rules.md B (plataforma educativa) 207→140 líneas 32% artifact-rules.md, edu-rules.md C (plataforma de juegos) 214→114 líneas 47% artifact-rules.md, game-domain.md C bajó 47%. Al ser plataforma de juegos, las reglas de dominio (46 líneas) se cargaban cada turno. Ahora solo se cargan al tocar archivos relacionados con juegos.\nPero resulta que Los números no están mal. 32–47% de reducción. Se ve bien.\nPero siendo honesto, esto es \u0026ldquo;32–47% de 155–214 líneas.\u0026rdquo; Unos cientos de tokens por turno. La mayor parte de los $19.22 en cache_read no viene de las 200 líneas de CLAUDE.md — viene de la acumulación del historial de conversación. Si corres 20 turnos en una sesión, en el turno 20 los 19 turnos anteriores completos se cargan como cache_read.\nUn proyecto consumió más de la mitad del costo del día. Más de 3 veces más caro que los demás. La razón fue simple: 17 turnos en una sola sesión. El cache_read se disparó en los turnos finales.\nPor mucho que adelgaces CLAUDE.md, si no cambias cómo se acumula el historial, la mayor parte del cache_read sigue igual. EP.1 redujo la cantidad de agentes. EP.2 usó hooks para cortar output. EP.3 redujo documentos fijos. Todo trabajo significativo, pero la fuga real sigue ahí.\nCortar o continuar, esa es la cuestión Pasados 20 turnos, iniciar una nueva sesión es más eficiente para cache_read. Pero una nueva sesión significa que cache_write ocurre de nuevo. CLAUDE.md, MEMORY.md, prompt del sistema — todo se escribe desde cero.\nCortas sesiones para reducir cache_read, y cache_write sube. Mantienes sesiones para reducir cache_write, y cache_read sube. De cualquier forma hay costo.\nAún no tengo la respuesta. Alrededor de 20 turnos parece ser el punto de equilibrio, pero depende del tipo de trabajo. Trabajo de diseño con mucha conversación es mejor cortarlo pronto. Codificación continua es mejor mantenerla.\nEse es el verdadero descubrimiento de EP.3. Reduje lo que pude. Lo que queda es el dominio de \u0026ldquo;cómo usarlo.\u0026rdquo;\nOtros posts de esta serie\nEP.1 — Alcancé el Límite en Tres Horas EP.2 — Reduciendo Costos con Hooks y Subagentes Construyendo un Sistema de Alertas Discord Referencias\nClaude Code Rules Files Claude Code CLAUDE.md ","permalink":"https://nullnull-kim.com/es/logs/2026-03-30-token-ep3/","summary":"\u003cp\u003eEn \u003ca href=\"/es/logs/2026-03-28-token-ep2/\"\u003eEP.2\u003c/a\u003e, usé hooks para reducir lo que Claude lee. Los resultados de tests solo mostraban fallos, los logs de build solo errores.\u003c/p\u003e\n\u003cp\u003eDecidí medir cuánto había reducido realmente.\u003c/p\u003e\n\u003ch2 id=\"primero-medir\"\u003ePrimero medir\u003c/h2\u003e\n\u003cp\u003eClaude Code registra todas las conversaciones como archivos JSONL. Se acumulan por proyecto bajo \u003ccode\u003e~/.claude/projects/\u003c/code\u003e, cada entrada contiene el uso de tokens. Construí un script (\u003ccode\u003eanalyze-tokens.js\u003c/code\u003e) que lee estos datos, los cruza con archivos de sesión diarios, contabiliza turnos, cache_read/write/output por separado y lo convierte todo a costo.\u003c/p\u003e","title":"Claude Code Ahorro de Tokens EP.3 — Separé CLAUDE.md en rules/"},{"content":"Ahora tengo 5 proyectos. shop, blog, code_dungeon, good_game, y un root que los gestiona a todos (ese no es su nombre real). Cada proyecto corre su propia sesión de Claude. El problema es que yo soy uno solo.\nSi lanzo una tarea en shop y me paso a editar un borrador en blog, no sé cuándo terminó shop. Si inicio Phase 1 en code_dungeon y me voy a ver good_game, code_dungeon podría estar esperando confirmación de permisos y no me entero. Mirar 5 terminales en rotación no es monitoreo. Es solo dolor de ojos.\nNecesito alertas.\nPor qué Discord Webhooks Slack existe. Telegram existe. Elegí Discord. La razón es simple: puedes crear canales ilimitados gratis. Un canal por proyecto y las alertas no se mezclan. root-alerts, shop-alerts, blog-alerts, code_dungeon-alerts, good_game-alerts. Una URL de webhook por canal.\nGuardé cada URL de webhook en .claude/.discord-webhook dentro de cada proyecto. Si hardcodeas URLs en scripts, hay que editar el script cada vez que se añade un proyecto, pero con archivos separados, solo creo un nuevo archivo de webhook.\nPrimer Hook: Alerta al completar Conecté un script de notificación Discord al Stop hook. Cuando una sesión termina, envía el nombre del proyecto y la hora a Discord.\n1 2 # Capturar stdin inmediatamente (prevenir competencia de stdin con otros hooks async) INPUT=$(cat) El Stop hook se ejecuta async. Cuando múltiples hooks corren simultáneamente, no hay garantía de cuál recibe stdin. INPUT=$(cat) al inicio del script lo captura inmediatamente.\nTodas las razones de parada eran \u0026ldquo;unknown\u0026rdquo; Las alertas llegaban, pero todas decían \u0026ldquo;desconocido\u0026rdquo;. [shop] desconocido — 03-28 18:01. Sé que terminó, pero no por qué. ¿Completado normal? ¿Overflow de tokens? ¿Rechazo?\nInvestigué el payload del Stop hook. No había campo stop_reason. El JSON que Claude Code pasa a los hooks no incluye la razón de terminación de sesión.\nEncontré un rodeo. El payload tiene transcript_path — la ruta a un archivo JSONL con la transcripción completa de la sesión. Se ve así:\n{\u0026#34;type\u0026#34;:\u0026#34;user\u0026#34;,\u0026#34;message\u0026#34;:{\u0026#34;role\u0026#34;:\u0026#34;user\u0026#34;,\u0026#34;content\u0026#34;:\u0026#34;Cambia la ruta del proyecto\u0026#34;},...} {\u0026#34;type\u0026#34;:\u0026#34;assistant\u0026#34;,\u0026#34;message\u0026#34;:{\u0026#34;role\u0026#34;:\u0026#34;assistant\u0026#34;,\u0026#34;content\u0026#34;:[{\u0026#34;type\u0026#34;:\u0026#34;text\u0026#34;,\u0026#34;text\u0026#34;:\u0026#34;...\u0026#34;}],\u0026#34;stop_reason\u0026#34;:\u0026#34;end_turn\u0026#34;,...},...} Una línea por evento, y los mensajes del asistente contienen el campo stop_reason. Reescribí el script para recorrer este archivo en reversa y extraer el último stop_reason.\n1 2 3 4 5 const lines = fs.readFileSync(tp, \u0026#39;utf8\u0026#39;).split(\u0026#39;\\n\u0026#39;).filter(l =\u0026gt; l.trim()); for (let i = lines.length - 1; i \u0026gt;= 0; i--) { const e = JSON.parse(lines[i]); if (e.stop_reason) { /* lo encontré */ } } Hay 7 posibles razones de parada. Mapeé cada una a una etiqueta en español.\nstop_reason Etiqueta de alerta end_turn Completado max_tokens Token agotado model_context_window_exceeded Contexto agotado stop_sequence Secuencia de parada pause_turn Pausado refusal Rechazado tool_use Llamada a herramienta Ahora recibo alertas como [shop] Completado — 03-28 18:01 y [blog] Token agotado — 03-28 15:32.\nFiltrando alertas de sub-agentes Llegó una alerta de completado, fui a ver la terminal — seguía corriendo. Añadí logs de debug e investigué. La causa era la finalización de tareas paralelas de sub-agentes.\nUn ejemplo. Esta es la estructura de procesamiento de tareas que armé para el proyecto shop:\nSolicitud del cliente → task-orchestrator (principal) ├─ frontend-developer → Implementación UI ├─ backend-developer → Implementación API ├─ code-reviewer → Code review + verificación de rendimiento ├─ security-auditor → Auditoría de seguridad (condicional) └─ quality-gatekeeper → Verificación final Cada vez que un sub-agente termina, se dispara el Stop hook. Aunque la sesión principal no haya terminado. Si 5 sub-agentes están en una tarea, son 6 alertas. frontend-developer completado, backend-developer completado, code-reviewer completado\u0026hellip; mientras la sesión principal sigue corriendo.\nSi el payload tiene un campo agent_id, es un sub-agente. Añadí un filtro para saltar tanto alertas como borrado de heartbeat para sub-agentes.\n1 2 IS_SUBAGENT=$(echo \u0026#34;$INPUT\u0026#34; | node -e \u0026#34;...\u0026#34; 2\u0026gt;/dev/null) [ \u0026#34;$IS_SUBAGENT\u0026#34; = \u0026#34;yes\u0026#34; ] \u0026amp;\u0026amp; exit 0 Las alertas de completado no son suficientes Cuando Claude pide confirmación de permisos, pregunta por acceso de escritura, o espera input del usuario, el Stop hook no se dispara. \u0026ldquo;Esta tarea debe estar tardando,\u0026rdquo; pensé, esperé — luego revisé y llevaba decenas de minutos esperando mi respuesta.\nSegundo Hook: Alerta de espera La idea es simple. Cada vez que Claude ejecuta una herramienta, escribe un timestamp. Si el timestamp no se actualiza en 2 minutos, el proyecto se considera detenido.\nConecté un script de heartbeat al hook PostToolUse. Cada ejecución de herramienta escribe la hora actual en .claude/.heartbeat.\n1 date +%s \u0026gt; \u0026#34;$PROJECT_ROOT/.claude/.heartbeat\u0026#34; Eso es todo. Un hook de una línea.\nUn script de vigilancia separado revisa los archivos de heartbeat de los 5 proyectos cada 60 segundos. Si la última actualización fue hace más de 2 minutos, envía una alerta \u0026ldquo;en espera\u0026rdquo; a Discord. Sin re-alertas dentro de 10 minutos para el mismo proyecto. Si no, es spam de alertas.\n1 2 3 STALE_THRESHOLD=120 # 2 minutos COOLDOWN=600 # Prevención de re-alerta 10 minutos CHECK_INTERVAL=60 # Verificar cada 60 segundos Cuando una sesión termina, el Stop hook borra el archivo de heartbeat. Esto previene alertas de \u0026ldquo;en espera\u0026rdquo; para proyectos que ya terminaron.\nAhora solo llegan alertas de terminación de la sesión principal.\nConfiguración actual Dos hooks y un script de vigilancia.\nComponente Disparador Función heartbeat.sh PostToolUse Actualizar timestamp en cada ejecución de herramienta notify-discord.sh Stop Alerta Discord al terminar sesión + borrar heartbeat watcher.ps1 Intervalo 60s (siempre corriendo) Alerta \u0026ldquo;en espera\u0026rdquo; cuando heartbeat \u0026gt; 2min sin actualizar .discord-webhook — Almacenamiento de URL webhook por proyecto Añadir un proyecto nuevo toma dos pasos: poner la URL del webhook en .claude/.discord-webhook y añadir la ruta al array PROJECTS de watcher.ps1.\n5 proyectos corriendo simultáneamente. Las alertas de Discord están funcionando.\nAlgo que leí después de construir esto Hay un post llamado 50 Tips prácticos para Claude Code con este item:\n48. Reproducir sonido cuando Claude termina — Registrar un sonido del sistema via Stop Hook. Iniciar una tarea, cambiar a otro trabajo, recibir un ping cuando termina.\nSi solo trabajas en local, eso parece suficiente.\nPosts relacionados\n[Claude] (Lo que hice para ahorrar tokens) EP.1 — Agoté el límite en tres horas [Claude] (Lo que hice para ahorrar tokens) EP.2 — Hay que proteger my precious ","permalink":"https://nullnull-kim.com/es/logs/2026-03-29-discord-alert/","summary":"\u003cp\u003eAhora tengo 5 proyectos. shop, blog, code_dungeon, good_game, y un root que los gestiona a todos (ese no es su nombre real). Cada proyecto corre su propia sesión de Claude. El problema es que yo soy uno solo.\u003c/p\u003e\n\u003cp\u003eSi lanzo una tarea en shop y me paso a editar un borrador en blog, no sé cuándo terminó shop. Si inicio Phase 1 en code_dungeon y me voy a ver good_game, code_dungeon podría estar esperando confirmación de permisos y no me entero. Mirar 5 terminales en rotación no es monitoreo. Es solo dolor de ojos.\u003c/p\u003e","title":"Claude Code Alertas Discord — Sistema de monitoreo multiproyecto"},{"content":"Después de reducir a 9 agentes y poner CLAUDE.md a dieta, los intervalos entre Compacting conversation... se alargaron notablemente. Las mismas tareas, pero aguantaba mucho más que antes. Me sentí bien.\nEntonces estaba viendo la consola después de pedir una nueva funcionalidad. Los tests corrieron. 30 casos, todos pasaron. Pero Claude estaba mencionando los tests exitosos otra vez. Algo se sentía raro.\nLe pregunté a Claude. \u0026ldquo;¿Por qué mencionas otra vez los tests que ya pasaron?\u0026rdquo; Claude me explicó el concepto de herramientas. Cuando Claude ejecuta un comando de terminal o lee un archivo, todo eso son \u0026ldquo;llamadas a herramientas\u0026rdquo;. Y cada vez que una herramienta se ejecuta, su resultado completo se apila en el contexto de la conversación. Resultado de npm test — 30 líneas. Log de Hugo build — 180 líneas. Todo. Los tests pasaron todos sin nada que ver, pero leyó los 30. Para arreglar errores de build, solo necesitaba las últimas 5 líneas, pero cargó las 180.\nEl balde con fugas no era uno solo.\nY fue dicho: seguirás los hooks Mientras buscaba, descubrí los hooks de Claude Code. PreToolUse — un script que se interpone justo antes de que Claude ejecute una herramienta. Puede transformar la salida antes de que se ejecute un comando Bash, y puede bloquear una llamada Read antes de que suceda.\nAhora podía establecer mandamientos para proteger my precious.\nPrimer mandamiento: No leerás lo que tuvo éxito 30 tests pasaron todos, no hay necesidad de leerlos de nuevo. Hice un hook que filtra solo los casos fallidos y descarta el resto. (Le pedí a Claude que lo hiciera.)\n1 filtered_cmd=\u0026#34;$cmd 2\u0026gt;\u0026amp;1 | grep -A 10 -E \u0026#39;(FAIL|ERROR|✕|FAILED)\u0026#39; | head -150\u0026#34; Donde antes Claude leía los 30 resultados de tests, ahora solo ve los fallos. Si todo pasa, la cantidad de lectura es cero. 100% de lecturas innecesarias — eliminadas.\nSegundo mandamiento: No subirás lo que no sea error Log de Hugo build 180 líneas, Docker build 80 líneas — no hace falta subir todo para encontrar errores. Misma lógica: hice un hook que filtra solo ERROR, WARN, failed.\n1 2 # Hugo filtered_cmd=\u0026#34;$cmd 2\u0026gt;\u0026amp;1 | grep -E \u0026#39;(ERROR|WARN|error|failed|Fatal)\u0026#39; | head -30\u0026#34; 180 líneas se convirtieron en 5. Corté el 97%. Docker pasó de 80 líneas a unas 10.\nTercer mandamiento: No leerás lo que es inútil Hay una carpeta de archivo que ya no se usa. No hay razón para que Claude la abra mientras explora archivos. Hice un hook que intercepta llamadas a la herramienta Read y deniega cualquier ruta que contenga _archive.\n1 2 3 if [[ \u0026#34;$file_path\u0026#34; == *\u0026#34;/_archive/\u0026#34;* ]]; then # deny fi Simple, pero efectivo.\nPero hay un detalle La mejora era tangible. Compacting conversation... apareció menos frecuentemente. El contexto se mantenía mucho más ligero incluso después de ejecutar builds. Tres hooks bloqueando a Claude de leer información innecesaria.\nPero era \u0026ldquo;tangible\u0026rdquo;. No sabía exactamente cuánto había ahorrado. Hoy se sentía mejor que ayer, pero ¡no podía presumir de cuánto había cortado! ¿En qué se diferenciaba esto del EP.1, donde creí que \u0026ldquo;dividir agentes ayudaría\u0026rdquo; sin ninguna evidencia?\nSi no lo mides, no lo has mejorado. Era hora de medir de verdad.\nOtros posts de esta serie\nEP.1 — Agoté el límite en tres horas Sistema de alertas con Discord Referencias\nClaude Code Hooks Reference ","permalink":"https://nullnull-kim.com/es/logs/2026-03-28-token-ep2/","summary":"\u003cp\u003eDespués de reducir a 9 agentes y poner CLAUDE.md a dieta, los intervalos entre \u003ccode\u003eCompacting conversation...\u003c/code\u003e se alargaron notablemente. Las mismas tareas, pero aguantaba mucho más que antes. Me sentí bien.\u003c/p\u003e\n\u003cp\u003eEntonces estaba viendo la consola después de pedir una nueva funcionalidad. Los tests corrieron. 30 casos, todos pasaron. Pero Claude estaba mencionando los tests exitosos otra vez. Algo se sentía raro.\u003c/p\u003e\n\u003cp\u003eLe pregunté a Claude. \u0026ldquo;¿Por qué mencionas otra vez los tests que ya pasaron?\u0026rdquo; Claude me explicó el concepto de herramientas. Cuando Claude ejecuta un comando de terminal o lee un archivo, todo eso son \u0026ldquo;llamadas a herramientas\u0026rdquo;. Y cada vez que una herramienta se ejecuta, su resultado completo se apila en el contexto de la conversación. Resultado de npm test — 30 líneas. Log de Hugo build — 180 líneas. Todo. Los tests pasaron todos sin nada que ver, pero leyó los 30. Para arreglar errores de build, solo necesitaba las últimas 5 líneas, pero cargó las 180.\u003c/p\u003e","title":"Claude Code Ahorro de Tokens EP.2 — Reducir costos con hooks y subagents"},{"content":"Un amigo me pidió que le construyera una tienda online de cosméticos. En el trabajo solo escribía C, así que era una oportunidad para probar un stack nuevo. Toss Payments para pagos, React para el frontend. \u0026ldquo;Todos los proyectos de nueva generación en finanzas están yendo a React\u0026rdquo; — eso me rondaba la cabeza, y Toss Payments era amigable con Node. La dirección se definió rápido.\nObviamente, nunca había usado este stack. Tenía ganas, pero el plazo no daba para \u0026ldquo;estudiar primero, construir después\u0026rdquo;. Así que probé el vibe coding.\n\u0026ldquo;Hazme una tienda online para vender cosméticos, la URL de referencia es ~.\u0026rdquo; Eso fue todo, y Claude se puso a trabajar solo — salió un mockup que cubría cosas que ni había pensado. Ah, el vibe coding lleva más de un año y yo estaba completamente atrasado.\nMi plan de aprender el stack nuevo leyendo el código que Claude generaba era absurdamente ingenuo. Claude producía código mucho más rápido de lo que yo podía leerlo. Así que en vez de revisarlo yo, le pedí que se revisara a sí mismo. (El fin de la era humana parecía estar llegando.)\nDespués de un rato usando Claude, empezó a perder el hilo del contexto anterior. Busqué \u0026ldquo;context\u0026rdquo; en Google y encontré la causa. También descubrí que dividir roles en sub-agentes era la solución. Configuré cinco: pm, dba, back, front, qa. Definí todo en CLAUDE.md — reglas de rutas, guías de gestión de sesiones, todo. El uso estaba en torno al 15%. Suficiente, pensé.\nTres horas después, vi You've hit your limit · resets 3am.\nLo del reseteo a las 3am lo entendí. Lo que no entendí fue: ¿por qué en tres horas?\nLos botones estaban mal desde el principio Al configurar los 5 agentes, tenía una hipótesis equivocada: \u0026ldquo;Cuanto más piensa Claude, más tokens consume.\u0026rdquo; Sin evidencia. Solo me parecía lógico.\nLlené cada agente con reglas if-then. Si eliminaba la necesidad de que Claude razonara, el costo de inferencia bajaría — eso creía. CLAUDE.md lo llené con esa misma lógica.\nSolo después de alcanzar el límite busqué en Google. Ahí supe que estaba equivocado. La mayor parte del consumo de tokens de Claude no es inferencia — es lectura. Cada vez que un agente se ejecuta, lee CLAUDE.md completo desde el inicio. El CLAUDE.md que tan diligentemente llené se cargaba entero en el contexto, cada vez.\nComprimí las explicaciones en prosa a tablas y eliminé entradas duplicadas. La velocidad de consumo bajó.\nSi divido más, los tokens deberían bajar, ¿no? Después de la optimización, Compacting conversation... apareció menos. El contexto se mantenía bien. Me sentí bien.\nPero al mirar el consumo real de tokens, estaba perdiendo aún más.\n\u0026ldquo;Si divido los roles más fino, cada agente maneja un alcance más estrecho.\u0026rdquo; Ese fue el siguiente intento.\nPasé de 5 a 12. api-designer, ui-designer, performance-engineer, security-auditor\u0026hellip; Una estructura sistemática por etapas.\nEl contexto se mantenía bien. Pero los tokens parecían fugarse un poco más.\nFusión con lágrimas Le pedí a Claude que diagnosticara la causa. Se sentía como recibir un veredicto judicial. token.. my precious\u0026hellip;\nNúmero de agentes = número de lecturas de CLAUDE.md. Doce agentes cargándolo doce veces cada uno. Cuanto más dividía, más rápido se quemaba.\nTenía que reducir. Lo había construido con mucho esfuerzo, pero los fusioné con lágrimas en los ojos.\napi-designer absorbido por backend-developer, ui-designer por frontend-developer, performance-engineer por code-reviewer.\nElemento Antes Después Ahorro Tamaño total archivos de agentes 112KB 40KB -64% Número de agentes 12 9 -3 La velocidad de consumo cambió notablemente.\nAsí que me pasé a Max Una vez armada la estructura, realmente sentí la velocidad de Claude. Sí, cuesta dinero. Pero la velocidad de procesamiento era inimaginable. Trabajo que me habría tomado días se terminó en una sesión.\nMe pasé al plan Max. A usarlo bien, sin desperdicio.\nEl problema estructural estaba resuelto. No dejé de buscar en Google para proteger my precious. Y lo descubrí. Cuando Claude lee un archivo de 500 líneas, lee las 500. Cuando ejecuta tests, carga el resultado completo en el contexto — incluyendo los casos exitosos. No era un problema de cantidad de agentes. Era lo que Claude veía.\n¿Cómo hacer que Claude vea solo lo que necesita?\nOtros posts de esta serie\nEP.2 — Hay que proteger my precious Sistema de alertas con Discord Referencias\nCLAUDE.md — How Claude remembers your project Create custom subagents ","permalink":"https://nullnull-kim.com/es/logs/2026-03-27-token-ep1/","summary":"\u003cp\u003eUn amigo me pidió que le construyera una tienda online de cosméticos. En el trabajo solo escribía C, así que era una oportunidad para probar un stack nuevo. Toss Payments para pagos, React para el frontend. \u0026ldquo;Todos los proyectos de nueva generación en finanzas están yendo a React\u0026rdquo; — eso me rondaba la cabeza, y Toss Payments era amigable con Node. La dirección se definió rápido.\u003c/p\u003e\n\u003cp\u003eObviamente, nunca había usado este stack. Tenía ganas, pero el plazo no daba para \u0026ldquo;estudiar primero, construir después\u0026rdquo;. Así que probé el vibe coding.\u003c/p\u003e","title":"Claude Code Ahorro de Tokens EP.1 — Agoté el límite en tres horas"},{"content":" Un especialista en banca empresarial que tuvo la suerte de entrar en el sector financiero IT, gestionando sistemas para algunas de las mayores corporaciones de Corea. Recientemente empecé con el vibe coding y terminé en una guerra total contra los tokens.\nEn este blog registro prueba y error, vida cotidiana y, de vez en cuando, soluciones de LeetCode.\nGitHub: nullnull-kim Email: nullnull.kim@gmail.com Motor del blog: Hugo + PaperMod Hosting: Cloudflare ","permalink":"https://nullnull-kim.com/es/about/","summary":"about","title":"About"}]