Claude Code on KnightLi Blog

Cómo elegir planes de AI Coding: los usuarios ligeros priorizan comodidad, los intensivos necesitan flexibilidad

Sun, 10 May 2026 08:20:58 +0800

Los planes de AI Coding han cambiado muy rápido en los últimos seis meses. Muchas herramientas han pasado de un modelo de cobro por mensajes o por uso limitado a uno claramente basado en consumo, los planes baratos y generosos se han ido recortando, y algunos servicios extranjeros han añadido verificaciones de identidad, restricciones regionales y reglas de uso más estrictas.

Para un desarrollador, la pregunta ya no es solo qué modelo es el más fuerte. También importa cuánto vas a gastar cada mes, si la cuota alcanza, si la herramienta resulta cómoda de usar y si podrás cambiar sin demasiado dolor cuando un proveedor suba precios o cambie las reglas de repente.

Una conclusión bastante útil es esta: los usuarios ligeros deberían comprar comodidad, los usuarios intermedios deberían comprar relación calidad-precio y los usuarios intensivos deberían comprar flexibilidad. Cuanto más intensivo sea el uso, menos conviene atar el modelo y la herramienta dentro del mismo plan.

Cuatro cosas que conviene revisar antes de elegir un plan

Antes, al elegir un plan de AI Coding, normalmente bastaba con mirar tres cosas:

Si el modelo era lo bastante fuerte.
Si la velocidad de respuesta era estable.
Si la cuota incluida alcanzaba.

Ahora hay que añadir una cuarta: si el modelo y la herramienta se pueden separar.

El modelo aporta la capacidad de razonamiento, mientras que la herramienta gestiona contexto, edición de archivos, orquestación de Agent y experiencia de flujo de trabajo. Ambas cosas importan, pero es mejor no dejarlas completamente atadas entre sí. Por ejemplo, si te gustan los modelos de Claude, puedes usar el plan oficial o conectar la API a otras herramientas. Y si te gusta un editor o entorno Agent concreto, es preferible que pueda conectarse a varios modelos en lugar de obligarte a usar solo el suyo.

La gracia de esto no es complicarse por gusto. Es reducir riesgos. AI Coding es uno de los segmentos que cambian más rápido. Un plan que hoy parece generoso puede cambiar de precio en dos meses, y una herramienta que hoy parece cómoda puede empeorar después de un cambio en la integración con modelos. Separar modelos y herramientas te deja margen de maniobra.

Los planes extranjeros se están endureciendo

Herramientas como GitHub Copilot, Cursor, Windsurf y Claude Code siguen siendo la base de trabajo de mucha gente, pero la tendencia es cada vez más clara: mantener planes muy baratos con cuotas muy altas es más difícil, y la facturación por uso real es cada vez más común.

Cuando servicios como GitHub Copilot se apoyan más en facturación por uso, el supuesto margen de ahorro de algunos planes cae bastante. Para usuarios ligeros siguen siendo cómodos, pero para quienes usan agentes, contexto largo y tareas complejas de código con mucha frecuencia, el consumo real empieza a parecerse mucho más al coste real de API.

Cursor y Windsurf, en esencia, empaquetan capacidad de modelo dentro de una experiencia de IDE. Su punto fuerte es que funcionan bien desde el primer momento y ofrecen una experiencia de editor madura. Su punto débil es el mayor nivel de dependencia de herramienta. Cuanto más dependas de sus agentes propietarios, sus índices y sus flujos automáticos, más caro será migrar después.

Claude Code sigue siendo atractivo tanto por experiencia como por atención del ecosistema, pero las suscripciones internacionales, la verificación de identidad, las restricciones regionales y la seguridad de los servicios intermedios son riesgos que los usuarios en China necesitan valorar con cuidado. En especial, los relays de terceros pueden mezclar modelos, ser inestables, exponer datos o desaparecer, así que no son una gran base a largo plazo para trabajo importante.

Ventajas y límites de los planes nacionales

Una ventaja de muchos planes nacionales de AI Coding es que suelen ofrecerse en forma de API, lo que hace que queden menos atados a una sola herramienta. Puedes conectarlos a OpenCode, Cline, Continue, tus propios scripts o agentes internos.

El problema también es evidente: si quieres al mismo tiempo un modelo fuerte, buena velocidad y bastante cuota, hay pocos planes que cumplan todo a la vez.

La familia GLM es fuerte dentro del panorama nacional, pero en horas punta el rendimiento puede volverse inestable y las tareas pesadas acaban limitadas por velocidad. Kimi tiene buen nivel, pero sus reglas de precio y cuota hay que seguirlas de cerca, sobre todo la transparencia del límite real. Modelos como MiniMax son más amables en velocidad y cuota, lo que los hace útiles para tareas ligeras del día a día, lotes y ayuda de código no demasiado compleja, aunque pueden quedar un escalón por debajo en razonamiento de ingeniería difícil. DeepSeek puede parecer muy rentable cuando un modelo nuevo está en precio promocional, pero al acabar la promoción toca reevaluarlo con tarifa normal.

Por eso, en muchos casos, las opciones nacionales funcionan mejor como un grupo de modelos disponible para repartir trabajo según la tarea, y no como una apuesta total por un solo modelo y un solo plan.

Usuarios ligeros: elige lo que resulte cómodo y no sobrediseñes

Si solo usas AI para retocar scripts, completar documentación, explicar errores o generar herramientas pequeñas una o dos veces por semana, probablemente no necesitas una configuración complicada.

En este caso importa más la comodidad. Cursor, Windsurf, Trae, CodeBuddy, Tongyi Lingma, GitHub Copilot y herramientas similares son opciones razonables. El objetivo no es perseguir el coste unitario más bajo, sino reducir fricción: algo estable dentro de tu editor, con buenas sugerencias y fácil de revertir cuando se equivoca.

Para usuarios ligeros, construir capas de API, relays y proxys complejos solo para ahorrar un poco de dinero rara vez compensa. El tiempo, el riesgo de cuenta y el coste de depuración suelen costar más que la suscripción que te ahorras.

Usuarios intermedios: mira la relación calidad-precio, pero también la portabilidad

Si usas AI todos los días para programar, modificar proyectos, generar pruebas y preparar documentación, la cuota y el consumo real empiezan a importar mucho más.

En este caso conviene separar la herramienta principal de los modelos de respaldo. Por ejemplo, un plan cómodo de IDE puede servir para el trabajo diario, mientras que una API o plan agregador conectable a varias herramientas puede encargarse de tareas con contexto más largo o flujos de Agent más complejos.

Aquí hay tres preguntas clave:

Si se puede integrar con herramientas de terceros.
Si el consumo de tokens o cuota es visible y entendible.
Si al superar el límite se aplica throttling, degradación, corte del servicio o pura facturación por uso.

Si un plan parece barato pero solo funciona dentro de su propia herramienta, conviene contar también el coste de migrar más adelante. Si cuesta algo más pero puede conectarse a varias herramientas, puede ser mejor como base a largo plazo.

Usuarios intensivos: no bloquees modelo y herramienta juntos

Para los usuarios intensivos, la necesidad principal es la flexibilidad.

Cuando una persona o un equipo usa agentes de AI de forma intensiva todos los días, el consumo crece muy rápido. Búsquedas de repositorio, cambios con contexto largo, depuración en múltiples rondas y reparación automática de pruebas pueden multiplicar el gasto en tokens. Si en ese punto dependes de un solo plan, aparecen tres problemas con facilidad:

La cuota deja de ser suficiente de repente.
La regla de cobro cambia de forma inesperada.
Una herramienta o un modelo deja de estar disponible temporalmente.

La opción más estable es montar una estructura por capas: una herramienta Agent principal, uno o varios endpoints de modelo intercambiables, un modelo barato para tareas simples y un modelo fuerte para tareas difíciles. No conviene mandar todas las tareas pequeñas al modelo más caro, ni depender solo del más barato para las tareas críticas.

Para un usuario intensivo, que las herramientas puedan conectarse a cualquier modelo y que los modelos puedan moverse entre herramientas importa más que ahorrar unas decenas de dólares al mes. Lo realmente caro no suele ser la suscripción. Lo caro es quedar atrapado en un solo ecosistema y tener que reconstruir el flujo de trabajo después.

Una estrategia de combinación más estable

Una forma razonablemente sólida de organizarlo sería esta:

Usa un modelo de bajo coste para tareas ligeras como explicar código, escribir scripts pequeños, formatear y generar documentos simples.
Usa un modelo orientado a valor para tareas intermedias como desarrollo normal de funciones, completar pruebas y sugerencias de refactorización.
Usa un modelo fuerte para tareas difíciles como cambios de arquitectura, correcciones entre varios archivos, bugs complejos y razonamiento con contexto largo.
Mantén abierta la capa de herramientas, eligiendo soluciones que puedan conectarse por API, exportar configuración y cambiar de modelo.
Conserva un camino de respaldo, de forma que si tu plan principal cambia reglas puedas moverte rápido a otra herramienta o modelo.

Puede que no sea la configuración más barata posible, pero sí una mucho más resistente. Los precios y cuotas de AI Coding van a seguir cambiando. Lo valioso a largo plazo no es un plan que hoy parezca muy generoso, sino un flujo de trabajo portable.

Resumen

Los planes de AI Coding no deberían juzgarse solo por el precio mensual. Los usuarios ligeros deberían priorizar simplicidad y comodidad. Los usuarios intermedios deberían fijarse en cuota, consumo y capacidad de migrar. Los usuarios intensivos deberían separar modelos y herramientas para no quedar atrapados en un único ecosistema.

La idea más importante es que los planes cambian, los modelos cambian y las herramientas también. Mantener la capacidad de elegir en tus propias manos es la forma más importante de controlar costes cuando trabajas con AI Coding a largo plazo.

Claude Code duplica sus límites: Anthropic usa la expansión de cómputo con SpaceX para aliviar restricciones

Sat, 09 May 2026 10:59:48 +0800

El 6 de mayo de 2026, Anthropic anunció límites de uso más altos para Claude Code y Claude API, junto con una nueva alianza de cómputo con SpaceX. Para usuarios comunes, el cambio más directo es más capacidad usable en Claude Code. Para desarrolladores y empresas, el punto de fondo es que la capacidad de inferencia de Claude sigue creciendo.

El anuncio se puede dividir en dos partes:

Límites más altos para Claude Code y Claude API.
Nueva capacidad de cómputo desde centros de datos de SpaceX.

Qué cambió en los límites de Claude Code

Anthropic afirma que estos tres cambios entraron en vigor el día del anuncio:

El rate limit de cinco horas de Claude Code se duplicó para los planes Pro, Max, Team y Enterprise basado en asientos.
Se eliminaron las reducciones de límites en horas pico para Claude Code en cuentas Pro y Max.
Los rate limits de API para el modelo Claude Opus aumentaron de forma notable.

En la práctica, si usas Claude Code para sesiones largas de programación, análisis de repositorios, refactorización, depuración o flujos con agentes, este cambio puede reducir las veces en que una tarea se detiene antes de terminar.

Eso no significa uso ilimitado. Claude Code sigue afectado por el plan, el patrón de uso, el modelo, la longitud de la tarea, el tamaño del contexto y las políticas de la plataforma. Pero Anthropic ha ampliado claramente el margen de uso frente a los límites anteriores.

Por qué el cómputo afecta la experiencia de Claude Code

Herramientas como Claude Code consumen más recursos que un chat normal. Una sola tarea de código puede incluir:

Leer muchos archivos.
Analizar contexto largo.
Hacer varias llamadas a herramientas.
Generar, editar y revisar código.
Ejecutar pruebas repetidas veces o explicar errores.
Usar Opus para razonamiento complejo.

Detrás de esas acciones no solo hay tokens. También hay capacidad de inferencia, concurrencia y recursos de planificación. El usuario ve límites, colas o lentitud en horas pico; la plataforma ve presión entre oferta y demanda de cómputo.

Por eso es relevante que Anthropic haya unido los aumentos de límites y la alianza de cómputo en el mismo anuncio. Está indicando que mejorar Claude Code no es solo cambiar una regla del plan, sino ampliar la capacidad de inferencia del backend.

Qué aporta la alianza con SpaceX

Anthropic dice que firmó un acuerdo con SpaceX para usar toda la capacidad de cómputo del centro de datos SpaceX Colossus 1. La capacidad anunciada supera los 300 megavatios, corresponde a más de 220,000 GPU NVIDIA y estará disponible para Anthropic en un mes.

Esta capacidad adicional debería mejorar directamente la capacidad disponible para suscriptores de Claude Pro y Claude Max.

El anuncio también menciona interés en trabajar con SpaceX en cómputo de IA orbital en el futuro. Eso es más una dirección de largo plazo, distinta del aumento de límites de Claude Code que los usuarios pueden notar de inmediato.

La huella de cómputo de Anthropic está creciendo

SpaceX es solo una parte de la expansión reciente de cómputo de Anthropic. La compañía también enumera otras alianzas:

Hasta 5GW con Amazon, con cerca de 1GW de nueva capacidad prevista para finales de 2026.
5GW con Google y Broadcom, previstos para empezar a entrar en línea en 2027.
Una alianza estratégica con Microsoft y NVIDIA, que incluye 30,000 millones de dólares de capacidad en Azure.
Una inversión de 50,000 millones de dólares en infraestructura de IA en Estados Unidos con Fluidstack.

Anthropic también señala que el entrenamiento y la inferencia de Claude usarán varios tipos de hardware de IA, incluidos AWS Trainium, Google TPU y GPU NVIDIA.

La tendencia es clara: la competencia entre las principales compañías de modelos no se juega solo en nombres de modelos, benchmarks y funciones de producto. También se juega en energía, centros de datos, GPU, TPU, redes y capacidad de despliegue global.

Impacto práctico para usuarios de Claude Code

Para desarrolladores, el cambio más importante es que se duplicó el límite de cinco horas de Claude Code. Afecta escenarios como:

Lectura de repositorios grandes.
Refactorización de varios archivos.
Investigación de bugs y corrección de pruebas.
Migraciones de código y actualización de dependencias.
Tareas largas de programación con agentes.
Uso simultáneo de Claude Code en planes Team o Enterprise.

Un problema común de Claude Code era llegar al límite mientras la tarea seguía en curso. Con límites más altos, es más fácil que un agente complete una tarea completa en lugar de detenerse a mitad de camino.

Para usuarios Pro y Max, eliminar las reducciones en horas pico también es importante. Significa que la experiencia puede ser más estable durante periodos de alta demanda, con menos interrupciones por ajustes temporales.

Qué significa para usuarios de API

El anuncio también dice que los rate limits de API para Claude Opus aumentaron considerablemente. Para equipos que usan Opus en tareas difíciles, normalmente eso implica:

Mayor concurrencia.
Menos errores 429 por límite de tasa.
Mejor soporte para cargas por lotes.
Mejor encaje para contexto largo, razonamiento complejo y flujos con agentes.

Los límites concretos siguen variando por cuenta, organización, modelo y plan. Antes de desplegar en producción, conviene revisar Anthropic Console, la documentación de rate limits y los registros de errores.

Empresas y despliegue regional importan más

Anthropic también señala que sectores regulados como finanzas, salud y gobierno necesitan cada vez más infraestructura regional para cumplir requisitos de cumplimiento y residencia de datos. Por eso, parte de la expansión de capacidad se ubicará fuera de Estados Unidos, especialmente para inferencia en Asia y Europa.

Esto importa para clientes empresariales. Cuando las aplicaciones de modelos grandes entran en procesos críticos, la pregunta no es solo si el modelo funciona bien. También incluye:

Si los datos permanecen en la región requerida.
Si se cumplen requisitos regulatorios del sector.
Si hay capacidad estable en horas pico.
Si se soporta concurrencia a nivel de equipo y organización.
Si existen controles de auditoría, permisos y seguridad.

Desde esa perspectiva, la expansión de cómputo no es solo una noticia de rendimiento. También puede influir en compras y decisiones de despliegue empresarial.

Resumen

El mensaje de Anthropic es directo: las restricciones de uso de Claude Code y Claude API se están relajando porque nueva capacidad de cómputo está entrando en línea.

Para usuarios de Claude Code, lo más importante es la duplicación del límite de cinco horas y la eliminación de reducciones en horas pico para Pro y Max. Para usuarios de API y empresas, destacan el aumento de rate limits de Opus y las alianzas de cómputo a largo plazo con SpaceX, Amazon, Google, Microsoft, NVIDIA y Fluidstack.

Las herramientas de IA se parecen cada vez más a servicios de infraestructura. La calidad del modelo importa, pero la capacidad estable, el cumplimiento regional, las políticas de límites y el control de costes también determinan la experiencia.

Referencia:

Anthropic: Higher usage limits for Claude and a compute deal with SpaceX

Qué hacer si suspenden tu cuenta de Claude: límites de Claude Code y guía de apelación

Sat, 09 May 2026 10:32:12 +0800

Cuando una cuenta de Claude o Claude Code se limita de repente, se suspende justo después de pagar, pierde acceso Pro o muestra menos capacidad de uso de la esperada, muchos usuarios buscan una explicación rápida. Lo importante es no tratarlo como un simple problema técnico de “cambiar IP” o “crear otra cuenta”. Los sistemas de riesgo de cuentas suelen combinar señales como región, pago, dispositivo, comportamiento de login, contenido de uso, automatización y patrones de uso compartido.

Una forma más segura de abordarlo es identificar primero qué tipo de problema tienes: límite normal de uso, problema de pago o suscripción, autorización de Claude Code, o una acción a nivel de cuenta porque Anthropic considera que hubo incumplimiento de políticas o términos.

Primero distingue tres situaciones

La primera categoría son límites normales. Claude Pro, Max, Team, API y Claude Code tienen modelos de cuota diferentes. Horas pico, contexto largo, tareas de código y flujos con agentes pueden consumir límites más rápido. Ver “limit reached” no significa necesariamente que la cuenta esté suspendida.

La segunda categoría son problemas de suscripción o autorización. Por ejemplo, el pago puede haberse completado pero el acceso no se actualizó, una suscripción móvil puede no coincidir con la cuenta web, Claude Code puede no estar logueado correctamente, o puede quedar un ANTHROPIC_API_KEY antiguo en el entorno. Empieza revisando facturación, estado de login y configuración del cliente.

La tercera categoría sí es suspensión o terminación de cuenta. Suele verse en correos que mencionan suspension, disabled o terminated, o en un login que indica que la cuenta no está disponible. En ese caso, no conviene seguir probando con más dispositivos, redes y cuentas. Eso puede complicar las señales de riesgo.

Desencadenantes comunes

La documentación de ayuda y privacidad de Anthropic menciona áreas de riesgo como violaciones de Usage Policy, creación o uso desde regiones no admitidas, incumplimientos de términos, infracciones repetidas, acceso inusual y abuso.

En la práctica, los patrones de riesgo incluyen:

Registro, región de login y región de pago no coinciden.
Uso prolongado de proxies de datacenter, proxies compartidos o cambios frecuentes de IP.
Varias personas comparten una cuenta personal.
Logins frecuentes desde muchos dispositivos o regiones en poco tiempo.
Acceso automatizado de alta frecuencia a Claude.ai.
Uso de Claude Code como servicio compartido o punto de reventa.
Solicitudes que claramente violan las políticas de Anthropic.
Conflictos entre método de pago, dirección de facturación y región de cuenta.

La clave no es que una sola señal siempre cause suspensión. El riesgo aumenta cuando varias señales anómalas aparecen juntas.

No lo soluciones evadiendo controles de riesgo

En internet se suelen recomendar “soluciones estables” como navegadores de huella digital, reinicio de fingerprint de dispositivo, borrar carpetas locales, cambiar entornos, alinear zona horaria e idioma, o registrar otro correo. Parte de eso puede ser diagnóstico normal, pero otra parte busca claramente evadir controles de riesgo de la plataforma.

No conviene tratar “evadir el control de riesgo” como solución. Las razones son simples:

Puede violar los términos del servicio.
Puede añadir más señales de riesgo a la cuenta.
No resuelve causas raíz como pago, región o incumplimiento de política.
Si hay uso de equipo o negocio, dificulta explicar una apelación posterior.

Si tu objetivo es usar Claude de forma estable a largo plazo, la dirección correcta no es disfrazar el entorno. Es hacer que cuenta, región, pago, dispositivo y uso sean reales, coherentes y explicables.

Cómo diagnosticar límites de Claude Code

Los usuarios de Claude Code pueden empezar con:

1
2

claude --version
claude auth status

Si usas API key, confirma que la variable de entorno apunta a la cuenta correcta:

`1`	`echo $ANTHROPIC_API_KEY`

En Windows PowerShell:

`1`	`echo $env:ANTHROPIC_API_KEY`

Si has usado login web, OAuth, API keys, clientes de terceros o distintas terminales, primero unifica el método de autenticación. Alguna herramienta puede seguir usando credenciales antiguas.

También distingue dos casos:

Claude Code alcanzó el límite de uso: normalmente es cuota o suscripción.
La cuenta u organización está disabled: normalmente es un riesgo de cuenta, organización, pago o política.

Para lo primero, espera renovación de cuota o ajusta el plan. Para lo segundo, conserva capturas y correos, y usa soporte oficial o canales de apelación.

Recomendaciones compatibles para estabilidad

Para reducir la probabilidad de problemas de cuenta, empieza por lo básico:

Usa una cuenta normal en un país o región admitidos.
Mantén región de login, método de pago y facturación coherentes cuando sea posible.
Evita compartir una cuenta personal entre varias personas.
No uses una cuenta Pro/Max personal como pool API de equipo.
Evita cambios frecuentes de IP, dispositivo y navegador.
No uses clientes Claude de terceros de origen desconocido.
Evita automatización de alta frecuencia contra la interfaz web de Claude.ai.
Para negocio o equipos, prefiere Team, Enterprise o API.
Lee la Usage Policy de Anthropic y evita usos restringidos.

Si realmente necesitas usar Claude en varios dispositivos, inicia sesión normalmente. No borres entornos, cambies fingerprints ni alternes proxies de forma constante. La manipulación excesiva del entorno puede parecer anómala por sí misma.

Qué hacer tras una suspensión

Si la cuenta ya fue suspendida, procede así:

Revisa correos de Anthropic o Claude y confirma la razón o tipo de mensaje.
Deja de crear cuentas nuevas, cambiar redes y probar desde más dispositivos.
Reúne correo de cuenta, orden de suscripción, prueba de pago y contexto de uso reciente.
Si crees que fue un error, presenta appeal o contacta soporte por canales oficiales.
Explica el caso real de uso. No inventes región, identidad ni propósito.
Si hay cobro de suscripción, pregunta aparte por reembolso o gestión de suscripción.

En una apelación, cuanto más concreto seas, mejor. Explica si usaste Claude Code, cambiaste dispositivos, usaste VPN, compartiste con un equipo o conectaste herramientas de terceros. La plataforma necesita identificar la fuente de riesgo. Un “no hice nada” vago suele ayudar poco.

Afirmaciones que conviene tratar con cautela

Algunos posts o videos afirman que “fijar fingerprint evita bloqueos”, “un navegador elimina totalmente el riesgo”, “borrar una carpeta reinicia la identidad del dispositivo” o “alinear IP, zona horaria e idioma lo resuelve todo”. No conviene aceptarlo sin crítica.

Los sistemas de riesgo de plataforma suelen ser multidimensionales. No miran solo fingerprint del navegador o IP. Historial de cuenta, información de pago, política regional, contenido de uso, frecuencia de acceso, patrones de automatización, versión del cliente y llamadas API también pueden contar. Disfrazar una sola señal no equivale a estabilidad a largo plazo, y puede crear más inconsistencias.

Además, muchas “soluciones anti-bloqueo” son en realidad venta de herramientas o servicios. Lo que el usuario necesita es identificar la fuente de riesgo, usar el servicio de forma compatible y conservar evidencia para apelación, no depender de envoltorios de entorno de terceros.

Resumen

La suspensión de una cuenta Claude o la limitación de Claude Code no siempre tiene una sola causa. Puede ser cuota, suscripción, autorización, o una señal de riesgo combinada relacionada con región, pago, dispositivo, uso compartido, automatización o contenido sensible a políticas.

La clave para usar Claude de forma estable a largo plazo no es evadir controles de riesgo. Es uso compatible, información de cuenta coherente, patrones de acceso estables y planes formales para equipos. Si la cuenta se suspende, deja de manipular el entorno, conserva evidencias y usa los canales oficiales de apelación y soporte.

Referencias:

De PPT a prototipos: casos de uso de Guizang PPT Skill y Huashu Design

Sat, 09 May 2026 08:34:23 +0800

Hay dos Agent Skills de diseño creadas por desarrolladores chinos que vale la pena mirar en conjunto: guizang-ppt-skill, de Guizang, y huashu-design, de Huashu.

No son “herramientas de diseño” en el sentido tradicional. En realidad convierten un proceso de diseño, preferencias estéticas, listas de comprobación y plantillas de ingeniería en Skills que un Agent puede ejecutar. No abres una UI para arrastrar elementos poco a poco; entregas el requisito a un Agent como Claude Code, Codex o Cursor, y dejas que genere HTML, PPT, animaciones o prototipos siguiendo un flujo fijo.

El valor de estos proyectos no está en dejar que la IA improvise, sino en convertir “cómo hacer que esto no se vea mal” en un proceso.

guizang-ppt-skill: enfocado en PPT web con estilo de revista

guizang-ppt-skill, de Guizang, tiene una posición muy clara: genera PPT en HTML de archivo único con paginación horizontal, y una base visual de “revista digital x tinta electrónica”. Se parece más a un sistema de maquetación para charlas que a un framework de diseño general.

El README del repositorio enumera estas capacidades principales:

Salida HTML de archivo único, sin necesidad de build ni servidor. Se abre directamente en el navegador.
Paginación horizontal, con soporte para teclado, rueda del ratón, deslizamiento táctil, puntos inferiores e índice con ESC.
5 paletas temáticas predefinidas, incluidas Ink Classic, Indigo Porcelain, Forest Ink, Kraft Paper y Dune.
10 layouts de página, incluidos portada de apertura, separador de sección, póster de datos con número grande, texto a la izquierda e imagen a la derecha, cuadrícula de imágenes, Pipeline, pregunta de suspense, cita grande, comparación Before/After y composición mixta de texto e imagen.
Plantillas integradas, notas de componentes, esqueletos de layout, configuración de tema y listas de comprobación de calidad.

Sirve para presentaciones presenciales, charlas internas de industria, eventos privados, lanzamientos de productos de IA, demo days y decks con un estilo personal fuerte. No encaja tan bien con grandes tablas de datos, materiales de formación o edición colaborativa entre varias personas.

Este proyecto toma una buena decisión de alcance: no intenta cubrir todos los escenarios de diseño, sino que estrecha el foco a “PPT con estilo de revista”. Los colores de tema se eligen desde presets y los layouts tienen esqueletos claros. Eso reduce la probabilidad de que el Agent se desvíe.

Si a menudo necesitas convertir opiniones, observaciones de industria o contenido de lanzamiento de producto en un deck de presentación, puede ser muy práctico.

El comando de instalación también es directo:

`1`	`npx skills add https://github.com/op7418/guizang-ppt-skill --skill guizang-ppt-skill`

huashu-design: un flujo de diseño HTML-native más completo

huashu-design, de Huashu, cubre un terreno más amplio. Su objetivo no es solo hacer PPT, sino tratar HTML como un lienzo de diseño nativo y usar un Agent para generar activos de diseño entregables.

El README del repositorio enumera estas capacidades:

Prototipos clicables de App o Web.
Diapositivas HTML y exportación a PPTX editable.
Animaciones de lanzamiento de producto, MP4, GIF y versiones con música.
Comparación en paralelo de varias direcciones de diseño.
Infografías, visualización de datos y exportación a PDF, PNG y SVG.
Revisión experta en 5 dimensiones, incluidas consistencia filosófica, jerarquía visual, calidad de ejecución, funcionalidad e innovación.

La idea central es que el Agent entienda primero la marca y los materiales, y después produzca diseño de alta fidelidad. El proyecto enfatiza el Core Asset Protocol: cuando se trabaja con una marca concreta, primero hay que confirmar logo, imágenes de producto, capturas de UI, paleta de colores, tipografías y guía de marca, en lugar de adivinar de memoria.

Esto importa. Muchos diseños generados por IA parecen “diseño”, pero no parecen pertenecer a un producto o una marca real. huashu-design intenta resolver ese problema por adelantado: primero encontrar activos reales, luego diseñar.

El comando de instalación es:

`1`	`npx skills add alchaincyf/huashu-design`

Encaja mejor con quienes quieren completar una entrega de diseño más amplia desde la terminal: prototipos de producto, animaciones de lanzamiento, presentaciones, infografías y revisiones de diseño pueden procesarse dentro de un único flujo de trabajo de Agent.

La mayor diferencia entre ambos

En pocas palabras, guizang-ppt-skill es un generador de decks de presentación más estrecho y más estable; huashu-design es un sistema de diseño HTML-native más amplio y completo.

Si miramos solo PPT:

guizang-ppt-skill enfatiza más la sensación de revista, el ritmo, la maquetación y la presentación de archivo único en navegador.
huashu-design enfatiza más la capacidad de diseño general, PPTX editable, activos de marca, rutas de exportación y flujo de revisión.

Si miramos la capacidad de diseño general:

guizang-ppt-skill tiene límites más claros y sirve para crear rápido una presentación horizontal con estilo.
huashu-design es más integral y sirve para descomponer una tarea de diseño de producto o marca en prototipos, animaciones, diapositivas e infografías.

Estos dos proyectos también representan dos formas distintas de escribir Skills. El primero se parece a un conjunto muy concentrado de plantillas y restricciones estéticas; el segundo se parece al manual de trabajo de un pequeño equipo de diseño.

Por qué este tipo de Skill importa

Un problema común de los Agents es que “pueden hacerlo, pero no de forma estable”. La misma petición a veces produce una salida muy buena, y otras veces se desliza hacia gradientes morados, tarjetas redondeadas, iconos falsos y un montón de frases vacías que suenan sofisticadas.

El sentido de una Skill es añadir estabilidad. Fija cosas como:

Plantillas reutilizables.
Listas de comprobación ejecutables.
Preferencias estéticas claras.
Reglas para evitar errores comunes.
Formatos de salida y flujos de validación.
Cuándo hacer preguntas y cuándo empezar directamente.

Esto es mucho más fiable que escribir simplemente “hazlo más premium”.

Esto es especialmente cierto en tareas de diseño. La estética no se puede reproducir de forma estable con una sola frase de prompt. Lo que realmente ayuda es el proceso: confirmar materiales, definir una dirección, montar la estructura, trabajar la parte visual y revisar la salida. Cuando ese proceso se escribe como Skill, el Agent se parece más a un ejecutor colaborativo que a un generador de imágenes de una sola vez.

Recomendaciones de uso

Si solo quieres convertir un tema en una charla presencial o un deck para compartir, prueba primero guizang-ppt-skill. Su frontera de salida es estrecha, y el HTML de archivo único facilita distribuirlo y previsualizarlo.

Si quieres que un Agent asuma una tarea de diseño más completa, como prototipos de App, animaciones de lanzamiento, diapositivas con marca, PPTX exportable o infografías, mira primero huashu-design. Su flujo es más largo y encaja con tareas que necesitan varias rondas de iteración y exportación de entregables.

Si ya estás escribiendo tu propia Skill para Codex o Claude Code, ambos proyectos merecen estudio:

Para aprender “cómo estabilizar un escenario estrecho”, mira guizang-ppt-skill.
Para aprender “cómo dividir un flujo complejo en protocolos ejecutables”, mira huashu-design.

Resumen

Lo que tienen en común los proyectos de Guizang y Huashu es que ambos convierten la “capacidad de diseño” de un prompt único en un proceso repetible.

guizang-ppt-skill se centra en PPT HTML con estilo de revista y encaja con presentaciones muy estilizadas. huashu-design se centra en un sistema de diseño HTML-native que cubre prototipos, animaciones, diapositivas, infografías y revisión. El problema que resuelven no es “si la IA puede generar diseño”, sino “si la IA puede generar diseño entregable siguiendo un método estable”.

Esto podría convertirse en una categoría importante de proyectos open source dentro del ecosistema de herramientas Agent: no solo plantillas de código, sino experiencia humana, estética y métodos de trabajo empaquetados como Skills.

Enlaces de referencia:

Codex vs Claude Code: cómo elegir entre dos diseños de Subagent

Fri, 08 May 2026 14:14:01 +0800

Las herramientas de programación con IA están prestando cada vez más atención a los subagentes. No es simple moda: un solo agente acaba encontrando límites cuando debe manejar tareas reales de ingeniería.

Si un agente lee código, revisa logs, modifica implementación, ejecuta pruebas, analiza errores y resume resultados a la vez, el contexto principal se ensucia rápido. Resultados de búsqueda, salidas de comandos, logs de pruebas y razonamientos intermedios se mezclan. Las decisiones posteriores se vuelven menos fiables. Además, explorar, implementar, verificar y revisar en un único hilo dificulta el paralelismo.

El objetivo de los subagentes es reducir esa presión. La sesión principal deja de hacerlo todo de principio a fin y pasa a coordinar: define objetivos, asigna trabajo, recibe resultados y los integra. Un subagente se ocupa de una parte local, como exploración, implementación, verificación o revisión, y devuelve una conclusión comprimida.

Un subagente no es “otra copia de mí”. Es una forma de dividir trabajo de ingeniería confuso en roles más claros.

Fundamentos compartidos

Un sistema maduro de subagentes suele necesitar cuatro bases:

Aislamiento de contexto.
Especialización de roles.
Configuración a nivel de proyecto y usuario.
Límites de herramientas y permisos.

El aislamiento de contexto es esencial. En un repositorio real hay mucho material intermedio: búsquedas, logs de pruebas, salidas de comandos. Si todo entra en la sesión principal, el hilo principal se vuelve ruidoso. Un subagente puede digerir ese proceso local y devolver solo las señales útiles.

La especialización de roles también importa. Multi-agent no significa abrir varias copias del mismo modelo. Un rol de exploración debe buscar, leer y resumir. Un rol de implementación debe centrarse en cambios locales. Un rol de verificación debe ejecutar checks, identificar riesgos e informar con claridad.

Los límites de herramientas y permisos determinan si el sistema es seguro. Un subagente no debería heredar automáticamente todas las capacidades de la sesión principal. Un explorer de solo lectura no necesita escribir archivos. Un verifier no siempre necesita modificar implementación.

Codex y Claude Code comparten estas preocupaciones, pero toman caminos distintos.

Codex: delegación explícita

El diseño de Codex es más contenido.

Ofrece un mecanismo de delegación controlado y ligero alrededor de la sesión principal actual. Cuándo delegar, a quién delegar y cuándo recoger resultados son decisiones explícitas. El flujo de control permanece en la tarea actual.

Sus rasgos:

La sesión principal delega explícitamente.
El conjunto de roles se mantiene pequeño.
La sesión principal sabe qué agente hace qué.
Los resultados vuelven a la línea principal.
Los límites de colaboración son transparentes.

Esto encaja con equipos que valoran orquestación manual, previsibilidad y determinismo. Puedes pedir a un explorer que inspeccione una cadena de llamadas, a un worker que haga un cambio acotado y a la sesión principal que integre el resultado.

La contrapartida es que la presión de orquestación sigue en la sesión principal. Debe decidir cuándo dividir, cómo dividir, a quién asignar y cómo fusionar resultados. Para colaboración ligera es cómodo; para flujos largos puede cansar.

Claude Code: agentes como puestos de trabajo

Claude Code toma una ruta más de plataforma.

Trata los agentes como objetos describibles, seleccionables, configurables, con memoria, aislables y capaces de ejecutarse en segundo plano. Un subagente no es solo una ayuda temporal en una conversación; se parece más a un puesto de trabajo dentro de un sistema de ingeniería.

El sistema puede exponer listas de agentes, casos de uso, descripciones y límites de herramientas al modelo, permitiendo que el modelo decida qué rol usar en cada turno. Eso hace la delegación más automática.

Varios elementos definen este enfoque.

Primero, un sistema de roles. Explorer, planner, general-purpose y verifier pueden tener descripción de uso, restricciones de herramientas, modelos por defecto y condiciones de ejecución. Un explorer de solo lectura no edita archivos; un planner diseña; un verifier comprueba.

Segundo, herencia y override. Un subagente no es completamente libre. Hereda los límites grandes de la sesión principal, pero puede ajustar comportamiento local dentro de reglas permitidas.

Tercero, memoria. La memoria no es solo recordar algo. Puede tener alcance: memoria de usuario para preferencias largas, memoria de proyecto para contexto del repositorio y memoria local para estado del entorno.

Cuarto, background y worktree isolation. Algunas verificaciones pueden seguir en segundo plano mientras el hilo principal avanza. Si hace falta aislamiento fuerte, el agente puede trabajar en un worktree separado.

Quinto, ecosistema de plugins. Si los agentes son objetos de primera clase, hay que pensar en distribución, instalación, prioridades, overrides y seguridad. Los plugin agents pueden entrar al sistema, pero campos de alto riesgo como permission mode, hooks o MCP servers deben estar controlados.

Esto hace que Claude Code se parezca más a un runtime de agentes que a una herramienta de colaboración de una sola sesión.

Diferencia principal

Codex se parece a una herramienta de delegación controlada:

Delegación explícita.
Roles ligeros.
Flujo de control claro.
Subtareas centradas en la sesión actual.
Adecuado para trabajo humano-orquestado y determinista.

Claude Code se parece a un sistema de puestos de ingeniería:

Los agentes están modelados formalmente.
Los roles son más sistemáticos.
Memoria, background, aislamiento y plugins forman parte del runtime.
El modelo puede ayudar a elegir roles.
Adecuado para proyectos largos y workflows de plataforma.

La pregunta no es cuál tiene más funciones. Es si quieres que un subagente sea “un ayudante al que llamo explícitamente” o “un puesto permanente dentro del sistema”.

Cómo elegir

Elige el estilo Codex si valoras control explícito, delegación ligera y paralelismo seguro dentro de la sesión actual. Encaja con revisiones, cambios pequeños, tareas claras y flujos donde la persona quiere mantener el ritmo.

Elige el estilo Claude Code si necesitas roles sistemáticos, memoria a largo plazo, ejecución en segundo plano, aislamiento por worktree, plugins y un runtime más completo.

Hazte dos preguntas:

¿Aceptas que el modelo decida quién debe hacer el trabajo?
¿Necesitas un runtime de agentes más completo?

Si la primera te incomoda, la delegación explícita es mejor. Si la segunda es sí, un sistema tipo plataforma encaja mejor.

Consejos prácticos

No trates los subagentes como “más modelos igual a más potencia”.

Define límites de tarea para cada rol.
Limita las herramientas de cada rol.
Pide conclusiones, no logs crudos.
Mantén la decisión final en la sesión principal.
Haz visibles tareas en background y worktrees.
Define límites de seguridad para plugins.

El valor de los subagentes no está en la cantidad, sino en la calidad de la división del trabajo.

Resumen

Codex y Claude Code resuelven el mismo problema: un solo agente no puede cargar cómodamente con todo el trabajo real de ingeniería. Ambos reconocen la importancia de aislar contexto, especializar roles, definir permisos y resumir localmente.

Codex es más contenido y prioriza delegación explícita y control de la sesión principal. Claude Code es más sistemático y trata los agentes como puestos configurables, con memoria, aislamiento, background y ecosistema de plugins.

La elección no depende de qué marca gana, sino de si tu flujo necesita una herramienta de colaboración controlada o un runtime completo de agentes.

9Router: conecta Claude Code, Codex y Cursor a un mismo router de IA

Fri, 08 May 2026 13:41:15 +0800

9Router es un router local para herramientas de programación con IA. Permite conectar Claude Code, Codex, Cursor, Cline, Copilot, OpenCode, OpenClaw y herramientas similares a un único endpoint compatible con OpenAI, y desde ahí enrutar las solicitudes a distintos modelos y proveedores.

No pretende ser otro cliente de chat. Se coloca entre tus herramientas de programación y los proveedores de modelos para resolver problemas prácticos: formatos de API incompatibles, cambios manuales entre proveedores, consumo rápido de tokens por salidas de herramientas, cortes por cuotas agotadas y configuración complicada de varias cuentas.

Según el README, 9Router admite más de 40 proveedores y más de 100 modelos. Incluye RTK Token Saver, fallback automático, seguimiento de cuotas, rotación multi-cuenta, traducción de formatos y registros de solicitudes. Está escrito en JavaScript, usa Node.js, Next.js, React, Tailwind CSS y LowDB, y tiene licencia MIT.

Para qué sirve

9Router tiene más sentido cuando usas varias herramientas de programación con IA y varias fuentes de modelos al mismo tiempo.

Claude Code usa una cuenta de suscripción.
Codex o Cursor necesitan un endpoint OpenAI personalizado.
Cline, Continue o RooCode necesitan una API compatible con OpenAI.
Los proveedores gratuitos sirven para pruebas.
GLM, MiniMax o Kimi funcionan como respaldo barato.
Los modelos de mayor calidad se reservan para tareas difíciles.

Sin 9Router, cada herramienta necesita su propio endpoint, API key, nombre de modelo y estrategia de fallback. 9Router centraliza todo eso en una capa local.

API local:

`1`	`http://localhost:20128/v1`

Dashboard:

`1`	`http://localhost:20128/dashboard`

Instalación rápida

Para uso local:

1
2

npm install -g 9router
9router

Desde el código fuente:

git clone https://github.com/decolua/9router.git
cd 9router
cp .env.example .env
npm install
PORT=20128 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run dev

Modo producción:

1
2

npm run build
PORT=20128 HOSTNAME=0.0.0.0 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run start

El paquete npm requiere Node.js >=18.0.0. En VPS o Docker, configura JWT_SECRET, INITIAL_PASSWORD, DATA_DIR y API_KEY_SECRET.

Conectar herramientas de programación

Configuración típica:

1
2
3

Base URL: http://localhost:20128/v1
API Key: copiada desde el dashboard de 9Router
Model: nombre de modelo o combo configurado en 9Router

Para Codex CLI:

export OPENAI_BASE_URL="http://localhost:20128"
export OPENAI_API_KEY="your-9router-api-key"

codex "your prompt"

Para Cline, Continue o RooCode, elige OpenAI Compatible:

1
2
3

Base URL: http://localhost:20128/v1
API Key: your-9router-api-key
Model: cc/claude-opus-4-7

Los nombres dependen de los proveedores conectados, por ejemplo cc/, cx/, gh/, glm/, minimax/, kr/ y vertex/.

RTK Token Saver

En programación con IA, muchas veces lo que más tokens consume son salidas de herramientas:

git diff
git status
grep
find
ls
tree
logs
listas largas de archivos

RTK Token Saver comprime esas salidas antes de enviarlas al modelo. El proyecto afirma que puede ahorrar 20%-40% de tokens de entrada en muchas solicitudes.

La ventaja es que no tienes que cambiar de herramienta ni de modelo. Aun así, para logs críticos o contenido completo de archivos, conviene probar primero que la calidad de respuesta no baje.

Fallback automático

Puedes ordenar modelos por prioridad:

1
2
3

1. Modelo de suscripción
2. API barata
3. Proveedor gratuito

Ejemplo:

1
2
3

1. cc/claude-opus-4-7
2. glm/glm-5.1
3. kr/claude-sonnet-4.5

El fallback reduce interrupciones, pero cambia la consistencia de salida. Para refactors grandes, migraciones o tareas sensibles, es mejor fijar un modelo principal.

Cuidado con proveedores gratuitos

Kiro, OpenCode Free y Vertex pueden ser útiles, pero sus reglas cambian. Verifica siempre si el uso es gratuito, si hay límites regionales, si se permite usar herramientas de terceros, si puede haber rate limits o bloqueos, y cuándo caduca la cuota.

9Router enruta solicitudes; no cambia las condiciones del proveedor.

Despliegue local

Para uso personal, basta con escuchar en localhost. Si lo llevas a un VPS o LAN, cambia la contraseña por defecto, configura JWT_SECRET y API_KEY_SECRET, no expongas el dashboard directamente, y exige Bearer API key en /v1/*.

docker run -d \
  --name 9router \
  -p 20128:20128 \
  --env-file ./.env \
  -v 9router-data:/app/data \
  -v 9router-usage:/root/.9router \
  9router

Resumen

9Router es una puerta de enlace local para herramientas de programación con IA. Unifica Claude Code, Codex, Cursor y Cline en http://localhost:20128/v1, y gestiona selección de modelo, traducción de formatos, compresión de tokens, cuotas y fallback.

Es más útil para usuarios intensivos que ya alternan entre varios proveedores. Empieza con una herramienta y un proveedor, y añade combos poco a poco.

Referencias

24 consejos de Claude Code: modo plan, rewind, CLAUDE.md, Skills, Agents y plugins

Fri, 08 May 2026 08:54:14 +0800

Claude Code no es solo una caja de chat. Se parece más a un Agent de programación que puede entrar en un directorio de proyecto, leer y escribir archivos, ejecutar comandos y mantener contexto.

Si solo le das un requisito y esperas código, pronto aparecen problemas: el plan no queda claro, los permisos se repiten, el contexto crece, el resultado no convence, no sabes cómo volver atrás y no hay un lugar estable para reglas del proyecto.

Estos son consejos prácticos para quienes empiezan con Claude Code.

Empieza dentro del directorio del proyecto

Claude Code funciona mejor cuando se inicia dentro del directorio del proyecto, no desde una terminal cualquiera.

Crea una carpeta de proyecto, entra en ella, abre la línea de comandos e inicia Claude Code:

claude

Si al entrar por primera vez pregunta si confías en la carpeta actual, confirma antes de seguir. Así podrá leer archivos, crear archivos y ejecutar operaciones alrededor del proyecto.

Una práctica sencilla es pedirle que cree una web personal de fotógrafo. Es una tarea visual, permite inspeccionar el resultado y sirve para practicar generación de archivos, comandos, rewind y refactorización.

Usa modo plan para aclarar la dirección

Ante tareas complejas, Claude Code puede entrar en modo plan. Su función es discutir requisitos, dividir pasos y pedir aprobación antes de ejecutar.

Tras escribir un plan, suelen aparecer opciones como:

Aprobar el plan y permitir automáticamente herramientas de edición posteriores.
Aprobar el plan, pero pedir confirmación manual para futuras ediciones.
Pausar y seguir discutiendo el plan con Claude Code.

Si la tarea está clara, aprueba y continúa. Si no, pídele que complete el plan: estilo de página, stack técnico, estructura de carpetas, interacciones y criterios de aceptación.

El modo plan reduce retrabajo. Si el Agent empieza directamente, puede crear muchos archivos rápido; si la dirección era incorrecta, luego todo se vuelve más difícil de corregir.

Cambia de modo con Shift + Tab

En Claude Code, Shift + Tab permite cambiar entre modos de trabajo. Se usa a menudo para entrar en modo plan o para cambiar a un modo de aprobación automática de edición.

Hábitos recomendados:

Proyecto nuevo, función nueva o cambio grande: primero modo plan.
Cambio pequeño o arreglo claro: ejecutar directamente.
Borrado, reemplazos masivos o instalación de dependencias: mantener confirmación humana.

En modo plan, Claude Code puede preguntar detalles del proyecto. Usa flechas para elegir opciones y Enter para confirmar. Después de enviar feedback, actualizará el plan.

No abras todos los permisos

Cuando Claude Code ejecuta comandos, edita archivos o inicia programas, puede pedir permisos.

Opciones comunes:

Permitir solo esta vez.
Permitir el mismo tipo de comando en esta sesión.
Rechazar o pausar.

Para abrir una página local, iniciar un servidor de desarrollo o revisar archivos, aprueba según necesidad. Pero no uses durante mucho tiempo un modo de “permitir todo” solo por comodidad.

La aprobación total automática solo tiene sentido en tareas de bajo riesgo, muy claras y con respaldo Git. En el uso diario, conserva confirmación humana para borrar, sobrescribir carpetas, instalar dependencias, usar red, hacer commits o ejecutar scripts.

Ejecuta comandos locales en modo terminal

Claude Code puede entrar en modo de comandos de terminal y ejecutar comandos locales.

Por ejemplo, después de generar una página, puedes abrir un archivo HTML con:

`1`	`start index.html`

start es un comando de Windows para abrir archivos. Es más rápido que buscar el archivo manualmente.

El modo terminal sirve para:

Abrir páginas generadas.
Ver contenido de directorios.
Iniciar servidores locales.
Ejecutar pruebas o builds.

Pero los comandos de alto riesgo siguen requiriendo cuidado: borrado recursivo, mover directorios, sobrescrituras masivas y cambios de entorno.

Usa rewind cuando el resultado se desvía

Si la página o el código que hizo Claude Code no es lo que quieres y cada corrección lo empeora, usa rewind temprano.

Rewind puede devolver conversación o código a un punto anterior. Opciones comunes:

Revertir código y conversación.
Revertir solo conversación.
Revertir solo código.
Comprimir contenido anterior como resumen.
Cancelar.

Cuando la dirección se desvió claramente, conviene volver código y conversación juntos. Así contexto y archivos regresan a un estado más limpio.

Ten en cuenta que el rewind de Claude Code normalmente cubre archivos creados o modificados con herramientas internas. Archivos creados por comandos externos quizá no se reviertan por completo. Para proyectos importantes, usa Git.

Escribe prompts largos en un editor

No metas requisitos complejos en una sola línea.

Si el sistema permite editar un prompt largo en un editor, úsalo, guarda y luego envíalo a Claude Code.

Un prompt largo debería aclarar:

Objetivo.
Stack técnico.
Qué no debe hacerse.
Qué archivos deben conservarse.
Cómo verificar el resultado.
Criterios de aceptación.

Por ejemplo, si quieres refactorizar una página HTML a un stack más moderno, no escribas solo “refactoriza”. Explica estructura por componentes, preservación visual, diseño responsive y pide ejecutar una comprobación de build.

Recupera sesiones después de salir

Si necesitas salir de Claude Code, hazlo normalmente. Luego vuelve al mismo directorio y arranca otra vez:

claude

Si el historial anterior no aparece, usa comandos de historial para ver sesiones recientes y cargar la sesión anterior.

Esto sirve para continuar trabajo interrumpido. Pero no uses el historial como única memoria. Reglas del proyecto, stack, comandos comunes y notas deben estar en archivos del proyecto.

Guarda reglas del proyecto en CLAUDE.md

CLAUDE.md es un archivo de memoria importante para Claude Code. Normalmente está en la raíz del proyecto y registra reglas, stack, estructura de carpetas y restricciones de colaboración.

Puedes inicializarlo con:

/init

CLAUDE.md sirve para registrar:

Objetivos del proyecto.
Stack técnico.
Comandos de inicio, prueba y build.
Estructura de directorios.
Estilo de código.
Acciones prohibidas.
Reglas de commit y despliegue.

En cada conversación, Claude Code puede usar estas reglas como parte del contexto. Piensa en él como un manual del proyecto.

Una prueba sencilla es añadir una regla evidente en CLAUDE.md y luego preguntar algo. Si la respuesta sigue la regla, leyó la memoria del proyecto.

Usa @ para referenciar archivos

En el cuadro de entrada, @ permite seleccionar archivos o Agents y añadirlos al contexto actual.

Sirve para:

Hacer que Claude Code lea un archivo de configuración.
Pedir cambios en una página concreta.
Continuar según CLAUDE.md u otro documento.
Decir explícitamente “mira solo este archivo, no adivines la estructura”.

Comparado con pegar el contenido del archivo, @ es más claro y menos propenso a omisiones.

Revisa y comprime contexto

Tras una conversación larga, el contexto crece. Si se vuelve demasiado largo, el modelo puede ralentizarse o ignorar detalles antiguos.

Usa:

`1`	`/context`

Si el contexto ya es largo, comprime el historial:

`1`	`/compact`

Si aun así el efecto es malo, limpia el contexto actual:

/clear

Después de limpiar, Claude Code todavía puede entender parte del proyecto mediante archivos, CLAUDE.md y el directorio actual, pero no conserva todo el historial de conversación.

Una regla útil: abre una conversación nueva al terminar una tarea, escribe reglas del proyecto en CLAUDE.md, y no acumules discusión temporal para siempre en un solo chat.

Skills: convierte flujos fijos en instrucciones

Skills son instrucciones reutilizables para Claude Code. No son prompts de una sola vez, sino flujos de tarea empaquetados.

Por ejemplo, si generas informes semanales a menudo, crea una Skill de informe semanal con:

Información de entrada necesaria.
Formato de salida.
Tono y estructura.
Qué debe conservarse.
Qué no debe inventarse.

Las Skills suelen contener name, description e instrucciones detalladas. Al instalarlas en el directorio global de Skills, Claude Code puede reconocerlas y cargarlas cuando la tarea encaja.

Candidatos adecuados:

Informes semanales.
Plantillas de revisión de código.
Organización de documentos.
Procesamiento de imágenes por lotes.
Artículos con formato fijo.
Flujos de inicialización de proyectos.

Si copias el mismo prompt muchas veces, conviértelo en Skill.

Agents: delega subtareas a asistentes independientes

Agents no son lo mismo que Skills.

Una Skill es un manual de instrucciones. Un Agent se parece más a un asistente independiente que trabaja fuera de la conversación principal y devuelve resultados.

Su valor está en aislar contexto. Para una revisión de código, puedes crear un Agent de solo lectura que lea el proyecto y entregue un informe sin modificar archivos. Así no contamina la conversación principal y reduce riesgos.

Al crear un Agent, considera:

Si será de proyecto o de usuario.
Si Claude Code debe generar la configuración.
Qué herramientas puede usar.
Qué modelo usará.
Si guardará memoria.
Si el prompt del Agent es claro.

Para Agents de auditoría de código, da solo permisos de lectura. Primero que entregue un informe; luego la conversación principal decide si cambia código.

Plugins: empaqueta Skills, Agents, MCP y Hooks

Los plugins son paquetes de capacidad más completos. Pueden incluir:

Skills
Agents
MCP
Hooks

Frente a una Skill aislada, un plugin sirve mejor para capacidades de conjunto. Un plugin de diseño frontend puede empaquetar estética de página, reglas de layout, hábitos de componentes y Agents relacionados.

Al instalar plugins, suele haber opciones:

Directorio de usuario, efectivo para todos los proyectos.
Directorio de proyecto, compartido con el proyecto.
Directorio local del proyecto, solo efectivo en tu ordenador.

Para capacidades personales frecuentes, usa el directorio de usuario. Para acuerdos de equipo, usa el proyecto. Para pruebas temporales, usa instalación local.

Los plugins mejoran tareas concretas

En generación de páginas frontend, un plugin suele ser más estable que un prompt desnudo.

Por ejemplo, para “crear una web personal de fotógrafo”, un prompt normal puede crear una página aceptable. Si usas explícitamente un plugin de diseño frontend, la estructura, jerarquía visual, espaciado, color y acabado suelen mejorar.

Esto no reemplaza el criterio humano. Lo razonable es dejar que el plugin genere un primer borrador mejor y luego ajustar detalles manualmente.

Un flujo de trabajo más estable

Combinando todo lo anterior, queda un flujo más estable:

Inicia claude dentro del directorio del proyecto.
Discute requisitos primero en modo plan.
Confirma stack y criterios de aceptación antes de aprobar.
Mantén confirmación manual para acciones de alto riesgo.
Usa modo terminal para previsualización y pruebas.
Usa rewind cuando el resultado se desvíe.
Escribe reglas en CLAUDE.md.
Revisa y comprime contexto en conversaciones largas.
Convierte flujos repetidos en Skills.
Delega inspección, investigación y análisis a Agents de solo lectura.
Usa plugins para tareas de dominio específico.
Mantén puntos de commit Git en proyectos importantes.

Así Claude Code será mucho más estable que enviar una frase y esperar generación.

Resumen

La eficiencia de Claude Code no viene solo del modelo, sino también del control del flujo.

El modo plan define la dirección, los permisos controlan el riesgo, rewind reduce retrabajo, CLAUDE.md guarda reglas del proyecto, /context, /compact y /clear gestionan contexto, Skills reutilizan flujos, Agents aíslan subtareas y plugins empaquetan capacidades completas.

La mejor forma de usar Claude Code es dejar que avance dentro de límites claros, no entregarle todo el proyecto de una vez.

opencode, Claude Code y Codex: diferencias y guía de herramientas open source de programación con IA

Fri, 08 May 2026 08:33:37 +0800

opencode es un AI Coding Agent open source de anomalyco. Su posicionamiento es directo: dar a los desarrolladores un asistente de código programable, extensible y capaz de conectarse a varios proveedores de modelos dentro de la terminal.

Si lo comparamos con Claude Code y Codex, los tres resuelven una misma clase de problema: llevar la IA a bases de código reales para entender contexto, modificar archivos, ejecutar comandos y correr pruebas. Pero su orientación de producto es distinta.

opencode pone más énfasis en open source, soporte de múltiples modelos y TUI de terminal. Claude Code enfatiza el ecosistema de modelos de Anthropic y la colaboración de ingeniería local. Codex es el AI coding agent de OpenAI, disponible desde la terminal, IDEs, Codex app y tareas en la nube.

Para quién es opencode

opencode encaja mejor con estos tipos de desarrolladores:

Quienes quieren completar cambios de código, análisis de proyectos y tareas de ingeniería desde la terminal.
Quienes no quieren que su AI Coding Agent dependa de un único proveedor de modelos.
Quienes prefieren herramientas open source y quieren auditarlas, ampliarlas o construir sobre ellas.
Quienes ya están cómodos con Neovim, TUI y flujos de línea de comandos.
Quienes quieren controlar en el futuro el mismo agente de programación desde una app de escritorio, móvil u otros clientes.

Su objetivo no es crear otra ventana de chat, sino poner capacidades de programación con IA dentro de la terminal y los directorios de proyecto que los desarrolladores ya usan.

Instalación

El README oficial ofrece varias formas de instalación.

# Instalación directa
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS y Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# Otros métodos
mise use -g opencode
nix run nixpkgs#opencode

El README oficial también recomienda eliminar versiones anteriores a 0.1.x antes de instalar, para evitar problemas causados por restos de versiones antiguas.

El script de instalación elige el directorio de instalación con esta prioridad:

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

Si necesitas especificar una ruta, puedes usar:

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

La app de escritorio sigue en Beta

Además de la herramienta de línea de comandos, opencode también ofrece una app de escritorio, actualmente marcada como Beta. Se puede descargar desde GitHub Releases o opencode.ai/download.

La versión de escritorio cubre estas plataformas:

Plataforma	Archivo
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`, `.rpm` o `.AppImage`

En macOS y Windows también se puede instalar la app de escritorio con gestores de paquetes.

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

Dos modos Agent integrados

opencode incluye dos Agent integrados, que se pueden cambiar con la tecla Tab.

build es el modo predeterminado. Tiene permisos completos de desarrollo y sirve para editar código directamente, ejecutar comandos y avanzar en tareas de ingeniería.

plan es el modo de solo lectura. Es más adecuado para analizar bases de código desconocidas, entender la estructura del proyecto y preparar un plan de cambios. Por defecto rechaza ediciones de archivos y pregunta antes de ejecutar comandos bash.

Además, opencode incluye un sub-Agent general para búsquedas complejas y tareas de varios pasos. Los usuarios pueden invocarlo escribiendo @general en un mensaje.

Este diseño es bastante práctico: antes de actuar, usa plan para entender el proyecto; cuando haga falta cambiar código, cambia a build. En repositorios grandes, separar permisos de lectura y escritura ayuda a reducir errores.

Qué es Codex

Codex es el AI coding agent de OpenAI para ayudar a desarrolladores a escribir código, revisar código, corregir bugs y entregar tareas de ingeniería.

A diferencia de una herramienta simple de autocompletado, Codex se parece más a un Agent capaz de operar sobre una base de código. Puede trabajar contigo en herramientas locales y también puede recibir tareas delegadas para ejecutarlas en la nube. Los materiales oficiales de OpenAI describen Codex como disponible desde varias superficies, incluyendo CLI, IDEs, Codex app y flujos en la nube de ChatGPT/Codex.

Para desarrolladores, Codex tiene varios puntos importantes:

Puede leer bases de código, editar archivos, ejecutar comandos y correr pruebas.
Soporta varias interfaces, incluyendo terminal, IDE, app y nube.
Encaja con corrección de bugs, desarrollo de funciones, refactorización, migraciones, revisión de código y generación de pruebas.
Está más ligado a cuentas, modelos y ecosistema de producto de OpenAI.
Las tareas en la nube sirven para ejecutar en paralelo varias tareas de ingeniería relativamente bien definidas.

Si opencode se parece más a un framework abierto de agente en terminal, Codex se parece más a un banco de trabajo completo de programación con IA ofrecido por OpenAI: colaboración local, delegación en la nube y flujos de ingeniería más largos para equipos.

Diferencias principales

opencode, Claude Code y Codex son herramientas de programación con IA, pero la elección se entiende mejor mirando estas dimensiones.

Herramienta	Posicionamiento central	Ventajas principales	Mejor para
`opencode`	AI Coding Agent open source	Open source, múltiples modelos, TUI, arquitectura cliente/servidor	Desarrolladores que quieren una cadena de herramientas abierta, modelos reemplazables y un flujo centrado en terminal
`Claude Code`	Herramienta de programación de línea de comandos de Anthropic	Experiencia con modelos Claude, comprensión de código, contexto largo, colaboración en tareas de ingeniería	Desarrolladores que ya usan el ecosistema Claude/Anthropic y quieren avanzar tareas de código locales
`Codex`	AI coding agent de OpenAI	CLI, IDE, Codex app, tareas en la nube, flujos multi-Agent	Equipos que ya usan ChatGPT/OpenAI y quieren combinar colaboración local con delegación en la nube

En resumen, las palabras clave de opencode son “apertura y reemplazabilidad”; las de Claude Code son “ecosistema Claude y agente local de ingeniería”; y las de Codex son “ecosistema OpenAI y colaboración desde múltiples entradas”.

Diferencias con Claude Code

El FAQ oficial de opencode lo compara directamente con Claude Code. Ambos son muy parecidos en capacidad, pero las diferencias principales son estas.

Primero, opencode es un proyecto 100% open source, alojado en GitHub y publicado con MIT license.

Segundo, opencode no depende de un único proveedor de modelos. Recomienda los modelos ofrecidos a través de OpenCode Zen, pero también puede trabajar con Claude, OpenAI, Google o modelos locales. Para desarrolladores, esto significa que cuando cambien el costo, la capacidad o la disponibilidad de los modelos, no quedarán atados a una sola plataforma.

Tercero, opencode incluye soporte LSP opcional. Para autocompletado, navegación, diagnósticos y comprensión del proyecto, LSP es una base muy importante.

Cuarto, opencode pone más énfasis en TUI. Está creado por usuarios de Neovim y los creadores de terminal.shop, así que el foco del producto está claramente en la experiencia de terminal.

Quinto, opencode usa una arquitectura cliente/servidor. Esto significa que opencode puede ejecutarse en tu computadora y, en el futuro, controlarse desde una TUI, una app de escritorio, una app móvil u otros clientes. La TUI es solo una de las posibles interfaces.

Cuándo elegir opencode, Claude Code o Codex

Si ya usas Claude Code o Codex, opencode no tiene por qué reemplazarlos de inmediato. Una forma más razonable de verlo es que ofrece una opción abierta, con modelos reemplazables y orientada a la terminal.

Conviene considerar primero opencode cuando:

Quieres que tu herramienta de programación con IA sea lo más open source posible.
No quieres atar tu flujo de trabajo a un proveedor de modelos.
Quieres probar Claude, OpenAI, Google o modelos locales con la misma herramienta.
Te gustan los flujos TUI y no quieres que una app de escritorio o web interrumpa tu flujo principal.
Te interesa el potencial de control remoto de una arquitectura cliente/servidor.

Conviene considerar primero Claude Code cuando:

Usas principalmente modelos Claude.
Te importan el contexto largo, la comprensión de código y la colaboración en tareas de ingeniería complejas.
Quieres avanzar cambios, pruebas y refactorizaciones dentro de un repositorio local.
Confías más en la experiencia predeterminada de Claude Code diseñada por Anthropic.

Conviene considerar primero Codex cuando:

Ya usas ChatGPT o el ecosistema de cuentas de OpenAI.
Quieres un mismo coding agent en terminal, IDE, app de escritorio y tareas en la nube.
Quieres delegar en la nube correcciones de bugs, desarrollo de funciones, migraciones o generación de pruebas relativamente claras, en paralelo.
Necesitas revisión de código, tareas en segundo plano, colaboración de equipo y flujos multi-Agent.

Si priorizas una experiencia oficial de extremo a extremo, configuración predeterminada de modelos, administración empresarial e integraciones listas, Claude Code o Codex pueden ser más cómodos. Si priorizas control, apertura y enfoque provider-agnostic, opencode merece atención.

Puntos a tener en cuenta

opencode, Claude Code y Codex avanzan rápido. Los releases de GitHub, comandos de instalación, nombres de archivos de escritorio, disponibilidad de modelos y permisos de planes pueden cambiar. Antes de instalar o elegir, conviene revisar directamente el README, la documentación y las páginas de releases oficiales de cada herramienta.

Además, la app de escritorio de opencode sigue marcada como Beta, así que no conviene tratarla por defecto como una herramienta estable de producción. Para tareas de ingeniería diarias, la versión de terminal sigue siendo la entrada principal.

Visto como tendencia de herramientas, opencode representa la dirección de cadena de herramientas abierta para AI Coding Agents: modelos reemplazables, clientes reemplazables y una capacidad central de agente lo más abierta posible. Codex y Claude Code se parecen más a modelos convertidos por sus empresas en superficies de producto completas para coding agents. Para desarrolladores, ambas rutas probablemente coexistirán durante mucho tiempo.

Referencias

opencode GitHub: https://github.com/anomalyco/opencode
sitio oficial de opencode: https://opencode.ai
documentación de opencode: https://opencode.ai/docs
opencode Releases: https://github.com/anomalyco/opencode/releases
OpenAI Codex: https://openai.com/codex/
Using Codex with your ChatGPT plan: https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started: https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Claude Opus 4.7, Sonnet 4.6 y Haiku 4.5: diferencias y guía para elegir modelo

Fri, 08 May 2026 08:19:03 +0800

Los modelos grandes principales de Anthropic evolucionan sobre todo a través de la serie Claude. A mayo de 2026, la línea principal de Claude ya está en la etapa 4.x, pero mantiene una estructura de tres niveles: Opus se centra en la máxima capacidad, Sonnet equilibra rendimiento y costo, y Haiku prioriza velocidad y relación costo-beneficio.

Si solo quieres una regla rápida para elegir, recuerda esto:

Para el razonamiento más complejo y pesado, y para agentic coding: mira primero Claude Opus 4.7.
Para la mayoría de escenarios de desarrollo, escritura, análisis y API empresariales: empieza por Claude Sonnet 4.6.
Para tareas de alta concurrencia, baja latencia y sensibilidad al costo: considera Claude Haiku 4.5.

Modelos principales actuales

Según la documentación oficial de modelos de Anthropic, los modelos principales actuales de Claude pueden entenderse así.

Modelo	Posicionamiento	Escenarios adecuados
`Claude Opus 4.7`	El modelo general disponible más potente actualmente, orientado a razonamiento complejo y agentic coding	Refactorización de grandes bases de código, tareas de varios pasos, análisis estratégico complejo, trabajos que requieren mayor consistencia
`Claude Sonnet 4.6`	El punto de equilibrio entre velocidad, capacidad y costo, con una ventana de contexto de 1 millón de token	Generación de código, análisis de documentos largos, trabajo de conocimiento empresarial, desarrollo de Agent, tareas diarias de producción de alta calidad
`Claude Haiku 4.5`	El nivel de modelo pequeño más rápido y de menor costo, pero aún con capacidades cercanas a modelos de frontera	Conversación en tiempo real, soporte al cliente, clasificación por lotes, colaboración simple con código, llamadas API de alta concurrencia

Aquí conviene prestar atención a dos detalles de nombres.

Primero, el nombre oficial es Claude Haiku 4.5, no Claude 4.5 Haiku. Segundo, Claude Mythos Preview no es un modelo principal disponible para usuarios comunes o desarrolladores. Es una vista previa de investigación controlada relacionada con Project Glasswing, orientada principalmente a flujos defensivos de ciberseguridad, y no debería mezclarse con la selección habitual de modelos Claude.

Opus: para los problemas más difíciles

Opus es el nivel que Anthropic usa para sus modelos más potentes. El punto de Claude Opus 4.7 no es ser barato ni ser el más rápido, sino ser más adecuado para tareas complejas, de varios pasos, que requieren verificación repetida.

Encaja mejor en estas situaciones:

Cambios grandes de código en muchos archivos.
Refactorización de sistemas complejos y razonamiento arquitectónico.
Tareas Agent de cadena larga.
Trabajo que requiere mayor comprensión visual, comprensión documental y planificación de varias rondas.
Tareas de análisis empresarial donde el costo del error es alto.

Si el costo de que una tarea falle una vez es alto, o si quieres que el modelo dedique más tiempo a entender el contexto antes de actuar, normalmente vale más la pena probar Opus.

Sonnet: el punto de partida predeterminado para la mayoría

Claude Sonnet 4.6 es un modelo más adecuado como entrada predeterminada. Su posicionamiento no es ser un “Opus de gama baja”, sino poner razonamiento, programación, comprensión visual, contexto largo y agent planning suficientemente fuertes dentro de un perfil de costo y velocidad más controlable.

Para desarrolladores, el valor de Sonnet 4.6 está principalmente en tres puntos:

Puede manejar contextos muy largos, por lo que sirve para bases de código, contratos, informes o varios documentos.
Es más fácil usarlo como modelo habitual en Claude Code, API y escenarios empresariales.
Cuesta menos que Opus, así que encaja mejor con el uso frecuente.

Si no sabes con qué modelo Claude empezar, normalmente puedes empezar por Claude Sonnet 4.6. Solo cuando la tarea necesite claramente más capacidad conviene cambiar a Opus.

Haiku: cuando importan más la velocidad y el costo

Claude Haiku 4.5 es el nivel de modelo pequeño, pero no debe entenderse simplemente como un “modelo débil”. Anthropic lo posiciona como rápido y de bajo costo, manteniendo al mismo tiempo capacidades cercanas a modelos de frontera.

Es adecuado para estos escenarios:

Chat en tiempo real y bots de soporte al cliente.
Clasificación masiva de textos cortos.
Llamadas API de baja latencia.
Cambios simples de código y prototipos rápidos.
Ejecución de subtareas en flujos con múltiples Agent.

Si la tarea es clara, el contexto no es complejo y el rendimiento por volumen importa, Haiku suele ser más razonable que usar a ciegas un modelo más grande.

Capacidades de herramientas de Claude

La serie Claude no es solo un conjunto de modelos de chat. Anthropic ahora integra sus capacidades de modelo en varios productos y herramientas para desarrolladores.

Claude Code es una herramienta de programación de línea de comandos para desarrolladores. Puede leer bases de código, editar archivos, ejecutar comandos y correr pruebas, por lo que sirve para avanzar de forma continua en tareas de ingeniería. Su experiencia depende mucho de la comprensión de código del modelo, la gestión de contexto y la estabilidad en llamadas a herramientas.

Computer Use permite que el modelo opere un entorno de escritorio mediante capturas de pantalla, mouse y teclado. Todavía debe usarse con cautela, y la documentación oficial también enfatiza ejecutarlo en un entorno aislado para evitar errores de operación o riesgos de seguridad.

Artifacts está más orientado a la experiencia dentro de la aplicación Claude. Puede colocar código, prototipos de páginas, gráficos o documentos en la interfaz para previsualizarlos e iterarlos. No es un modelo independiente, sino una parte de la forma de producto de Claude.

En cuanto a expresiones como “Managed Agents” o “Agent autoevolutivos”, conviene ser prudente al escribir. Anthropic sí está reforzando Agent SDK, Claude Code, contexto largo, llamadas a herramientas y flujos empresariales, pero no hay que describirlo como si ya tuviera capacidades de autoevolución no controlada.

Formas de acceso

Los usuarios comunes pueden usar Claude desde la web de Claude.ai o desde aplicaciones móviles. Los distintos planes afectan los modelos disponibles, las cuotas y las funciones.

Los desarrolladores suelen tener varias formas de integración:

Anthropic Console y Claude API.
Amazon Bedrock.
Google Cloud Vertex AI.
Microsoft Foundry.

Los modelos disponibles, la ventana de contexto, los precios y el soporte regional pueden cambiar. Antes de desarrollar, conviene basarse en la documentación oficial de modelos de Anthropic y en las páginas de la plataforma en la nube correspondiente.

Cómo elegir

En el uso real, no hace falta perseguir el modelo más potente desde el principio. Una mejor forma es dividir la elección según el costo de la tarea.

Para escritura diaria, generación de código, análisis de documentos largos, organización de conocimiento y la mayoría de prototipos Agent, empieza con Claude Sonnet 4.6. Normalmente es el mejor punto de partida por relación costo-beneficio y capacidad general.

Si la tarea necesita razonamiento complejo más fuerte, cambios de ingeniería entre archivos, planificación de cadena larga o mayor confiabilidad, cambia a Claude Opus 4.7.

Si la tarea es simple, de gran volumen y sensible a la latencia, como clasificación, resumen, atención al cliente o procesamiento por lotes, incluye Claude Haiku 4.5 entre los candidatos.

La línea de modelos Claude no es simplemente una historia de “una nueva versión reemplaza a la anterior”. Es una caja de herramientas organizada por dificultad de la tarea, velocidad y costo. Elegir el modelo correcto importa más que usar a ciegas el modelo más caro.

Referencias

Anthropic Models Overview: https://platform.claude.com/docs/en/about-claude/models/overview
Introducing Claude Opus 4.7: https://www.anthropic.com/news/claude-opus-4-7
Introducing Claude Sonnet 4.6: https://www.anthropic.com/news/claude-sonnet-4-6
Introducing Claude Haiku 4.5: https://www.anthropic.com/news/claude-haiku-4-5
Anthropic Computer Use Tool: https://docs.anthropic.com/en/docs/build-with-claude/computer-use

En qué se diferencian los mecanismos de memoria de ChatGPT, Claude Code y Gemini

Thu, 07 May 2026 14:47:17 +0800

La “memoria” se está volviendo cada vez más importante en los productos de IA. Marca el paso de conversaciones puntuales a colaboración de largo plazo: ya no necesitas volver a explicar tu contexto, repetir tus preferencias ni pedir al modelo que entienda el mismo proyecto una y otra vez.

Pero memoria no significa lo mismo en todos los productos. ChatGPT, Claude Code y Gemini intentan ayudar a la IA a recordar más tiempo, pero sus objetivos, lugares de almacenamiento, transparencia y casos de uso son muy distintos.

Al 7 de mayo de 2026, se pueden entender aproximadamente como tres tipos:

ChatGPT se parece más a memoria de asistente personal.
Claude Code se parece más a memoria de proyecto de ingeniería.
Gemini se parece más a contexto del ecosistema Google.

ChatGPT: preferencias de largo plazo alrededor de la persona

La memoria de ChatGPT está diseñada principalmente para colaboración personal. Le importa quién eres, qué prefieres y en qué trabajas a lo largo del tiempo.

OpenAI separa actualmente la memoria de ChatGPT en saved memories y chat history.

saved memories son piezas importantes de información que ChatGPT guarda, como tu nombre, preferencias, objetivos, stack tecnológico habitual y hábitos de escritura. Puedes pedirle explícitamente que recuerde algo, y también puede guardar información de una conversación cuando cree que será útil más adelante.

chat history permite a ChatGPT consultar conversaciones anteriores al responder. No significa que cada chat se convierta en una memoria permanente. Más bien, ChatGPT puede buscar en conversaciones pasadas contexto relevante cuando lo necesita.

La lógica central de ChatGPT es: entender al mismo usuario entre sesiones.

Ejemplos típicos:

“Mantén mis ejemplos de código concisos.”
“Uso principalmente Python y TypeScript.”
“Estoy escribiendo un blog Hugo sobre herramientas de IA.”
“Prefiero conclusiones primero y detalles después.”

Estas memorias no están ligadas a un solo proyecto. Siguen a la cuenta y a los hábitos de trabajo del usuario.

Memory Sources: hacer más visible la personalización

OpenAI destacó Memory sources en su actualización de mayo de 2026.

El objetivo no es añadir otro tipo de memoria, sino mostrar al usuario qué fuentes consultó ChatGPT al personalizar una respuesta. Según los documentos de ayuda de OpenAI, Memory Sources puede mostrar:

Chats anteriores.
Memorias guardadas.
Instrucciones personalizadas.
Archivos de la biblioteca de archivos.
Correos de Gmail conectado.

La visibilidad de archivos y Gmail depende del plan, la región y el estado de conexión. OpenAI también dice que Memory sources puede no mostrar todos los factores que influyeron en una respuesta, pero ayuda a entender y gestionar la personalización.

Esto importa. Cuanto más puede la IA “recordarte”, más necesitas saber qué usó para responder. De lo contrario, la personalización se vuelve una caja negra: parece conocerte, pero no sabes por qué.

La ventaja de ChatGPT es su comprensión de preferencias personales entre sesiones y temas. El riesgo es que las memorias se vuelvan obsoletas, o que el usuario olvide que una memoria antigua sigue afectando respuestas. Vale la pena limpiar periódicamente memorias guardadas y chats antiguos.

Claude Code: alrededor de codebases y reglas de ingeniería

La memoria de Claude Code está más orientada a ingeniería. Le importan menos las preferencias cotidianas del usuario y más cómo debe modificarse este codebase.

Claude Code tiene dos mecanismos de memoria que se confunden fácilmente:

Memoria explícita del proyecto: CLAUDE.md.
Memoria automática del proyecto: Auto Memory.

CLAUDE.md es el archivo de memoria de proyecto más básico y estable. Puede vivir en la raíz del proyecto o dentro de subdirectorios. Claude Code lee estos archivos como instrucciones de proyecto y reglas operativas.

Buen contenido para CLAUDE.md:

Comandos comunes de build, test y lint.
Reglas de estilo y nombres.
Notas de arquitectura del proyecto.
Límites de módulos y zonas de riesgo.
Convenciones del equipo y flujo de commits.

Si CLAUDE.md se guarda en el repositorio, puede versionarse con Git y compartirse como guía de agente para el equipo. Esto es completamente distinto de la memoria personal en la nube de ChatGPT.

Claude Code Auto Memory: acumular experiencia de proyecto

Claude Code también tiene Auto Memory. Su objetivo es permitir que Claude acumule conocimiento del proyecto entre sesiones sin obligar al usuario a escribir cada nota manualmente.

Según la documentación de Claude Code, Auto Memory permite a Claude guardar notas mientras trabaja, como comandos de build, descubrimientos de depuración, notas de arquitectura, preferencias de estilo y hábitos de workflow. No guarda cada sesión, sino que decide qué puede ser útil más adelante.

Un malentendido común es creer que Auto Memory escribe por defecto en .claude/memory.md dentro de la raíz del proyecto. La documentación oficial dice que cada proyecto tiene su propio directorio de memoria bajo el home del usuario, con una ruta similar a:

`1`	`~/.claude/projects/<project>/memory/`

MEMORY.md carga las primeras 200 líneas o 25KB al inicio de cada conversación, mientras que el contenido detallado puede dividirse en otros archivos temáticos. Los archivos de Auto Memory son Markdown locales, y el usuario puede verlos, editarlos o borrarlos mediante /memory.

Esto hace que la memoria de Claude Code se parezca más a una base local de conocimiento de proyecto. Está más cerca del codebase que la memoria personal de ChatGPT, y es más dinámica que un simple CLAUDE.md.

Pero Auto Memory es local a la máquina. No sigue naturalmente al repositorio hacia otras máquinas o entornos cloud. Para reglas estables compartidas por el equipo, ponlas en el CLAUDE.md del repositorio.

Gemini: alrededor del contexto del ecosistema Google

La lógica de memoria de Gemini vuelve a ser distinta.

Gemini también soporta información guardada y referencias a chats anteriores. Los documentos de ayuda de Google dicen que los usuarios pueden guardar información sobre vida, trabajo o preferencias, y Gemini puede consultar chats pasados antes de responder. Cuando usa esta información, la respuesta puede mostrar fuentes como Your saved info o Previous chats.

Pero la diferenciación de Gemini no es solo “guardar unas preferencias”. Es la integración con el ecosistema Google.

Con autorización del usuario y disponibilidad de funciones, Gemini puede acceder a contexto de apps conectadas de Google como Gmail, Google Drive, Docs y Sheets. Su ventaja no es hacer que el usuario le enseñe cada dato manualmente, sino convertir los datos existentes de la cuenta Google en contexto de trabajo buscable.

Una diferencia típica:

ChatGPT recuerda: “Últimamente he estado reparando una unidad de cinta LTO.”
Gemini puede encontrar el correo de confirmación de compra en Gmail o leer notas de reparación desde Drive.

Esto no significa que Gemini pueda leer todos los datos de Google sin condiciones. Depende del tipo de cuenta, región, permisos, apps conectadas, ajustes de Keep Activity y disponibilidad del producto. Las cuentas empresariales y escolares también pueden estar controladas por administradores de Google Workspace.

Más exactamente, la memoria de Gemini es una combinación de información guardada, chats anteriores y datos conectados del ecosistema Google.

Diferencias centrales

Dimensión	ChatGPT	Claude Code	Gemini
Objeto central	Persona y preferencias	Proyecto y codebase	Cuenta Google y datos del ecosistema
Memoria típica	Preferencias, contexto personal, objetivos de largo plazo	Arquitectura, comandos, convenciones, experiencia de depuración	Información guardada, chats anteriores, contexto de Gmail/Drive/Docs
Forma de almacenamiento	Memoria y contexto de chat en la cuenta OpenAI	`CLAUDE.md`, `MEMORY.md`, archivos Markdown locales	Actividad de cuenta Google, información guardada, datos de apps conectadas
Transparencia	Memory sources muestra parte de la fuente	Los archivos Markdown se pueden abrir y editar	Se gestiona con indicaciones de fuente, Gemini Apps Activity y ajustes Google
Capacidad entre proyectos	Fuerte, sigue a la cuenta de usuario	Débil, principalmente sigue al proyecto o memoria local	Fuerte, depende de datos y permisos de Google
Compartición en equipo	No adecuada para compartir directamente	`CLAUDE.md` puede compartirse por Git	Depende sobre todo de Workspace y permisos
Mejor para	Preferencias personales y comportamiento de asistente a largo plazo	Proyectos de código largos y colaboración con agentes	Recuperación en Google Workspace y trabajo entre herramientas

Cómo elegir

Si quieres que la IA recuerde quién eres, qué estilo prefieres y cómo sueles trabajar, la memoria de ChatGPT es más adecuada.

Sirve para guardar preferencias personales como estilo de escritura, stack técnico, formato de respuesta, contexto profesional y dirección de proyectos de largo plazo. Su foco es reducir el coste de presentarte de nuevo para que cada conversación empiece más rápido.

Si quieres que la IA recuerde cómo debe cambiarse un codebase, qué comandos funcionan y qué trampas evitar, Claude Code es más adecuado.

Pon reglas estables en CLAUDE.md para compartirlas con el equipo. Deja que Auto Memory ayude con experiencia dinámica. Las decisiones importantes deberían organizarse aún en documentación o CLAUDE.md, no quedar solo en memoria automática local.

Si la mayoría de tus materiales viven en Gmail, Drive, Docs y Sheets, el contexto de ecosistema de Gemini tiene ventaja.

Es útil para encontrar correos antiguos, organizar documentos de Drive y conectar calendario y materiales de oficina. La clave al usar Gemini no es recordarle todo repetidamente en chat, sino asegurarse de que las conexiones de apps, permisos y ajustes de actividad relevantes estén correctos.

Una división práctica del trabajo

Puedes dividirlos así:

ChatGPT recuerda preferencias personales generales.
Claude Code recuerda conocimiento de ingeniería para un repositorio.
Gemini recupera materiales de tu ecosistema Google.

En otras palabras, ChatGPT es como un secretario personal, Claude Code como un ingeniero senior dentro del proyecto, y Gemini como un indexador de tu cuenta Google.

No hay ganador absoluto. Tienen objetivos distintos.

El mayor error es mezclarlos. Las preferencias personales no siempre pertenecen a la memoria de proyecto; la arquitectura del proyecto no siempre pertenece a la memoria personal en la nube; y recuperar datos del ecosistema Google no significa que el modelo te entienda de verdad a largo plazo.

Lectura breve

La siguiente etapa de la memoria en IA no es simplemente “recordar más”. La memoria necesita capas, visibilidad y control.

ChatGPT se centra en personalización entre sesiones. Claude Code se centra en continuidad de proyectos de código. Gemini se centra en contexto del ecosistema Google. Una buena colaboración de largo plazo con IA no pone toda la información en una sola caja negra; mantiene cada tipo de memoria en el lugar correcto.

Pon preferencias personales en memoria personal, reglas de ingeniería en el codebase, y materiales históricos en los sistemas originales de documentos y correo. El trabajo de la IA es llamar el contexto correcto cuando hace falta, no mezclar todo en una sola pila.

Enlaces

OpenAI Memory FAQ: https://help.openai.com/en/articles/8590148-memory-faq
ChatGPT Release Notes: https://help.openai.com/en/articles/6825453-chatgpt-release-notes
Claude Code Memory: https://code.claude.com/docs/en/memory
Gemini Saved info: https://support.google.com/gemini/answer/15637730
Gemini Apps Privacy Hub: https://support.google.com/gemini/answer/13594961

Anthropic eleva los límites de uso de Claude y amplía cómputo con SpaceX

Thu, 07 May 2026 14:26:14 +0800

Anthropic anunció el 6 de mayo de 2026 que elevará algunos límites de uso de Claude Code y Claude API, al mismo tiempo que reveló una nueva alianza de cómputo con SpaceX.

En la superficie, esto trata de “más cuota”. La señal más importante es que las empresas de modelos están conectando experiencia de producto, niveles de suscripción, límites de API e infraestructura. Para usuarios intensivos, el cómputo no es abstracto. Determina si pueden ejecutar más tareas de Claude Code, esperar menos y llamar a modelos Opus con más fiabilidad.

Cómo cambian los límites de Claude Code y API

Anthropic anunció tres cambios, todos efectivos desde el día del anuncio.

Primero, los límites de uso de cinco horas de Claude Code se duplican para los planes Pro, Max, Team y Enterprise basados en asientos.

Esto importa directamente a usuarios intensivos de Claude Code. Antes, la lectura continua de código, edición y ejecución de tareas podía chocar rápidamente con el límite de cinco horas. Duplicar el límite permite más trabajo de desarrollo sostenido dentro de la misma ventana de trabajo.

Segundo, las cuentas Pro y Max ya no verán límites reducidos de Claude Code durante horas pico.

Esto es más importante que el número en sí. La parte más frustrante de muchas herramientas de IA no es la cuota normal, sino las ralentizaciones repentinas o límites inestables durante periodos de alta demanda. Eliminar reducciones en horas pico muestra que Anthropic quiere que los usuarios de pago tengan una experiencia más predecible incluso cuando la demanda es alta.

Tercero, Anthropic aumenta de forma considerable los límites de tasa de API para modelos Claude Opus. El artículo original presenta los números detallados en una tabla de imagen; el punto central es que la capacidad API de Opus sube de forma significativa.

Para desarrolladores, Opus es el modelo más caro, pesado y capaz. Límites API más altos para Opus sugieren que Anthropic quiere que más empresas y desarrolladores lo pongan en flujos reales de negocio, no solo que usen Claude en una interfaz de chat.

El peso del acuerdo de cómputo con SpaceX

Los límites más altos están respaldados por nueva oferta de cómputo.

Anthropic dice que firmó un acuerdo con SpaceX para usar toda la capacidad de cómputo del centro de datos Colossus 1 de SpaceX. La alianza proporcionará más de 300 megavatios de nueva capacidad dentro de un mes, equivalentes a más de 220.000 GPU NVIDIA.

Esos números dicen dos cosas.

Primero, el cómputo sigue siendo un cuello de botella para empresas de modelos frontera. Capacidad del modelo, longitud de contexto, uso de herramientas, agentes de programación, multimodalidad y casos empresariales consumen grandes cantidades de recursos de inferencia. Cuantos más usuarios y tareas complejas soporte una plataforma, más suministro GPU estable a gran escala necesita.

Segundo, la competencia de infraestructura de IA entró en una fase de escala masiva. Antes, la atención se centraba más en rankings de modelos, funciones de producto y precios. Ahora, quien pueda asegurar energía, instalaciones, redes y GPU más rápido tendrá más opciones de convertir capacidad de modelo en producto estable.

Anthropic también dice que la capacidad de SpaceX mejorará directamente la capacidad para suscriptores Claude Pro y Claude Max. En otras palabras, no es solo infraestructura de entrenamiento; también apoya inferencia orientada al usuario.

El mapa de cómputo de Anthropic

SpaceX no es el único socio de cómputo de Anthropic.

El anuncio también apunta a varios acuerdos de infraestructura anunciados anteriormente:

Un acuerdo de hasta 5GW con Amazon, incluyendo casi 1GW de nueva capacidad para finales de 2026.
Un acuerdo de 5GW con Google y Broadcom, que se espera empiece a entrar en línea en 2027.
Una alianza estratégica con Microsoft y NVIDIA que incluye 30.000 millones de dólares de capacidad Azure.
Una inversión de 50.000 millones de dólares en infraestructura de IA estadounidense con Fluidstack.

El hilo común es que Anthropic no se está atando a una sola pila de hardware ni a una sola plataforma cloud. El artículo original dice explícitamente que Claude se entrena y ejecuta en AWS Trainium, Google TPUs y GPU NVIDIA.

Esta estrategia multisuministrador es práctica. Es difícil que un solo proveedor cloud satisfaga la demanda de entrenamiento frontera e inferencia a gran escala a largo plazo. Un enfoque multiplataforma aumenta la complejidad de ingeniería, pero reduce riesgos de cadena de suministro y capacidad.

Por qué los límites de uso son realmente un tema de cómputo

Los “límites” de productos de IA no son solo texto de membresía. Se corresponden con costos reales.

Cada vez que Claude Code lee un repositorio, genera un patch o ejecuta una tarea larga, consume recursos de inferencia. Los usuarios de API que ponen Opus en soporte, análisis financiero, revisión de código, procesamiento documental o flujos agentic crean demanda sostenida. Para la plataforma, relajar límites significa tener cómputo más fiable detrás.

La lógica del anuncio es clara: primero explicar que los usuarios reciben límites más altos, luego explicar por qué esos límites pueden subir ahora. La nueva capacidad de SpaceX, junto con alianzas existentes con Amazon, Google, Microsoft, NVIDIA y Fluidstack, soporta un uso más pesado.

Esto también explica por qué los productos de IA enfatizan cada vez más la segmentación. Usuarios Free, Pro, Max, Team y Enterprise consumen cómputo de forma distinta y pagan distinto. Las empresas de modelos tienen que reajustar cuotas, prioridad, acceso a modelos y costos de infraestructura.

La señal del cómputo orbital para IA

El anuncio incluye un detalle futurista: Anthropic dice que también expresó interés en colaborar con SpaceX para desarrollar varios gigavatios de capacidad de cómputo orbital para IA.

Eso no significa que los centros de datos orbitales vayan a convertirse de inmediato en producto. Una lectura más prudente es que las empresas de IA frontera ya están pensando más allá de los centros de datos terrestres para el suministro futuro de cómputo.

Los centros de datos de IA están limitados por energía, terreno, refrigeración, redes y regulación. A medida que crece la demanda de entrenamiento e inferencia, la industria explorará más formas de infraestructura. El cómputo orbital puede sonar distante, pero su aparición en un anuncio oficial de Anthropic ya es una señal: la imaginación alrededor de la competencia por cómputo se está expandiendo.

Expansión internacional y cumplimiento

Anthropic también dice que los clientes empresariales, especialmente en sectores regulados como finanzas, salud y gobierno, necesitan cada vez más infraestructura regional para cumplimiento y residencia de datos.

Eso significa que las empresas de modelos no pueden construir toda la infraestructura en Estados Unidos. La IA empresarial debe manejar cumplimiento regional, residencia de datos, seguridad de cadena de suministro, costos de energía y relaciones con comunidades locales. Anthropic dice que su colaboración con Amazon ya incluye inferencia adicional en Asia y Europa.

También dice que será intencional al añadir capacidad en países democráticos cuyos marcos legales y regulatorios soporten inversión a gran escala y cadenas de suministro seguras, mientras explora formas de extender su compromiso de precio eléctrico de centros de datos de EE. UU. a otras jurisdicciones.

Esto muestra que la infraestructura de IA no es solo un tema técnico. Cada vez es más un asunto de energía, manufactura y economía geopolítica.

Resumen

El anuncio de Anthropic se puede resumir de forma simple: los límites de Claude suben porque nueva capacidad de cómputo a gran escala está entrando en línea.

Para usuarios, los efectos de corto plazo son límites de cinco horas más altos en Claude Code, menos reducciones en horas pico para Pro y Max, y más margen API para Opus. Para la industria, el punto mayor es que la competencia de modelos se está expandiendo de “quién tiene el modelo más fuerte” a “quién puede asegurar continuamente suficiente cómputo estable y compatible”.

La experiencia futura de productos de IA puede diferir no solo por parámetros de modelo y diseño de producto, sino también por capacidad de infraestructura. Quien pueda organizar energía, GPU, centros de datos, alianzas cloud y cumplimiento regional tendrá más opciones de convertir modelos frontera en servicios de largo plazo.

Enlaces

Anuncio de Anthropic: https://www.anthropic.com/news/higher-limits-spacex

CC Switch: una herramienta de escritorio para gestionar Claude Code, Codex, Gemini CLI y OpenClaw en un solo lugar

Wed, 06 May 2026 09:03:08 +0800

CC Switch es una herramienta de gestión de escritorio para usuarios intensivos de programación con IA. El problema que intenta resolver es directo: muchas personas ahora usan Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw al mismo tiempo, pero cada herramienta tiene su propio formato de configuración, sintaxis de Provider, configuración MCP y forma de gestionar Skills.

Cuando solo usas una herramienta, editar archivos de configuración manualmente todavía es tolerable. Una vez que se mezclan varias herramientas, además de cuentas oficiales, APIs de terceros, servicios relay, modelos locales y configuración compartida de equipo, editar JSON, TOML y archivos .env a mano se vuelve tedioso rápidamente.

CC Switch se posiciona como una forma de reunir estas configuraciones dispersas en una sola app de escritorio multiplataforma.

Qué problema resuelve

Las herramientas modernas de programación con IA se sienten cada vez más como “colegas de desarrollo dentro de la línea de comandos”, pero sus ecosistemas aún no están completamente unificados.

Los puntos de dolor comunes incluyen:

Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw usan formatos de configuración distintos.
Cambiar API Providers requiere editar repetidamente archivos de configuración.
Los servidores MCP se configuran una y otra vez en distintas herramientas.
Archivos de prompt como CLAUDE.md, AGENTS.md y GEMINI.md son difíciles de mantener de forma consistente.
Instalación, sincronización, respaldo y eliminación de Skills carecen de una entrada central.
Cambiar entre múltiples cuentas, relays y servicios de modelos puede volverse confuso fácilmente.
Cuando un archivo de configuración editado a mano se rompe, depurarlo cuesta tiempo.

La idea detrás de CC Switch es dejar de obligar a los usuarios a recordar los detalles de configuración de cada herramienta, y usar una interfaz unificada para gestionar Providers, MCP, Prompts, Skills, Sessions y proxies.

Herramientas soportadas

El README enumera cinco objetivos principales soportados:

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

Estas herramientas son similares en posicionamiento: todas se centran en programación con IA, flujos Agent y colaboración por línea de comandos. Pero sus sistemas de configuración difieren, y el valor de CC Switch está en envolver esas diferencias.

Para quienes comparan con frecuencia distintas herramientas de programación con IA, esto es mucho más fácil que abrir manualmente archivos de configuración cada vez.

Gestión de Providers

La primera capa de CC Switch es la gestión de Providers.

Incluye más de 50 presets de Provider. El README menciona direcciones como AWS Bedrock, NVIDIA NIM y varios relays comunitarios. Los usuarios pueden copiar una API key, importarla con un clic y luego cambiar desde la interfaz.

Los puntos prácticos incluyen:

Añadir Providers con un clic.
Reordenar Providers arrastrando.
Cambiar rápidamente desde la bandeja del sistema.
Importar y exportar Providers.
Sincronizar algunos Providers comunes entre varias apps.

Para muchas personas, esta función por sí sola ya es atractiva. En el trabajo diario de programación con IA, el problema muchas veces no es “no sé usar el modelo”, sino “qué herramienta, endpoint y cuenta debería usar hoy esta key”.

Proxy local y failover

Además de escribir archivos de configuración, CC Switch también proporciona un modo de proxy local.

El foco de esta capacidad es:

Cambio en caliente de Providers.
Conversión de formatos.
Failover automático.
Circuit breakers.
Health checks de Providers.
Corrección de solicitudes.

En términos simples, no solo escribe configuración en herramientas objetivo. También puede añadir una capa de proxy local en el medio, para que distintas herramientas accedan a servicios de modelos mediante el proxy.

Esto es útil para usuarios con múltiples Providers: si un servicio cae, cambiar a otro; si un modelo es caro, pasar a uno más barato; si el formato de solicitud es incompatible, adaptarlo mediante la capa de proxy.

MCP, Prompts y Skills

La segunda capa importante de CC Switch es la gestión unificada de MCP, Prompts y Skills.

MCP

Proporciona un panel MCP unificado para gestionar servidores MCP entre varias apps, con soporte para sincronización bidireccional e importación mediante Deep Link.

Esto es práctico para usuarios que ya trabajan con MCP. Cuando hay muchos servidores MCP, la configuración se dispersa fácilmente entre distintos clientes. Un panel unificado reduce la configuración duplicada y facilita la migración.

Prompts

La sección Prompts soporta edición Markdown y puede sincronizar archivos correspondientes entre distintas herramientas, como:

CLAUDE.md
AGENTS.md
GEMINI.md

Estos archivos son esencialmente manuales de proyecto para Agents. La gestión unificada facilita mantener reglas de equipo, convenciones de proyecto y prompts globales.

Skills

Las Skills pueden instalarse con un clic desde repositorios GitHub o archivos ZIP. También se soportan gestión de repositorios personalizados, enlaces simbólicos y copia de archivos.

Si usas herramientas como Claude Code, Codex y OpenClaw al mismo tiempo, las Skills pueden convertirse fácilmente en archivos dispersos por distintos directorios. CC Switch las centraliza y reduce el costo de mantenimiento.

Sesiones y workspace

El README también menciona funciones de Session Manager y Workspace.

Puede explorar, buscar y restaurar historial de sesiones de varias apps. Para personas que usan herramientas de programación con IA durante mucho tiempo, la gestión de sesiones es realmente importante: muchos contextos valiosos, rastros de depuración y comparaciones de soluciones quedan enterrados en conversaciones antiguas.

También proporciona un editor de Workspace para OpenClaw, permitiendo editar archivos de agente como AGENTS.md y SOUL.md con vista previa Markdown.

Esto muestra que CC Switch no es solo una pequeña utilidad para “cambiar keys”. Se está expandiendo hacia una estación de trabajo para AI Agent.

Sincronización en la nube y almacenamiento de datos

CC Switch soporta sincronizar datos de Providers mediante Dropbox, OneDrive, iCloud, NAS o WebDAV.

El almacenamiento local de datos también está claramente definido:

Base de datos: ~/.cc-switch/cc-switch.db
Configuración local: ~/.cc-switch/settings.json
Copias automáticas: ~/.cc-switch/backups/
Skills: ~/.cc-switch/skills/
Copias de Skills: ~/.cc-switch/skill-backups/

Usa SQLite como fuente principal de datos y enfatiza escrituras atómicas y copias automáticas, con el objetivo de evitar corrupción de archivos de configuración durante cambios o escrituras.

Este diseño importa para usuarios intensivos. Si la herramienta de gestión de configuración escribe una mala configuración, todas las herramientas de programación con IA pueden verse afectadas.

Instalación

CC Switch es una app de escritorio multiplataforma construida sobre Tauri 2.

Los requisitos aproximados del sistema son:

Windows: Windows 10 o posterior
macOS: macOS 12 Monterey o posterior
Linux: Ubuntu 22.04+, Debian 11+, Fedora 34+ y otras distribuciones principales

Los usuarios de Windows pueden descargar el instalador .msi o un paquete comprimido portable.

Los usuarios de macOS pueden instalarlo con Homebrew:

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

Para actualizar:

`1`	`brew upgrade --cask cc-switch`

Los usuarios de Linux pueden elegir .deb, .rpm o AppImage. Los usuarios de Arch Linux también pueden instalarlo con paru -S cc-switch-bin.

Al 6 de mayo de 2026, la página del repositorio muestra la última release como CC Switch v3.14.1, publicada el 23 de abril de 2026.

Stack técnico

Por la estructura del repositorio, CC Switch es una app de escritorio Tauri típica:

Frontend: React 18, TypeScript, Vite, TailwindCSS, TanStack Query, shadcn/ui
Backend: Tauri 2, Rust, SQLite, Tokio
Testing: Vitest, MSW, Testing Library

Los patrones de diseño principales incluyen:

SQLite como Single Source of Truth.
JSON para configuración local a nivel de dispositivo.
Escritura en la configuración viva de herramientas objetivo durante el cambio.
Rellenar ediciones del Provider actual desde la configuración viva.
Escrituras atómicas usando archivos temporales más rename.
Conexiones de base de datos bloqueadas para evitar problemas de escritura concurrente.

Esta arquitectura sugiere que el proyecto no es un script simple, sino una herramienta de escritorio diseñada para uso de largo plazo.

Para quién es

CC Switch encaja con estos usuarios:

Personas que usan Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw juntas.
Personas que cambian con frecuencia entre cuentas oficiales, relays de terceros, modelos locales o Providers de equipo.
Usuarios que ya usan MCP intensivamente.
Equipos que quieren mantener CLAUDE.md, AGENTS.md y GEMINI.md en un solo lugar.
Usuarios que instalan, prueban y migran Skills con frecuencia.
Personas que quieren ver historial de sesiones y uso entre distintas herramientas.

Si solo usas una herramienta de programación con IA, dependes del login oficial y rara vez tocas Providers, MCP o Skills, su valor puede no ser evidente.

Pero si ya entraste en un estado de “muchas herramientas, muchas cuentas, muchos Providers, muchos proyectos”, puede eliminar mucho trabajo repetitivo de configuración.

Qué vigilar

Herramientas como esta son cómodas, pero también necesitan límites claros.

Primero, gestiona configuración para múltiples AI CLIs, así que los usuarios deben asegurarse de confiar en la herramienta y su lógica de escritura.

Segundo, API keys, endpoints relay y servidores MCP son configuración sensible. Antes de activar sincronización en la nube, asegúrate de que la carpeta de sincronización y el servicio WebDAV sean seguros y confiables.

Tercero, después de cambiar Providers, la mayoría de herramientas todavía necesitan reiniciar la terminal o CLI para que los cambios surtan efecto. El README menciona que Claude Code soporta cambio en caliente de datos de Provider, pero otras herramientas normalmente aún requieren reinicio.

Cuarto, al volver al login oficial, es mejor añadir el provider oficial según las instrucciones del proyecto y luego volver a ejecutar el flujo de login de la herramienta correspondiente.

Resumen

El valor de CC Switch no está en crear otra herramienta de programación con IA. Su valor está en reconocer una realidad: el ecosistema de AI coding entró en una etapa donde coexisten múltiples herramientas.

Claude Code, Codex, Gemini CLI, OpenCode y OpenClaw tienen cada una sus propios sistemas de configuración, mientras MCP, Skills, Prompts y Providers se expanden rápidamente. Seguir editando archivos de configuración a mano terminará convirtiéndose en una carga.

CC Switch reúne estas piezas en una app de escritorio, facilitando cambiar Providers, sincronizar MCP, gestionar Skills, mantener archivos de prompt y ver sesiones. Para usuarios intensivos de programación con IA, herramientas como esta pueden pasar de “utilidad opcional” a “infraestructura diaria”.

Referencias

farion1231/cc-switch

free-claude-code: conectar Claude Code a OpenRouter, DeepSeek y modelos locales mediante un proxy

Fri, 01 May 2026 03:41:49 +0800

free-claude-code es un Anthropic-compatible proxy para usar con Claude Code.

La idea no es crackear Claude Code ni ofrecer un servicio Claude oficial gratuito, sino iniciar localmente un proxy compatible con la forma de la API de Anthropic y reenviar las solicitudes de Claude Code a otros backends de modelos. El README menciona backends como NVIDIA NIM, OpenRouter, DeepSeek, LM Studio, llama.cpp y Ollama.

En pocas palabras, resuelve este problema: te gusta la experiencia de Claude Code en la terminal, pero quieres conectar las peticiones del modelo a otro provider o a un modelo local.

Qué problema resuelve

La experiencia interactiva de Claude Code es muy adecuada para tareas de desarrollo.

Puede leer código en la terminal, modificar archivos, ejecutar comandos y avanzar según el contexto del proyecto. El problema es que muchos usuarios no necesariamente quieren usar siempre el mismo backend de modelo:

Quieren probar distintos modelos en OpenRouter
Quieren usar modelos como DeepSeek para reducir costes
Quieren conectar las peticiones a Ollama local
Quieren ejecutar modelos locales con LM Studio o llama.cpp
Quieren unificar en el entorno de desarrollo una entrada de proxy
Quieren comparar el rendimiento de distintos modelos dentro del flujo de Claude Code

El posicionamiento de free-claude-code es añadir una capa de proxy compatible entre Claude Code y estos servicios de modelos.

Así, Claude Code sigue enviando solicitudes con estilo Anthropic, y el proxy se encarga de adaptarlas a distintos backends.

Funcionamiento

Puede entenderse como tres capas:

El frontend es Claude Code
En medio está el proxy free-claude-code
El backend es OpenRouter, DeepSeek, un modelo local u otro servicio de modelo

Claude Code cree que está accediendo a una API Anthropic-compatible.

El proxy recibe la solicitud, elige el provider objetivo según la configuración, transforma los campos necesarios y devuelve la respuesta a Claude Code.

La ventaja de esta estructura es que no necesitas modificar Claude Code ni exigir que cada servicio de modelo soporte Claude Code de forma nativa. Mientras el proxy pueda alinear la interfaz, puede conectar más modelos al mismo flujo de trabajo.

Backends soportados

Las direcciones listadas en el README incluyen:

NVIDIA NIM
OpenRouter
DeepSeek
LM Studio
llama.cpp
Ollama

Estos backends representan varias formas de uso.

OpenRouter se parece más a una entrada agregadora de modelos, útil para probar distintos modelos comerciales y open source.

DeepSeek conviene a quienes se preocupan por capacidad en chino, capacidad de código y coste.

LM Studio, llama.cpp y Ollama se inclinan hacia la ruta de modelos locales. Sirven para ejecutar modelos en tu propia máquina o en un entorno de intranet, reducir dependencia de APIs externas y facilitar experimentos offline.

NVIDIA NIM está más orientado a inferencia empresarial y despliegue con GPU.

Por qué un Anthropic-compatible proxy

Claude Code está diseñado alrededor de la interfaz y los hábitos de modelo de Anthropic.

Si quieres conectarlo a otros modelos, el problema más directo es que las interfaces no coinciden:

Campos de solicitud distintos
Nombres de modelo distintos
Formatos de streaming distintos
Expresión de tool use distinta
Formatos de error distintos
Límites de tokens y contexto distintos

El valor de la capa proxy está ahí.

Mantiene la interfaz vista por Claude Code con una forma cercana a Anthropic y adapta el backend. Para el usuario, después de configurar el proxy, puede probar distintos modelos dentro del mismo flujo de Claude Code.

Escenarios adecuados

free-claude-code es adecuado para:

Querer usar el flujo de terminal de Claude Code
Probar modelos no Anthropic dentro de Claude Code
Reducir costes de llamadas de modelo
Conectar Claude Code a OpenRouter
Integrar DeepSeek u otros servicios de modelo compatibles
Usar Ollama, LM Studio o llama.cpp para ejecutar modelos locales
Configurar para un equipo una entrada unificada de proxy de modelos

Si solo usas Claude Code oficial normalmente y no tienes necesidades especiales de provider, coste o despliegue local, quizá no necesites este tipo de proxy.

Pero si comparas modelos con frecuencia o quieres que Claude Code acceda a modelos locales y de terceros, este tipo de herramienta es útil.

Diferencia frente a usar directamente OpenRouter u Ollama

Usar directamente OpenRouter, Ollama o LM Studio normalmente significa conversar con el modelo o llamarlo mediante API.

El punto central de free-claude-code no es sustituir esos servicios, sino conectarlos al flujo de desarrollo de Claude Code.

La diferencia está en:

Sigues usando la experiencia de terminal de Claude Code
La IA puede realizar tareas alrededor del repositorio de código
El backend de modelo puede cambiarse por otro provider
Los modelos locales también tienen oportunidad de entrar en el flujo de Claude Code
La configuración se concentra en la capa proxy, no se cambia por separado en cada herramienta

Por eso se parece más a un puente que a un nuevo cliente de chat.

Precauciones con modelos locales

Conectar Claude Code a modelos locales es atractivo, pero también tiene límites prácticos.

Primero, diferencia de capacidad del modelo.

Las tareas de Claude Code no son solo chat; incluyen entender código, planificar cambios, editar archivos y procesar salidas de comandos. Un modelo local pequeño no necesariamente puede completar estas tareas de forma estable.

Segundo, ventana de contexto.

Las tareas de código consumen mucho contexto. Si la ventana del modelo es demasiado pequeña, puede no leer archivos completos, perder restricciones o olvidar contexto durante varias rondas.

Tercero, compatibilidad con tool use.

El flujo de Claude Code depende de llamadas a herramientas y comportamiento estructurado. Aunque un backend pueda chatear, no necesariamente sigue bien protocolos de tool calling.

Cuarto, velocidad y hardware.

La velocidad del modelo local depende de la máquina, el método de cuantización y el tamaño del modelo. Si una tarea de código responde demasiado lento, la experiencia se degrada de forma notable.

Por eso, los modelos locales son más adecuados para experimentos, tareas de bajo riesgo y escenarios concretos. Para tareas de código realmente complejas, todavía hay que elegir con cuidado según la capacidad del modelo.

Límites de uso

Este tipo de proyecto puede malinterpretarse fácilmente por el título, así que conviene aclarar los límites.

Primero, no es cuota gratuita oficial de Claude Code.

Solo reenvía las solicitudes de Claude Code a otros backends de modelos. Al usar OpenRouter, DeepSeek, NVIDIA NIM u otras APIs, sigues teniendo que cumplir precios, cuotas y condiciones de uso de esos servicios.

Segundo, no es una herramienta para saltarse autorización.

Al usar cualquier proxy, hay que cumplir las licencias y términos de Claude Code, del proveedor de modelo y del propio proyecto. No debería entenderse como una forma de evitar restricciones oficiales.

Tercero, el proxy procesará el contenido de tus solicitudes.

Código, salida de comandos y contexto del proyecto pueden pasar por el proxy y por el servicio backend. Al desplegarlo, hay que considerar logs, claves, red y límites de privacidad. Para código de empresa o proyectos sensibles, es mejor usar un entorno controlado.

Cuarto, el rendimiento de distintos modelos puede variar mucho.

La misma operación de Claude Code puede comportarse de forma completamente distinta al cambiar de modelo. No asumas que todos los modelos pueden sustituir a Claude.

Relación con proxies como LiteLLM

Desde el punto de vista de diseño, free-claude-code pertenece a la categoría de “proxies de interfaz compatible”.

El objetivo común de estas herramientas es reducir el acoplamiento entre la aplicación superior y los servicios de modelos inferiores. La aplicación superior solo se enfrenta a una interfaz relativamente unificada, y los providers de abajo pueden cambiarse por configuración.

Cada proyecto tiene un foco distinto. Algunos se orientan a gateway de modelos general, otros a OpenAI-compatible API, y otros se adaptan específicamente a herramientas como Claude Code.

Lo interesante de free-claude-code es que coloca el escenario objetivo directamente en Claude Code, no en un proxy de chat genérico.

Usuarios adecuados

Es más adecuado para usuarios con cierta capacidad de configuración:

Conocen Claude Code
Saben configurar API key y provider de modelos
Entienden cómo arrancar un proxy y variables de entorno
Pueden diagnosticar problemas de red, puertos, nombres de modelo y streaming
Quieren comparar el rendimiento de distintos modelos en tareas de código

Si solo quieres algo listo para usar, la configuración oficial suele ser más tranquila.

Si estás dispuesto a montar proxy, cambiar modelos, ajustar parámetros y quieres llevar Claude Code a más entornos de modelo, este proyecto merece estudio.

Referencia

Alishahryar1/free-claude-code

Una última frase

El valor de free-claude-code no está en la palabra “free”, sino en construir un puente entre Claude Code y más backends de modelos.

Cuando quieres conservar la experiencia de desarrollo de Claude Code y al mismo tiempo probar OpenRouter, DeepSeek, modelos locales o servicios de inferencia empresariales, este tipo de Anthropic-compatible proxy tiene sentido.

Compound Engineering Plugin: convertir la programación con IA en un ciclo de planificación, ejecución y revisión

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin es un plugin de flujo de trabajo de programación con IA publicado como open source por Every Inc.

No se centra en “hacer que la IA escriba un fragmento de código más rápido”, sino en colocar la programación con IA dentro de un ciclo más parecido al de un equipo de ingeniería: primero planificar, luego implementar, después revisar y finalmente conservar la experiencia aprendida. Para quienes usan con frecuencia herramientas como Claude Code, Codex, Cursor o Copilot, este tipo de plugin resuelve un problema de flujo de trabajo, no solo de prompts.

Las herramientas de programación con IA son cada vez más fuertes, pero en proyectos reales lo más difícil no suele ser generar código, sino lograr que siga de forma continua las reglas del proyecto, entienda los límites de la tarea, evite repetir errores y acumule contexto durante iteraciones largas.

Qué problema resuelve

Muchas personas usan asistentes de programación con IA más o menos así:

Describen directamente el requisito
Dejan que la IA modifique código
Miran si el resultado puede ejecutarse
Si hay error, añaden más instrucciones
En la siguiente tarea vuelven a explicar desde cero

Este método puede completar tareas pequeñas, pero en proyectos complejos aparecen problemas con facilidad:

El requisito no se divide primero con claridad y la IA empieza a modificar directamente
Falta una review sistemática después de los cambios
Las reglas del proyecto dependen de que el usuario las recuerde una y otra vez
El mismo tipo de error vuelve a aparecer en la siguiente ocasión
Falta un método de trabajo común entre varias herramientas Agent
La experiencia no se convierte en reglas reutilizables

Compound Engineering Plugin quiere resolver precisamente estos problemas. Divide la programación con IA en varias etapas, para que el Agent no solo ejecute comandos, sino que participe en un proceso de ingeniería más completo.

Qué es Compound Engineering

Según la descripción del README del proyecto, Compound Engineering puede entenderse como un método de desarrollo de software asistido por IA.

Destaca un ciclo:

Planificación: entender primero el objetivo, dividir tareas y confirmar la ruta
Ejecución: modificar código según el plan, ejecutar comandos y tratar problemas
Revisión: comprobar calidad de implementación, riesgos y cobertura de pruebas
Aprendizaje: convertir la experiencia en reglas reutilizables para el futuro

Este ciclo se parece mucho a la forma de trabajo de un equipo de ingeniería real.

Un ingeniero fiable no recibe un requisito y empieza a cambiar cosas sin rumbo, ni entrega directamente después de modificar. Primero evalúa el alcance de impacto, luego implementa, después revisa riesgos y resultados de pruebas, y finalmente registra los problemas encontrados. Los AI Agent también necesitan restricciones similares.

Por qué hace falta un plugin

Un prompt puede decirle a la IA “planifica antes de ejecutar”, pero el prompt por sí mismo no siempre es estable.

Cuando la conversación se alarga y el contexto se vuelve complejo, el modelo puede saltarse la planificación, ignorar reglas o volverse demasiado confiado para terminar la tarea. El valor del plugin está en fijar el proceso para que distintos entornos Agent sigan un método parecido.

Este tipo de plugin suele dividir el flujo de trabajo en comandos, reglas, plantillas o subprocesos. El usuario no necesita escribir cada vez un prompt completo, sino que activa una etapa mediante una entrada fija.

Por ejemplo:

Pedir primero al Agent que genere un plan
Implementar después paso a paso según el plan
Activar review tras terminar los cambios
Volver a corregir cuando se encuentren problemas
Escribir las experiencias valiosas en memoria o reglas

Esto hace que la programación con IA se parezca más a una “colaboración controlada” que a una conversación de una sola vez.

Qué entornos Agent soporta

El README menciona que el proyecto soporta varios entornos de programación con IA, incluyendo:

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

Este punto es importante.

Muchas herramientas de flujo de trabajo están atadas a un solo cliente; al cambiar de herramienta, las reglas dejan de reutilizarse. Compound Engineering Plugin se parece más a un método de ingeniería transversal a distintos Agent, llevando procesos similares de planificación, ejecución y revisión a varias herramientas.

Si usas varios asistentes de programación con IA al mismo tiempo, este tipo de flujo unificado gana valor. Las herramientas tienen capacidades distintas, pero las normas del proyecto, los hábitos de review y el método de división de tareas deberían ser lo más consistentes posible.

Para qué sirve la etapa de planificación

El valor de la planificación es evitar que la IA actúe demasiado pronto.

En tareas complejas, las preguntas realmente importantes suelen ser:

Qué archivos hay que modificar
Qué módulos pueden verse afectados
Cuál es el patrón existente
Si hay pruebas
Dónde están los riesgos
Si hay que leer documentación antes
Si puede dividirse en pasos más pequeños

Si el Agent no piensa primero estas preguntas y se pone a escribir código directamente, es fácil que produzca una implementación que parece terminada, pero que se aleja de la estructura del proyecto.

El plan no tiene que ser largo. Un buen plan debería ser corto, concreto y ejecutable. Su objetivo no es fabricar documentación, sino dar límites a la implementación posterior.

Qué evitar en la etapa de ejecución

Cuando la IA ejecuta tareas de código, aparecen con facilidad varios problemas:

Refactorizar código no relacionado de paso
Sobrescribir cambios existentes del usuario
Cambiar solo el happy path
Ignorar manejo de errores
No seguir el estilo existente del proyecto
No ejecutar validaciones necesarias
Probar a ciegas tras encontrar errores

Un plugin de flujo de trabajo no puede garantizar que estos problemas desaparezcan por completo, pero puede reducir su frecuencia mediante reglas y restricciones por etapa.

Por ejemplo, la etapa de ejecución puede pedir al Agent que avance paso a paso según el plan; si descubre algo fuera del alcance previsto, primero explica el riesgo; si modifica módulos compartidos, añade pruebas o al menos ejecuta validaciones relacionadas.

Esta restricción es especialmente importante en codebases grandes. Cuanto más rápido escribe código la IA, más necesita un proceso que limite su inercia.

Por qué importa la etapa de review

Muchos fallos de programación con IA no ocurren porque el código no pueda ejecutarse en absoluto, sino porque los detalles están mal:

No se tratan condiciones límite
Las actualizaciones de estado no son consistentes
El contrato de API se cambia en silencio
Las pruebas no cubren rutas clave
Los mensajes de error no son claros
No se mencionan riesgos de rendimiento o seguridad

La etapa de review cambia al Agent de “modo autor” a “modo revisor”.

El modo autor tiende a justificar su propia implementación; el modo revisor debe buscar activamente defectos, riesgos de regresión y pruebas omitidas. Separar estas dos etapas suele ser más fiable que pedir en una misma respuesta que implemente y se autoevalúe.

Para el usuario, la salida de review también es más valiosa. Ayuda a decidir rápidamente si este cambio merece integrarse o si necesita otra ronda de trabajo.

El sentido de aprendizaje y memoria

La palabra “Compound” del nombre del proyecto sugiere una idea importante: la experiencia de ingeniería debería crecer con efecto compuesto.

Si cada vez que la IA comete un error solo lo arregla en ese momento, pero la próxima vez comete el mismo error, la mejora de eficiencia es limitada. Un mejor método es conservar la experiencia útil:

Convenciones de directorios del proyecto
Métodos de diagnóstico para ciertos errores
Comandos de prueba y precauciones
Archivos generados que no deben tocarse
Preferencias de estilo de código
Patrones de implementación habituales

Estas experiencias pueden convertirse en reglas, memoria, documentación o plantillas. En tareas posteriores, el Agent lee primero ese conocimiento acumulado y luego empieza a trabajar.

Esa es la clave para que la programación con IA pase de “pregunta y respuesta puntual” a “colaboración de largo plazo”.

Escenarios adecuados

Compound Engineering Plugin es adecuado para:

Usar AI Agent para escribir código de forma continua
Modificar un mismo proyecto durante muchas rondas
Querer que la IA planifique antes de implementar
Querer que después de modificar entre automáticamente en mentalidad de review
Equipos que quieren unificar el flujo de programación con IA
Personas que usan a la vez Claude Code, Codex, Cursor y otras herramientas
Querer convertir experiencia del proyecto en reglas reutilizables

Si solo pides ocasionalmente a la IA que escriba un pequeño script, el flujo completo puede parecer pesado.

Pero si estás tratando al asistente de programación con IA como un compañero diario de desarrollo, el ciclo de planificación, ejecución, revisión y aprendizaje se vuelve claramente útil.

Diferencia frente a plantillas de prompt comunes

Las plantillas de prompt comunes suelen resolver “cómo expresar bien la tarea”.

Por ejemplo:

Piensa paso a paso
Lee primero los archivos
Mantén el estilo de código
Ejecuta pruebas
Resume los cambios

Estas indicaciones son útiles, pero siguen dependiendo de que el usuario las use correctamente cada vez.

Compound Engineering Plugin se sitúa más en la capa de flujo de trabajo. Organiza estos requisitos en un proceso repetible y lo adapta a distintas herramientas Agent. Así, no partes de cero escribiendo prompts cada vez, sino que avanzas dentro de un proceso.

En pocas palabras, una plantilla de prompt se parece a un recordatorio; un plugin de flujo de trabajo se parece a un sistema.

Precauciones al usarlo

Primero, no conviertas el proceso en una carga.

Las tareas pequeñas no siempre necesitan un plan completo y una review larga. Un buen flujo de trabajo debería ajustarse a la complejidad de la tarea: resolver rápido los problemas simples y usar el ciclo completo en problemas complejos.

Segundo, la review no sustituye a las pruebas.

Una review hecha por Agent puede encontrar muchos problemas, pero aun así puede omitir errores reales de ejecución. El juicio final depende de pruebas, type checking, resultados de build y revisión humana.

Tercero, hay que limpiar reglas de forma continua.

Acumular experiencia es importante, pero demasiadas reglas también se convierten en ruido. Reglas obsoletas, repetidas o que solo servían para una tarea puntual deberían ordenarse periódicamente.

Cuarto, consistencia entre herramientas no significa identidad total.

Claude Code, Codex, Cursor, Copilot y otras herramientas tienen capacidades e interacciones diferentes. Lo que se unifica es el método de trabajo, no necesariamente cada comando ni cada detalle de configuración.

Qué equipos pueden aprovecharlo

Si un equipo ya permite que AI Agent modifique código real, no basta con discutir “qué modelo es más fuerte”.

Debería preocuparse más por:

Si la IA entiende la tarea antes de modificar
Si respeta límites del proyecto mientras modifica
Si revisa riesgos activamente después de modificar
Si aprende de errores históricos
Si el equipo tiene una norma común de uso de Agent

Ahí está el sentido de proyectos como Compound Engineering Plugin. Llevan la programación con IA desde una habilidad personal hacia un proceso reutilizable por el equipo.

Referencia

EveryInc/compound-engineering-plugin

Una última frase

Lo que merece atención de Compound Engineering Plugin no es que añada un comando más de programación con IA, sino que organiza la programación con IA como un proceso de ingeniería que puede mejorar en ciclos.

Cuando los AI Agent empiezan a participar en proyectos reales, planificación, ejecución, revisión y acumulación de experiencia importan más que generar código una sola vez.

Dominio de los ganchos de Claude Code: una introducción a los 13 eventos del ciclo de vida de los ganchos y al control de automatización

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery es un proyecto de aprendizaje centrado en Claude Code Hooks.

No es sólo una colección de guiones dispersos. Explica el ciclo de vida del gancho de Claude Code, los métodos de configuración, los patrones de script y los escenarios de automatización comunes en un solo lugar. Para las personas que quieren que Claude Code sea más controlable y más parecido a un asistente de ingeniería, vale la pena leer este tipo de material.

Claude Code ya puede leer código, editar archivos y ejecutar comandos de forma predeterminada. Pero si desea que verifique permisos automáticamente, bloquee operaciones riesgosas, inyecte reglas de proyecto, ejecute pruebas o le recuerde las convenciones del equipo en momentos específicos, las instrucciones de chat por sí solas no son lo suficientemente estables. El valor de los ganchos es que convierten las “reglas que necesito recordarle a la IA cada vez” en un flujo de trabajo ejecutable.

Qué problemas resuelven los ganchos

Después de usar Claude Code por un tiempo, los puntos débiles comunes incluyen:

Cada nueva sesión necesita repetir las mismas reglas del proyecto.
Te preocupa que pueda ejecutar comandos que no debería ejecutar.
Quieres verificaciones antes y después de la edición de archivos.
Quiere formatear, realizar pruebas o realizar análisis de seguridad antes de confirmar
Quieres que las convenciones del equipo sean un flujo de trabajo fijo en lugar de recordatorios verbales.
Quiere contexto antes y después de las llamadas a herramientas para iniciar sesión o bloquear
Quiere que tareas complejas activen subagentes o scripts dedicados

Los ganchos están diseñados para estas “acciones automáticas en momentos fijos”.

Puedes considerarlos como enlaces de eventos en el flujo de trabajo de Claude Code. Cuando se inicia una sesión, un usuario envía un mensaje, el modelo está a punto de llamar a una herramienta, finaliza una llamada a una herramienta o un agente está a punto de detenerse, Claude Code puede ejecutar los scripts que usted configuró.

Los 13 eventos del ciclo de vida del gancho

Uno de los puntos principales del proyecto README es que cubre sistemáticamente los 13 eventos de gancho del Código Claude.

Estos eventos abarcan varias etapas, desde el inicio de la sesión hasta las llamadas a las herramientas, y desde la entrada del usuario hasta la terminación del agente. Por finalidad, se pueden agrupar a grandes rasgos como:

Inicio de sesión: inicializa el entorno e inyecta el contexto del proyecto.
Entrada del usuario: inspeccionar indicaciones, agregar reglas y realizar auditorías
Antes de las llamadas a la herramienta: comprobaciones de permisos, bloqueo de comandos y validación de seguridad.
Después de las llamadas a la herramienta: registrar resultados, activar el formateo y ejecutar la verificación
Finalización de tareas: resumir, limpiar, notificar o guardar estado

Este diseño de ciclo de vida significa que no es necesario incluir todas las reglas en un mensaje muy largo.

Por ejemplo, el control de permisos debe realizarse antes de las llamadas a la herramienta. Las comprobaciones de formato son mejores después de editar los archivos. La inyección de reglas del proyecto es mejor al inicio de la sesión o después de la entrada del usuario. Poner reglas en el punto de enlace correcto suele ser más confiable que meter todo en un indicador del sistema.

Dónde vive la configuración

Los ganchos de Claude Code generalmente se configuran a través de archivos de configuración.

Las ubicaciones comunes incluyen:

Configuración a nivel de usuario: ~/.claude/settings.json
Configuración a nivel de proyecto: .claude/settings.json

La configuración a nivel de usuario es buena para las preferencias personales, como reglas generales de seguridad, bloqueo de comandos y rutas de registro.

La configuración a nivel de proyecto es mejor para reglas específicas del repositorio, como qué pruebas se deben ejecutar, qué directorios no se pueden editar, cómo se manejan los archivos generados y qué comprobaciones se requieren antes de la confirmación. Si usa Claude Code en un equipo, es mejor colocar la configuración a nivel de proyecto en el repositorio. De esa manera, todos inician el proyecto con las mismas limitaciones de colaboración de IA en lugar de depender de la memoria personal.

Por qué son importantes los scripts de un solo archivo

El proyecto enfatiza los scripts de un solo archivo “UV”.

El beneficio es una implementación simple. Un único archivo Python puede declarar dependencias y ejecutarse sin mantener un entorno complejo para un enlace. Esto encaja bien con los ganchos porque muchos ganchos solo hacen una pequeña cosa:

Comprobar si un comando está permitido
Determinar si la ruta de un archivo es segura
Leer las reglas del proyecto y devolvérselas a Claude.
Escanear la salida en busca de información confidencial
Ejecutar formateo o pruebas después de las ediciones.
Escribir eventos en registros.

Cuanto más pequeño sea un script de enlace, más fácil será de mantener y es menos probable que se convierta en un sistema nuevo y complicado.

¿Qué pueden hacer los ganchos con la automatización?

claude-code-hooks-mastery muestra muchas direcciones. En el trabajo real, los más comunes se encuentran a continuación.

1. Control de permisos y seguridad

Este es el uso más directo de los ganchos.

Antes de que Claude Code ejecute un comando, un gancho puede inspeccionar el contenido del comando. Si contiene acciones de alto riesgo, como eliminar, restablecer, limpiar o sobrescribir, puede bloquear la ejecución o requerir confirmación manual.

Se pueden aplicar reglas similares a las rutas de archivos:

No modificar la configuración de producción.
No escribir en archivos secretos
No eliminar scripts de migración
No tocar directorios específicos
No ejecute comandos de red no aprobados

Anteponer esta protección a las llamadas a herramientas es más confiable que escribir “no realizar operaciones peligrosas” en un mensaje.

2. Inyección de contexto

Muchos proyectos tienen información de fondo fija:

Pila de tecnología
Convenciones de codificación
Comandos de prueba
Estrategia de ramificación
Estructura del directorio
Acciones prohibidas
Reglas para archivos generados.

Decirle esto a Claude Code manualmente cada vez es molesto y fácil de olvidar. Los ganchos pueden inyectar automáticamente el contexto necesario al inicio de la sesión o después de que el usuario envía un mensaje.

Esto es como darle a Claude Code un manual de trabajo a nivel de proyecto. No reemplaza el README ni la documentación de desarrollo, pero ayuda a la IA a ingresar al estado correcto antes de ejecutar una tarea.

3. Verificación después de las ediciones

Después de que Claude Code modifica archivos, los ganchos pueden activar comprobaciones automáticamente.

Las acciones comunes incluyen:

Ejecutar formateo
Ejecutar pelusa
Ejecutar pruebas unitarias.
Verificar errores de tipo
Escanear archivos generados
Validar formato Markdown o JSON

Esto ayuda a reducir los errores de bajo nivel. Cuando la IA edita varios archivos, una verificación ligera después de la modificación puede revelar problemas antes.

Sin embargo, los ganchos no deberían ejecutar tareas pesadas de forma predeterminada. Ejecutar el conjunto de pruebas completo después de cada cambio de archivo puede ralentizar la experiencia. Un mejor enfoque es elegir comprobaciones según el tipo de archivo, el directorio y el riesgo de la tarea.

4. Validación de las reglas del equipo

Si un equipo ya tiene convenciones claras, algunas de ellas pueden colocarse en ganchos.

Por ejemplo:

Confirmar formato de mensaje
Reglas de estilo de código
No editar directamente ciertos archivos generados
La documentación debe actualizarse en conjunto.
Los cambios de API deben actualizar las pruebas.
Ciertos directorios sólo pueden ser generados por herramientas específicas Esto hace que Claude Code se parezca más a una parte del flujo de trabajo del equipo que a un asistente externo sin restricciones.

Por supuesto, los ganchos no deberían reemplazar a la CI. Son mejores para recordatorios locales y bloqueo temprano. La validación final aún debe pertenecer a los sistemas de CI, revisión y prueba.

5. Subagentes y tareas dedicadas

El archivo README también menciona contenido relacionado con subagentes.

Este tipo de uso es adecuado para enviar tareas complejas a flujos de trabajo más especializados. Por ejemplo, la conversación principal puede comprender el requisito, mientras que un enlace o una configuración desencadenan tareas dedicadas de verificación, auditoría, resumen o documentación.

Para los usuarios individuales, el primer paso útil no es la compleja orquestación de agentes. Es mejor entregar primero a los ganchos acciones repetitivas, claras y de bajo riesgo. Una vez que las reglas se estabilicen, puede producirse una automatización más compleja.

Línea de estado y estilos de salida

El proyecto también cubre la línea de estado y los estilos de salida.

Esto puede parecer un pequeño detalle de la experiencia, pero es importante para el uso a largo plazo del Código Claude. Una línea de estado puede mostrar el contexto actual, el estado de la tarea, información del entorno o sugerencias. Los estilos de salida pueden hacer que las respuestas de Claude Code se ajusten mejor a sus hábitos de trabajo.

Si colaboras con IA en el mismo terminal todos los días, estos detalles afectan la eficiencia. Las buenas sugerencias de estado reducen los errores y le ayudan a determinar rápidamente si la sesión actual se encuentra en el proyecto, rama y entorno correctos.

No hagas que los ganchos sean demasiado pesados

Los ganchos son poderosos, pero no son el lugar para poner todo.

Las buenas reglas son:

Las acciones de alta frecuencia deben ser rápidas.
El bloqueo de seguridad debe ser claro.
La salida debe ser corta.
Los motivos del fallo deben ser legibles.
Los scripts deben tener una única responsabilidad.
Las comprobaciones exhaustivas deben ser comandos explícitos o tareas de CI

Si un enlace tarda más de diez segundos cada vez, los usuarios pronto querrán desactivarlo. Si un gancho tiene reglas de bloqueo vagas, tanto Claude Code como el usuario tendrán dificultades para entender qué hacer a continuación.

Los ganchos son mejores para tareas con límites claros: permitir o rechazar, agregar contexto, registrar eventos, ejecutar comprobaciones ligeras y sugerir el siguiente paso.

¿Quién debería usarlo?

Si solo ocasionalmente le pides a Claude Code que edite un pequeño fragmento de código, es posible que aún no necesites estudiar los ganchos en profundidad.

Pero este proyecto es útil si:

Utilice Claude Code con frecuencia
A menudo deja que la IA modifique el código del proyecto real.
Preocupación por que la IA ejecute comandos peligrosos
Quiere inyectar automáticamente reglas de equipo en los flujos de trabajo de IA
Quiere que las comprobaciones se ejecuten automáticamente después de las ediciones
Quiere convertir recordatorios repetidos en configuración
Están creando un flujo de trabajo de codificación de IA más estable.

Los ganchos son especialmente significativos en proyectos colaborativos. Pueden convertir parte de la experiencia del equipo en guiones en lugar de depender de que cada persona se lo recuerde a la IA manualmente.

Notas de uso

Primero, comience con los ganchos de seguridad.

En comparación con la automatización compleja, el bloqueo de comandos, la protección de rutas y las comprobaciones de archivos confidenciales son más fáciles de implementar y reducen el riesgo de inmediato.

En segundo lugar, comprometa cuidadosamente las reglas a nivel de proyecto.

.claude/settings.json afecta a todos los que usan el repositorio. Antes de comprometer reglas, asegúrese de que no restrinjan demasiado el desarrollo normal ni dependan de rutas que solo existen en su máquina.

En tercer lugar, mantenga la salida del gancho concisa. Claude Code consume esta salida. Si es demasiado largo, contamina el contexto. Si es demasiado vago, no guía el siguiente paso. Lo mejor es devolver sólo el juicio necesario y la siguiente recomendación.

Cuarto, mantenga los ganchos depurables.

Cuando los ganchos aumentan en número, los problemas pueden provenir de la configuración, los scripts, los permisos, las rutas, las dependencias o el propio Claude Code. Los registros claros facilitan mucho la depuración posterior.

Referencia

disler/claude-code-hooks-mastery

Pensamiento final

El valor de “Claude Code Hooks” es convertir “reglas que espero que la IA recuerde siempre” en flujos de trabajo que realmente se ejecutan.

Si ya utiliza Claude Code en proyectos reales, los ganchos son un paso clave desde “un asistente de codificación que puede conversar” hasta “un colaborador de ingeniería limitado”.

Claude-Mem: Agregar memoria a largo plazo entre sesiones al código Claude

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem es un sistema de memoria persistente para Claude Code.

Intenta resolver un problema muy específico: cada vez que un asistente de codificación de IA inicia una nueva sesión, a menudo olvida decisiones de arquitectura anteriores, obstáculos pasados, preferencias de proyecto y contexto de implementación.
Si un proyecto dura mucho tiempo, explicar repetidamente los mismos antecedentes se convierte en una pérdida de tiempo.

La idea detrás de Claude-Mem es comprimir las conversaciones de Claude Code en recuerdos, almacenarlas en una base de datos local y en un almacén de vectores, y luego recuperarlas a través de una herramienta de búsqueda.

¿Qué problema resuelve?

Claude Code es bueno en tareas de código, pero el contexto de la sesión aún es limitado.

Los puntos débiles comunes incluyen:

Una nueva sesión no sabe lo que hicieron las sesiones anteriores.
Las decisiones de diseño del proyecto deben explicarse repetidamente.
Los problemas que ya fueron depurados son fáciles de repetir
Las tareas de larga duración carecen de continuidad.
El conocimiento del proyecto es difícil de acumular a través de conversaciones.

Claude-Mem está diseñado en torno a estos problemas.

No se trata simplemente de guardar registros de chat. En cambio, comprime las conversaciones en fragmentos de memoria que son más fáciles de recuperar. Cuando sea necesario más adelante, la búsqueda semántica puede recuperar el contexto relevante.

Cómo funciona

Según el diseño README, “Claude-Mem” consta principalmente de varias partes.

La primera parte son los ganchos.

Se integra con el flujo de sesión de Claude Code y captura datos de la conversación en el momento adecuado.

La segunda parte es un trabajador en segundo plano.

El trabajador procesa el contenido de la conversación en bruto y lo convierte en recuerdos más breves y fáciles de buscar.

La tercera parte es el almacenamiento local.

El proyecto utiliza SQLite para metadatos estructurados y Chroma para indexación de vectores. Esto preserva la información básica de la sesión al tiempo que admite la recuperación semántica.

La cuarta parte es “mem-search”.

Este es el punto de entrada de consulta para Claude Code. Cuando se necesita un contexto antiguo, se pueden buscar recuerdos relevantes a través de esta herramienta.

El flujo general se puede entender así:

Las sesiones de Claude Code generan contenido
Los ganchos capturan datos de la sesión
El trabajador lo comprime y organiza de forma asincrónica.
Los recuerdos se escriben en SQLite y Chroma.
Las sesiones posteriores los recuperan mediante mem-search

¿Cuándo es útil?

Claude-Mem es adecuado para proyectos de larga duración, no para tareas pequeñas y puntuales.

Por ejemplo:

Un repositorio se desarrolla durante muchos días.
La estructura del código es compleja y tiene muchos antecedentes.
Es necesario recordar las convenciones del proyecto, los hábitos de nomenclatura y las elecciones de arquitectura.
Claude Code se utiliza a menudo para corregir errores, funciones y documentación.
Quieres que la IA recuerde por qué se cambió algo antes

Si solo le pide a Claude Code que haga un cambio de una línea, la memoria a largo plazo no es muy significativa.
Pero si tratas a Claude Code como un colaborador a largo plazo, resulta útil.

Instalación y puesta en marcha

El README proporciona un flujo de instalación directo:

1
2

npm install -g claude-mem
claude-mem install

Empiece con:

`1`	`claude-mem start`

Verificar estado:

`1`	`claude-mem status`

Deténgalo cuando sea necesario:

`1`	`claude-mem stop`

El objetivo detrás de estos comandos es conectar el sistema de memoria como un servicio local de larga duración al flujo de trabajo de Claude Code.

Cómo utilizar `mem-search`

mem-search es el punto de entrada clave para recuperar la memoria.

No pretende reemplazar la búsqueda ordinaria. Permite a Claude Code consultar conversaciones pasadas por significado.

Por ejemplo, Claude Code puede buscar:

Por qué un módulo fue diseñado de cierta manera
Cómo se depuró un error anteriormente
Reglas de nomenclatura acordadas en el proyecto.
Compensaciones técnicas discutidas anteriormente
El trasfondo detrás de una refactorización.

Esto es diferente de la simple búsqueda de palabras clave.
Si la compresión de memoria y la indexación de vectores funcionan bien, puede recuperar contenido semánticamente relacionado incluso si no recuerda la redacción exacta.

¿En qué se diferencia de la documentación del proyecto?

La documentación del proyecto es buena para sacar conclusiones estables.

Por ejemplo:

Notas de arquitectura
Procedimientos de implementación
Convenciones API
Estructura de la base de datos
Reglas de desarrollo

Claude-Mem es mejor para el contexto creado durante las conversaciones.

Por ejemplo:

Por qué se rechazó un plan
Cómo se solucionó un problema temporal
La discusión detrás de una implementación.
Las preferencias del proyecto aún no están escritas en los documentos.
Antecedentes de tareas acumulados en múltiples conversaciones

Los dos no se reemplazan el uno al otro.
Un buen flujo de trabajo es escribir conocimientos estables en los documentos del proyecto y utilizar el sistema de memoria para ayudar a recuperar el contexto conversacional.

Cosas a tener en cuenta

En primer lugar, una mayor memoria a largo plazo no siempre es mejor.

Si cada conversación se guarda sin distinción, la recuperación posterior puede resultar ruidosa. Los recuerdos más valiosos son las decisiones del proyecto, los antecedentes de la implementación, el historial de depuración y las preferencias a largo plazo.

En segundo lugar, la memoria no puede reemplazar el código y la documentación.

El contexto antiguo encontrado por la IA es sólo una referencia. El juicio final aún depende del código actual, los resultados de las pruebas y los requisitos más recientes.

En tercer lugar, preste atención a la privacidad y los datos locales.

Dado que almacena el contenido de la conversación, debes saber qué proyectos son adecuados para él y qué información confidencial no debe entrar en la conversación.

Cuarto, los sistemas de memoria necesitan mantenimiento.

A medida que avanza un proyecto, los viejos recuerdos pueden quedar obsoletos. Si el contexto obsoleto se reutiliza incorrectamente, puede inducir a error en tareas posteriores.

Por qué es importante este tipo de herramienta

Las herramientas de codificación de IA están pasando de preguntas y respuestas únicas a una colaboración a largo plazo.

En preguntas y respuestas únicas, el modelo solo necesita responder la pregunta actual.
En una colaboración a largo plazo, es necesario conocer el historial del proyecto, las decisiones anteriores, las preferencias del equipo y los obstáculos que ya se han encontrado.

Aquí es donde importan herramientas como Claude-Mem: convierten el “recordar el contexto” de una capacidad de chat temporal en un sistema local que puede instalarse, ejecutarse y buscarse.

Para proyectos de ingeniería reales, esto es más práctico que simplemente alargar la ventana de contexto del modelo.
No es necesario contextualizar mucha información de una sola vez; es necesario recuperarlo en el momento adecuado.

¿Quién debería intentarlo?

Quizás quieras probarlo si:

Usas Claude Code con frecuencia
A menudo trabajas en el mismo proyecto durante varios días.
El contexto del proyecto es complejo.
Explicas repetidamente los mismos antecedentes a la IA.
Quieres preservar la experiencia de las conversaciones.

Si solo usas Claude Code ocasionalmente, o el proyecto es pequeño, es posible que aún no necesites este tipo de sistema.

Referencia

thedotmack/claude-mem

Pensamiento final

El objetivo de Claude-Mem no es “guardar registros de chat”. Ayuda a Claude Code a recuperar contexto útil en tareas posteriores. A medida que la codificación de IA pase de tareas únicas a colaboraciones en proyectos de larga duración, los sistemas de memoria serán cada vez más importantes.
No pueden reemplazar la documentación y las pruebas, pero pueden reducir las explicaciones repetidas y hacer que la IA se sienta más como un asistente que comprende el historial del proyecto.

Ralph y la colaboración entre múltiples agentes: cómo mantener la IA funcionando de manera confiable durante tareas largas

Mon, 27 Apr 2026 08:19:02 +0800

Si ha estado utilizando agentes de codificación últimamente, rápidamente se encontrará con una pregunta muy práctica: La IA puede funcionar, claro, pero ¿cómo se puede mantener funcionando durante horas sin desviarse, olvidar requisitos o rehacer el mismo trabajo?

Ésa es la verdadera pregunta detrás de muchas discusiones sobre “Ralph” y la colaboración entre múltiples agentes. La cuestión no es simplemente comparar qué modelo es más fuerte. La pregunta más útil es esta: ¿cómo se diseña un flujo de trabajo que permita a la IA mantenerse estable durante tareas largas?

Si analizamos el problema, normalmente hay dos rutas principales:

El enfoque Ralph: seguir iniciando sesiones nuevas y conectar el contexto a través del sistema de archivos
El enfoque de múltiples agentes: dejar que un agente líder coordine mientras los agentes trabajadores dividen la ejecución

Dicho de manera más simple, la pregunta no es “qué modelo es más poderoso”, sino “¿cómo se organiza la IA para que se comporte más como un pequeño equipo que pueda seguir cumpliendo?”.

01 Por qué las tareas largas se descarrilan

En tareas breves, muchos problemas quedan ocultos. Usted da una instrucción, el modelo lee algunos archivos, cambia algunas líneas y el trabajo está hecho.

Una vez que la tarea se hace más larga, los modos de falla comunes comienzan a acumularse:

Las conversaciones se hacen más largas y el contexto comienza a abultarse.
Los requisitos anteriores quedan eliminados por la información más reciente.
Un agente tiene que planificar, implementar y probar al mismo tiempo.
Sin un paso de aceptación claro, “está hecho” a menudo significa simplemente “dice que está hecho”.

Entonces, cuando la IA funciona durante mucho tiempo, el verdadero desafío no suele ser la calidad del modelo de un solo disparo. Se trata de división de tareas, transferencia de estados, separación de roles y bucles de retroalimentación.

02 El enfoque Ralph: dividir las tareas largas en rondas cortas

Ralph encaja bien cuando el problema principal es un contexto sucio y sobrecargado.

Su patrón central es sencillo:

Sigue lanzando nuevas sesiones de agentes en bucle
Deje que cada ronda se encargue solo de una tarea lo suficientemente pequeña
Almacene el estado cruzado en archivos en lugar de forzar todo en una sola conversación

El beneficio es inmediato: cada ronda comienza con un contexto nuevo, por lo que la sesión permanece más centrada y es menos probable que se vea arrastrada por la vieja historia.

Si ya ha visto proyectos estilo “Ralph”, la estructura le resultará familiar:

Las tareas actuales viven en archivos estructurados.
Los aprendizajes intermedios van a los archivos de progreso.
Los cambios de código permanecen en el historial de git.

En otras palabras, “Ralph” no intenta que un agente recuerde todo para siempre. Exterioriza la memoria a propósito para que la sesión en sí sea más ligera.

Este tipo de configuración funciona especialmente bien cuando:

La obra ya se puede dividir en pequeñas historias.
Cada historia puede caber dentro de una ventana de contexto.
El proyecto ya cuenta con pruebas, verificación de tipos u otras comprobaciones.

Es una solución al problema de cómo hacer que la IA siga avanzando ronda a ronda.

03 El enfoque de múltiples agentes: dividir el trabajo que un agente no puede realizar solo

La otra ruta es la colaboración entre múltiples agentes.

En este tipo de diseño de flujo de trabajo, el patrón más prometedor suele ser el siguiente: el agente principal no debe hacer todo el trabajo directamente. En cambio, coordina mientras otros agentes se encargan del desarrollo, las pruebas, la verificación y la aceptación.

Esto difiere de Ralph en un aspecto importante:

Ralph se siente más como una iteración en serie
El trabajo con múltiples agentes se parece más a una división paralela del trabajo. Cuando la tarea contiene naturalmente diferentes roles, la colaboración entre múltiples agentes se vuelve más fácil de usar. Por ejemplo:
Un agente desglosa la tarea y escribe el plan de ejecución.
Un agente implementa el cambio real.
Un agente prueba y valida el resultado.
Un agente comprueba si el resultado sigue coincidiendo con el objetivo original.

La cuestión no es abrir más ventanas porque sí. El valor real es la separación de roles. Las tareas que antes recaían sobre un solo agente ahora se pueden dividir en etapas más claras.

Una vez que los límites de los roles están claros, varios problemas se aclaran:

La persona que escribe no tiene que ser la misma que revisa
La parte de pruebas no tiene que reconstruir el requisito completo cada vez.
Es menos probable que el agente principal se ahogue en los detalles de la implementación.

Esta es una solución al problema de cómo hacer que la IA coopere más como un equipo pequeño.

04 La verdadera clave no es el paralelismo, sino el diseño de tareas

Ya sea que elija Ralph o la colaboración entre múltiples agentes, lo más fácil de subestimar es esto: el diseño del flujo de trabajo importa más que abrir más agentes.

Si la división de tareas es incorrecta, agregar más agentes sólo crea un paralelismo con la confusión.

Una avería más estable suele tener algunas características:

Una tarea se asigna a un objetivo claro
Un rol posee una categoría de salida
Cada ronda tiene una condición clara de finalización.
La producción de una ronda puede ser consumida directamente por la siguiente.

Por ejemplo, en lugar de darle a la IA una instrucción gigante como “construir toda la característica”, una estructura más estable suele ser:

Primero, rompa los requisitos y los límites.
Luego dividir la implementación
Luego dividir las pruebas
Entonces haz de la aceptación su propio paso.

La ventaja es que cuando algo sale mal, resulta más fácil saber si el problema radica en los criterios de comprensión, implementación, prueba o entrega.

05 Por qué la aceptación es tan importante

Muchos flujos de trabajo de IA fallan no porque no haya sucedido nada antes, sino porque el último paso careció de un pase de confirmación genuinamente independiente.

En tareas largas, suele haber una gran brecha entre “se produjo un resultado” y “el resultado es realmente utilizable”.

Por eso, una dirección especialmente importante es separar el desarrollo de la aceptación. Incluso sin un proceso complejo, vale la pena hacerse al menos estas preguntas:

¿Realmente completó la tarea original?
¿Solo parchó la superficie sin solucionar la causa raíz?
¿Las pruebas cubrieron sólo el camino más feliz?
¿Se cambiaron silenciosamente los requisitos upstream a lo largo del camino?

Sin esa capa, la IA puede seguir declarando éxito fácilmente dentro de un flujo de trabajo prolongado.

06 Cómo elegir entre los dos

Si desea una regla general rápida:

Si su principal problema es la sobrecarga del contexto y la deriva de las sesiones largas, comience con “Ralph”
Si su principal problema es que un agente desempeña demasiadas funciones, comience con la colaboración de varios agentes.

Más específicamente:

Ralph se adapta al trabajo que es claro, granular y fácil de avanzar paso a paso
La colaboración entre múltiples agentes se adapta al trabajo con fuertes límites de roles y una necesidad de paralelismo y verificación cruzada.

En la práctica, estos dos enfoques no siempre son competidores. Una configuración madura suele combinarlos:

Utilice un bucle exterior estilo “Ralph” para impulsar la tarea más grande.
Utilice la colaboración de múltiples agentes dentro de cada ronda para investigación, implementación, prueba y aceptación.

Eso les brinda a ambos un mejor control sobre el contexto prolongado y una mejor colaboración dentro de una sola ronda.

07 Resumen de una oración

Lo que hace que valga la pena estudiar estos enfoques no es que recomienden “Ralph” o la colaboración entre múltiples agentes de forma aislada. Es que dejan muy clara una verdad práctica: mantener la IA estable durante tareas largas depende menos del modelo en sí y más de si se diseñó bien el contexto, las tareas, los roles y la aceptación.

Si ya está pidiendo a “Claude Code”, “Codex” u otros agentes de codificación que manejen tareas más largas del mundo real, este tipo de pensamiento de flujo de trabajo suele ser más valioso que simplemente cambiar a un modelo más sólido.

Qué es Ralph: convertir Claude Code y Amp en un circuito de desarrollo autónomo repetible

Mon, 27 Apr 2026 08:08:55 +0800

Si últimamente ha estado prestando atención a los flujos de trabajo de agentes de codificación de larga duración, snarktank/ralph es un proyecto que vale la pena analizar de cerca. No es otro contenedor de modelo ni otra interfaz de usuario de chat. En cambio, organiza “Claude Code” o “Amp” en un bucle autónomo que sigue recorriendo las historias en un “PRD” hasta que todo está hecho.

Su idea central es simple: no obligar al mismo agente a seguir trabajando dentro de un contexto cada vez más largo y desordenado. En su lugar, inicie una nueva sesión de codificación de IA para cada iteración. Eso evita que el contexto se hinche y hace que los límites de las tareas sean mucho más claros.

01 ¿Qué es Ralph?

Ralph se describe a sí mismo muy claramente: es un bucle de agente de IA autónomo que ejecuta repetidamente una herramienta de codificación de IA hasta que se completan los elementos de un “PRD”.

El repositorio actualmente admite dos herramientas:

Amplificador CLI
Código Claude

Cada iteración inicia una nueva instancia. En otras palabras, no depende de una conversación interminable. En cambio, mantiene la memoria en estado externo:

historia de git
progreso.txt
prd.json

Ese detalle importa mucho. Cuando la gente deja que un agente ejecute tareas grandes, el principal problema a menudo no es que el modelo no pueda codificar. Es que la sesión se vuelve más pesada con el tiempo, empieza a perder contexto, olvida requerimientos y repite trabajo. Ralph está diseñado casi exclusivamente en torno a ese problema.

02 Cómo funciona

El flujo de trabajo de Ralph tiene tres pasos.

1. Escribe primero un PRD

El archivo README sugiere comenzar con la habilidad “prd” incluida para generar un documento de requisitos y dividir la función en historias más pequeñas.

2. Convierta el PRD a `prd.json`

Luego, la habilidad ralph convierte el Markdown PRD en un prd.json estructurado. Ese archivo almacena las historias de los usuarios y si cada una ha pasado.

3. Ejecute el script de bucle

La ejecución real está a cargo de ralph.sh. Los comandos se ven así:

1
2

./scripts/ralph/ralph.sh [max_iterations]
./scripts/ralph/ralph.sh --tool claude [max_iterations]

El valor predeterminado es 10 iteraciones. En cada ronda, Ralph hace aproximadamente lo siguiente:

Crea una rama desde branchName
Elija la historia de mayor prioridad donde “pasa: falso”.
Implemente solo esa historia
Ejecute controles de calidad, como verificación de tipos y pruebas.
Comprometerse si pasan los controles
Actualiza prd.json
Adjunte lo aprendido a progress.txt
Continuar a la siguiente ronda.

Entonces Ralph no está tratando de terminar todo de una vez. Comprime el trabajo en muchos bucles pequeños que pueden caber dentro de una única ventana de contexto.

03 ¿Qué hace que Ralph sea interesante?

1. Cada ronda utiliza un contexto nuevo

Esta es la elección de diseño que define a Ralph. El archivo README enfatiza que cada iteración es una instancia de IA completamente nueva y que la memoria entre iteraciones reside solo en git, progress.txt y prd.json.

Esto es muy diferente del patrón común de mantener el “Código Claude” u otra herramienta dentro de una larga conversación. Una vez que las tareas aumentan, ese enfoque a menudo se ralentiza debido a su propia historia y gradualmente pierde enfoque. Ralph acepta que ninguna ronda debería recordar todo y, en su lugar, mueve la memoria a archivos.

2. Obliga a que las tareas sean pequeñas

Los documentos dicen explícitamente que cada elemento PRD debe ser lo suficientemente pequeño como para terminar dentro de una ventana de contexto. Tareas como agregar un filtro, actualizar una acción del servidor o agregar una columna de base de datos tienen aproximadamente el tamaño correcto. Tareas como reconstruir toda la API o crear un panel completo son demasiado grandes. Esa restricción es práctica. Muchos bucles de agentes autónomos fallan no porque el bucle sea malo, sino porque la división de tareas es demasiado burda y cada ronda lleva demasiado a la vez.

3. Preserva el aprendizaje, no solo el código

Más allá de progress.txt, el README también hace hincapié en la actualización de AGENTS.md. La razón es sencilla: las iteraciones futuras y los futuros desarrolladores leerán esas notas, por lo que los patrones, errores y convenciones descubiertos en cada ronda deben anotarse en el proyecto mismo.

Dicho de otra manera, Ralph no sólo intenta mantener a un agente codificando continuamente. También intenta ayudar al agente a desarrollar memoria de trabajo sobre el código base a lo largo del tiempo.

04 Cuando encaja mejor

Ralph encaja bien cuando su tarea se ve así:

Ya se puede dividir en un conjunto claro de historias de usuarios.
El código base tiene bucles de retroalimentación confiables, como pruebas, verificación de tipos o CI
Quiere que el agente siga avanzando sin poner todo en una larga conversación.
Estás de acuerdo con el progreso iterativo en lugar de exigir una finalización de una sola vez.

Por otro lado, si el requisito aún es vago, o el trabajo depende de discusiones frecuentes y cambios constantes de dirección, es posible que Ralph no sea el primero a quien recurrir. Se adapta mejor una vez que los requisitos ya están definidos y la ejecución debe ser constante.

05 En qué se diferencia del uso normal del código Claude

Con Claude Code simple, el patrón habitual es simple: abra una sesión y déjela seguir leyendo código, editando archivos y ejecutando comandos. Esto funciona muy bien para tareas pequeñas y medianas, pero las tareas más grandes suelen tener dos problemas:

El contexto sigue creciendo
Las decisiones intermedias son más difíciles de preservar de forma estructurada.

Ralph convierte “Claude Code” o “Amp” en algo más parecido a un ejecutor por lotes:

La fuente de la tarea es prd.json, no instrucciones de chat ad hoc.
Cada iteración reconoce solo una historia.
El estado de finalización se vuelve a escribir en los archivos.
Los aprendizajes van en progress.txt
Los cambios de código se conservan en git

Entonces, en la práctica, se siente menos como un nuevo asistente de IA y más como un controlador de iteración agregado sobre un agente de codificación.

06 Un requisito importante

Que Ralph funcione bien depende menos del bucle en sí y más de la calidad de sus bucles de retroalimentación. El archivo README dice esto de manera muy directa: sin verificación de tipo, pruebas y CI, los errores se agravarán en iteraciones posteriores.

Para tareas frontend, el repositorio incluso recomienda agregar la verificación del navegador a los criterios de aceptación. Sin una verificación real, un agente puede confundir fácilmente “parece hecho” con “realmente funciona”.

Ese punto es importante. Ralph no es una automatización mágica. Es más como un multiplicador de fuerza para la disciplina de ingeniería que ya tienes. Si su proyecto ya tiene desgloses de tareas claros y controles confiables, Ralph se vuelve mucho más útil. Si faltan esos fundamentos, el bucle sólo repetirá la confusión.

07 Resumen de una oración

Lo que hace que valga la pena estudiar “Ralph” no es que introduzca una enorme cantidad de infraestructura nueva. Toma una idea simple pero útil y la convierte en un flujo de trabajo práctico: deje que Claude Code o Amp manejen una pequeña historia por ronda, mantenga el enfoque en un contexto nuevo y preserve la continuidad a través de git, prd.json y progress.txt. Si ya está utilizando agentes de codificación en proyectos reales y sigue estancado en cómo impulsar tareas largas de manera confiable, vale la pena tomar prestado el enfoque de Ralph.

Referencias

Repositorio de GitHub: https://github.com/snarktank/ralph
Diagrama de flujo interactivo: https://snarktank.github.io

CLAUDE.md de 65 líneas de Karpathy: ayudando a la codificación de IA a evitar tres errores comunes

Sun, 19 Apr 2026 18:27:23 +0800

Un proyecto de GitHub sobre codificación de IA ha recibido mucha atención recientemente. Su núcleo no es una base de código compleja, sino un archivo CLAUDE.md de aproximadamente 65 líneas. La razón por la que atrajo tantas estrellas no es la complejidad técnica. Es que captura los problemas con los que muchas personas se encuentran repetidamente cuando usan IA para escribir código.

Los antecedentes comienzan con las observaciones de Andrej Karpathy sobre la codificación de IA. Karpathy es un influyente educador e ingeniero en IA: doctor de Stanford, uno de los primeros contribuyentes de OpenAI y exlíder de IA de Tesla responsable del sistema de visión de Autopilot. Continuó compartiendo sus puntos de vista sobre modelos grandes, educación y herramientas de inteligencia artificial, por lo que sus comentarios sobre los cambios en los flujos de trabajo de programación tienden a llamar mucho la atención de los desarrolladores.

Una vez dijo que después de usar Claude Code durante algunas semanas, su estilo de programación cambió notablemente. Anteriormente, era aproximadamente un 80% de código escrito a mano y un 20% de asistencia de IA. Ahora está más cerca del 80% del código escrito por IA y del 20% editado por él mismo. Lo describió como “programación en inglés”, diciéndole a un LLM qué escribir en lenguaje natural.

Pero también señaló varios problemas recurrentes en la codificación de IA.

01 Suposiciones erróneas

El primer problema es que los modelos hacen suposiciones fácilmente en nombre del usuario y luego siguen escribiendo en ese camino. No siempre manejan su propia confusión y no siempre se detienen a hacer preguntas cuando el requisito es ambiguo.

Por ejemplo, si el usuario solo dice “agregar una función de exportación de usuario”, el modelo podría asumir que debe exportar todos los usuarios, generar JSON, escribir en un archivo local y omitir cualquier confirmación sobre permisos o campos. Sólo después de terminar el código el usuario descubre que la comprensión del modelo no coincide con el escenario real.

Un mejor enfoque es enumerar primero las incertidumbres: ¿debería exportar todos los usuarios o los resultados filtrados? ¿Debería activar una descarga del navegador o ejecutarse como trabajo en segundo plano? ¿Qué campos son necesarios? ¿Qué tamaño tiene el conjunto de datos? ¿Existen restricciones de permisos? Si estas preguntas no se aclaran, escribir más rápido sólo significa ir más lejos.

02 Sobrecomplejidad

El segundo problema es que los modelos a menudo convierten problemas simples en complejos. Una tarea que podría manejarse con una función podría recibir clases abstractas, patrones de estrategia, patrones de fábrica, capas de configuración y un montón de puntos de extensión que tal vez nunca sean necesarios.

Este tipo de código puede parecer diseñado, pero en la práctica aumenta el costo de mantenimiento. La IA es especialmente buena para generar rápidamente estructuras grandes, pero no siempre juzga si esas estructuras son necesarias. El resultado es que una tarea que se puede resolver en 100 líneas se infla en 1000 líneas.

La prueba es sencilla: ¿un ingeniero senior observaría el cambio y pensaría que está sobrediseñado? Si la respuesta es sí, elimine las capas adicionales y resuelva el problema actual con la menor cantidad de código necesario.

03 Daños colaterales

El tercer problema es que los modelos a veces modifican o eliminan código que no comprenden completamente. Mientras solucionan un pequeño error, pueden cambiar comentarios casualmente, reformatear el código cercano, limpiar importaciones que parecen no utilizadas o incluso tocar lógica no relacionada con la tarea actual. Estas “mejoras inmediatas” son riesgosas porque amplían el alcance del cambio y dificultan la revisión. Es posible que el usuario solo desee solucionar un fallo del validador causado por un correo electrónico vacío, pero el modelo también puede mejorar la validación del correo electrónico, agregar validación de nombre de usuario y reescribir cadenas de documentos. Al final, resulta difícil saber qué línea cambió el comportamiento.

Una regla más segura es: cambiar sólo lo que se debe cambiar y sólo solucionar los problemas causados por su propio cambio. El código muerto existente, los problemas de formato o el bagaje histórico no deben tocarse a menos que la tarea lo solicite explícitamente. Como máximo, menciónalo.

04 Transformando las quejas en CLAUDE.md

Después de que los comentarios de Karpathy se difundieran ampliamente, el desarrollador Forrest Cheung hizo algo inteligente: organizó estas quejas en reglas de comportamiento ejecutables y las puso en un archivo CLAUDE.md.

El proyecto no contiene código complicado. Su idea clave es convertir las partes más propensas a fallas de la codificación de IA en reglas de trabajo claras. Se pueden resumir en cuatro principios.

La primera es pensar antes de escribir. No asumas en silencio. No ocultes la confusión. Si un requisito tiene múltiples interpretaciones, enumérelas. Si hay un enfoque más sencillo, dígalo. Pregunte cuando sea necesaria una aclaración y responda cuando sea necesario.

El segundo es mantener las cosas simples. No agregue funciones que no fueron solicitadas. No abstraiga el código único. No agregue configuraciones innecesarias. No escriba grandes cantidades de código defensivo para escenarios extremadamente improbables. Si 50 líneas pueden resolverlo, no escribas 200.

El tercero es hacer cambios precisos. Cada línea modificada debe rastrearse directamente hasta la solicitud del usuario. No mejore el código cercano como misión secundaria. No refactorices algo que no esté roto. Haga coincidir el estilo del proyecto existente tanto como sea posible.

El cuarto es la ejecución impulsada por objetivos. No le des al modelo sólo una instrucción vaga. Dale un criterio de éxito verificable. Por ejemplo, “corregir el error” puede convertirse en “escribir una prueba que reproduzca el error y luego hacer que pase”; “agregar validación” puede convertirse en “escribir pruebas de entradas no válidas y hacerlas pasar”. Cuanto más claro sea el criterio de éxito, más fácil será para el modelo avanzar hacia su finalización.

05 Por qué despegó

Este proyecto se hizo popular no porque el contenido sea misterioso, sino porque se acerca al trabajo de desarrollo real.

Muchas personas que utilizan IA para codificar han visto escenas similares: el modelo malinterpreta con confianza el requisito, el código se vuelve más complejo a medida que avanza o toca lugares que no debería tocar. El valor de CLAUDE.md es que convierte esas experiencias en reglas de colaboración que se pueden colocar dentro de un proyecto.

El coste de entrada también es bajo: un archivo puede empezar a marcar la diferencia, sin una integración complicada. Combinado con la influencia de Karpathy y los ejemplos prácticos de comparación del proyecto, se extendió naturalmente a través de la base de usuarios de Claude Code y la comunidad de codificación de IA en general.

Más importante aún, estas reglas no son solo para el Código Claude. No importa qué herramienta de codificación de IA utilice, los problemas subyacentes son similares: el modelo necesita saber cuándo preguntar, cuándo simplificar, cuándo detenerse y cómo decidir que la tarea está completa.

06 Lo que los desarrolladores pueden llevarse

La lección para los desarrolladores comunes es simple: la codificación con IA no se trata de lanzar una oración a un modelo y esperar un milagro. El enfoque eficaz es darle límites al modelo.

Cuando el requisito no esté claro, pídale que exponga sus supuestos primero. Cuando la implementación comience a complicarse, pídale que vuelva a la solución viable más pequeña. Al cambiar el código, manténgalo enfocado en el objetivo de la tarea. Al finalizar el trabajo, utilice pruebas, comandos o puntos de control explícitos para verificar el resultado.

La IA ya es muy capaz de escribir código, pero aún necesita buenas limitaciones de colaboración. El hecho de que un breve CLAUDE.md pueda atraer tanta atención demuestra que los desarrolladores no sólo necesitan modelos más inteligentes. También necesitan formas de trabajo más fiables.

En resumen:

Pensar antes de escribir para reducir suposiciones erróneas.
Mantenga las cosas simples para evitar el diseño excesivo.
Realizar cambios precisos para controlar el alcance del cambio.
Trabajar hacia metas con criterios de éxito verificables.

Estas cuatro reglas no son complicadas, pero son prácticas. El requisito previo para que la codificación de IA realmente mejore la eficiencia es no hacer que el modelo escriba más. Está haciendo que escriba con mayor precisión, con menos código y bajo un mejor control.

Uso más eficiente de la cuota de código de Claude: modelos, contexto, almacenamiento en caché y /compact

Sun, 19 Apr 2026 15:29:06 +0800

Muchos usuarios de Claude Code o Claude Max se encuentran con el mismo problema: incluso después de pagar por Pro, Max 5x o Max 20x, la advertencia de uso aparece rápidamente o tienen que esperar al siguiente reinicio. Esto resulta especialmente obvio cuando Claude Code lee muchos archivos, corrige errores complicados o ejecuta tareas largas en un proyecto grande.

El punto clave es este: el uso no se deduce linealmente por “minutos”. Depende del modelo, la longitud del contexto, los archivos adjuntos, el tamaño del código base, el historial de conversaciones, las llamadas a herramientas y la capacidad actual. En el mismo período de 5 horas, una persona puede trabajar durante mucho tiempo mientras que otra alcanza el límite en minutos. Por lo general, la cuenta no está rota; cada solicitud es simplemente demasiado pesada.

Esta nota recoge un conjunto de hábitos prácticos para utilizar la cuota de forma más eficiente.

01 Primero comprenda la ventana de uso de Claude

Tanto Claude Pro como Max tienen límites de uso. El uso de Claude Code se comparte con Claude en la web, el escritorio y el dispositivo móvil bajo la misma cuota de suscripción. El centro de ayuda de Anthropic explica que el recuento de mensajes depende de la longitud del mensaje, el tamaño del archivo adjunto, la duración de la conversación actual, el modelo o característica utilizada, y que el uso de Claude Code también se ve afectado por la complejidad del proyecto, el tamaño de la base del código y la configuración de aceptación automática.

Una forma sencilla de pensarlo:

Pro: adecuado para uso ligero y proyectos pequeños.
Max 5x: adecuado para un uso más frecuente y bases de código más grandes.
Máx. 20x: adecuado para colaboraciones diarias más intensas.
Las ventanas de uso se restablecen en sesiones de 5 horas.
Los mensajes largos, las conversaciones largas, los archivos grandes y las tareas complejas consumen el uso más rápidamente.
Los modelos más fuertes, como Opus, alcanzan los límites más rápido que Sonnet.

Así que “sólo lo usé durante 20 minutos” no explica mucho por sí solo. Lo que importa es cuánto contexto leyó Claude durante esos 20 minutos, qué modelo se utilizó, si los archivos grandes se procesaron repetidamente y si la misma larga conversación siguió acumulando más tareas.

02 Primer hábito: no optar por el modelo más caro

La familia de modelos Claude suele posicionarse así:

Opus: capacidad más potente, adecuada para razonamientos complejos, decisiones de arquitectura y errores difíciles.
Sonnet: capacidad y coste equilibrados, adecuado para la mayoría de las tareas de codificación cotidianas.
Haiku: más ligero, adecuado para clasificación, resumen y conversión de formato sencillos.

Para scripts diarios, pequeñas correcciones de errores, limpieza de documentación y explicación de código, Sonnet suele ser suficiente. Guarde Opus para casos como:

Diseño de arquitectura compleja.
Refactorizaciones profundas de múltiples archivos.
Errores difíciles de reproducir.
Solución de problemas de cadena larga.
Tareas donde el modelo normal está claramente estancado.

En Claude Code, use /model para cambiar de modelo o establezca el valor predeterminado en /config. Un hábito más constante es utilizar Sonnet de forma predeterminada y cambiar a Opus sólo en puntos clave, en lugar de ejecutar toda la tarea en Opus.

03 Segundo hábito: controlar el contexto, no arrastrar tareas antiguas

Cuanto más largo sea el contexto, más necesitará procesar Claude en cada turno y más rápido se consumirá el uso. Los documentos del Código Claude recomiendan explícitamente la gestión proactiva del contexto:

Utilice /clear cuando cambie a una tarea no relacionada.
Utilice /compact cuando finalice una fase pero debe permanecer un contexto importante.
Utilice /context para ver qué está ocupando espacio.
Configure una línea de estado si desea visibilidad continua del estado.

Un ritmo útil:

Small phase done: /compact
Large task done: /clear
Switching to unrelated work: /clear
Context usage getting high: /compact early

/compact resume el historial de conversaciones anteriores y al mismo tiempo conserva el estado de las tareas clave, las conclusiones, las rutas de los archivos y el trabajo restante. Reduce la cantidad de historial que se incluye en solicitudes posteriores. También puede agregar una breve instrucción:

`1`	`/compact Preserve changed files, test results, remaining TODOs, and key design decisions`

No espere a que se compacte automáticamente. Los documentos señalan que Claude Code se autocompacta cuando el contexto se acerca al límite, pero la compactación manual en los límites de fase suele ser más fácil de controlar.

04 Tercer hábito: las conversaciones largas y los archivos grandes hacen que cada solicitud sea más pesada

Mucha gente supone que “Sólo hice una pregunta más” debería ser barato. Pero en una conversación larga, esa pregunta puede tener detrás una gran cantidad de historia, resúmenes de archivos, definiciones de herramientas y reglas del sistema.

Las cosas que fácilmente inflan el contexto incluyen:

Conversaciones largas que nunca se aclaran.
Pedirle a Claude que lea archivos grandes completos.
Pegar registros largos, resultados de compilación o resultados de prueba.
Agregar muchas capturas de pantalla o imágenes a la vez.
Pidiéndole que escanee repetidamente todo el repositorio.
Un CLAUDE.md demasiado largo.
Demasiados servidores MCP habilitados.

Un enfoque más eficiente: pegue solo los errores clave de los registros, incluya solo las partes fallidas del resultado de la prueba y deje que Claude use rg, head, tail y la búsqueda de símbolos antes de leer solo las partes necesarias. Si el filtrado de la línea de comandos puede reducir el contenido, no pegue todo en contexto.

05 Cuarto hábito: comprender el almacenamiento en caché, pero no adorarlo

El almacenamiento en caché de avisos de Anthropic puede almacenar en caché prefijos de avisos repetidos. La vida útil predeterminada de la caché es de 5 minutos y también se admite una caché de 1 hora. Cuando se alcanza el caché, no es necesario reprocesar completamente el contexto repetido de gran tamaño, lo que ayuda a reducir los costos y mejorar la utilización del límite de velocidad.

Pero el almacenamiento en caché tiene limitaciones:

El contenido debe coincidir exactamente, incluidos texto e imágenes.
La caché predeterminada es de corta duración.
Cambiar modelos, herramientas, indicaciones del sistema o estructura de contexto puede reducir los accesos al caché.
Los tokens de salida no desaparecen debido al almacenamiento en caché; aún es necesario generar la respuesta.
La forma en que Claude Code utiliza el almacenamiento en caché es un detalle de implementación a nivel de producto, por lo que no lo trate como “memoria libre” permanente.

En la práctica, lo importante no es estudiar cada detalle del almacenamiento en caché. Mantiene la sesión estable:

Evite cambios frecuentes de modelo dentro de la misma fase.
No reescriba repetidamente grandes bloques de reglas a mitad de la tarea.
No sigas agregando nuevas imágenes dentro de la misma tarea.
No dejes una tarea larga inactiva durante demasiado tiempo y luego regreses con otra gran solicitud.
Utilice /compact en los límites de fase.

Esto hace que el contexto repetido sea más fácil de reutilizar y reduce el peso de las solicitudes posteriores.

06 Sobre las horas pico: evítalas cuando puedas, pero no las trates como una fórmula

La gente suele decir que ciertas horas se sienten más apretadas. El centro de ayuda de Anthropic es más cuidadoso: el recuento de mensajes puede verse afectado por la capacidad actual de Claude, la duración de la conversación, los archivos adjuntos, el modelo y las características. En otras palabras, la capacidad máxima puede afectar la experiencia, pero no trate una ventana horaria local específica como una regla permanente.

Sugerencias prácticas:

Realice grandes refactorizaciones y análisis exhaustivos en períodos en los que tanto su red como el servicio sean estables.
No comiences una tarea enorme justo antes de que planees alejarte.
Si espera salir por un largo tiempo, ejecute /compact o /clear primero.
Para ediciones pequeñas, no utilices Opus con un contexto largo a menos que realmente lo necesites.

Esto es más confiable que memorizar una regla fija de “no usarlo de X a Y”.

07 Slim Down CLAUDE.md, reglas, MCP y habilidades

Claude Code carga reglas del proyecto, información de herramientas y algo de contexto ambiental en la sesión. Los documentos oficiales también recomiendan separar las reglas generales de las reglas especializadas para que cada sesión no comience con una gran cantidad de texto no relacionado.

Una división útil:

CLAUDE.md: sólo reglas globales que siempre se aplican.
reglas: reglas específicas de ruta o de tipo de archivo.
habilidades: flujos de trabajo específicos, como publicación de publicaciones, implementación, generación de imágenes o confirmación de código.
MCP: solo habilita los servidores que la tarea actual realmente necesita.

Si CLAUDE.md tiene cientos o miles de líneas, cada sesión conlleva ese costo. Un mejor patrón es trasladar flujos de trabajo ocasionales a habilidades y cargarlos solo cuando sea necesario.

MCP es similar. Más herramientas no significan automáticamente más eficiencia. Los documentos de Claude Code mencionan el uso de /mcp para ver y deshabilitar servidores innecesarios, y /context para ver qué está consumiendo espacio de contexto.

08 Lista de comandos prácticos

Estos son los comandos diarios más útiles:

/model

Cambiar de modelo. Sonnet es un buen valor predeterminado; Utilice Opus para razonamientos complejos.

/clear

Borrar el contexto actual. Úselo cuando cambie a un trabajo no relacionado.

`1`	`/compact`

Comprimir el historial de conversaciones. Úselo cuando finalice una fase pero continúe la misma tarea.

`1`	`/context`

Inspeccione el uso del contexto y encuentre qué está ocupando espacio.

/status

Verifique la suscripción o el estado relacionado con el uso. El centro de ayuda de Anthropic también recomienda monitorear la asignación restante.

/mcp

Vea y administre servidores MCP y desactive las herramientas que no sean necesarias para la tarea actual.

Si utiliza la facturación API, /cost puede resultar útil. Pero para las suscripciones Pro/Max, los documentos de Claude Code explican que la estimación en dólares de “/cost” no es la referencia de facturación correcta; los suscriptores deberían confiar más en la información de uso como /stats y /status.

09 Un flujo de trabajo para ahorrar cuotas

Un flujo de trabajo práctico se ve así:

Ejecute /clear antes de comenzar una nueva tarea.
Utilice Sonnet de forma predeterminada.
Deje que Claude inspeccione primero la estructura del proyecto y los archivos clave, no todo el repositorio.
Ejecute /compact después de cada pequeña fase.
Cambie a Opus solo para bloqueadores duros.
Filtre registros, errores y pruebe los resultados antes de pegarlos.
Ejecute /clear una vez finalizada la tarea; No comience un nuevo trabajo con un contexto obsoleto.
Revise periódicamente CLAUDE.md, MCP y las habilidades para reducir el contexto siempre activo.

La idea central es simple: dejar que Claude vea sólo lo que realmente necesita para la tarea actual.

10 Resumen

El uso de Claude Code que se agota rápidamente no suele deberse a una sola cosa. A menudo es una combinación de modelos de alto costo, largas conversaciones sin borrar, demasiados archivos y registros, contexto de reglas y MCP pesado, reutilización de caché más débil y fluctuaciones máximas de capacidad.

Las soluciones prácticas también son sencillas:

Utilice Sonnet para el trabajo diario.
Guarde Opus para problemas verdaderamente complejos.
Utilice /compact cuando finalice una fase.
Utilice /clear al cambiar de tarea.
Utilice /context para encontrar el contexto hinchado.
Adelgazar CLAUDE.md, reglas, MCP y habilidades.
No volcar todo el repositorio, registros completos o lotes de imágenes grandes en contexto.

La cantidad de trabajo que puede soportar el mismo plan Pro o Max depende en gran medida de cómo gestiona el contexto. Si reduce el contexto y aclara los límites de las tareas, Claude Code se sentirá mucho más estable.

Referencias

Centro de ayuda de Claude: uso de Claude Code con su plan Pro o Max: https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Centro de ayuda de Claude: Acerca del uso del plan Max de Claude: https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs: Gestione los costes de forma eficaz: https://code.claude.com/docs/en/costs
Anthropic Docs: almacenamiento en caché rápido: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching