Claude Code on KnightLi Blog

¿Cómo utilizar las habilidades de investigación académica? Kit de habilidades de investigación académica de Claude Code

Sat, 06 Jun 2026 22:26:00 +0800

Imbad0202/academic-research-skills es un conjunto de habilidades de investigación académica para Claude Code. Cubre el proceso completo desde la investigación, redacción, revisión, revisión hasta finalización. El objetivo no es permitir que la IA escriba artículos por usted, sino facilitar el tedioso trabajo de asistencia a la investigación.

Hay una frase en el archivo README que es muy precisa: la IA es su copiloto, no el piloto. Puede ayudarle a encontrar literatura, organizar citas, verificar la lógica, revisar simulaciones y conversiones de formato, pero la definición real del problema, la selección del método, la interpretación de los resultados y las oraciones argumentativas aún deben ser responsabilidad del investigador.

¿Qué capacidades contiene?

Este proyecto no es un solo mensaje, sino un conjunto completo de sistemas de comando y habilidades de Claude Code. Los módulos principales enumerados en el README incluyen:

Investigación profunda: equipo de investigación de 13 agentes que respalda la facilitación socrática, la revisión sistemática PRISMA, la detección de intenciones, la verificación de modelos cruzados y la validación de la API Semantic Scholar;
Trabajo académico: proceso de redacción de artículos con 12 agentes, que incluyen calibración de estilo, control de calidad de la escritura, refuerzo de LaTeX, visualización, asesoramiento de revisión, conversión de citas, etc.;
Revisor de artículos académicos: revisión por pares con múltiples perspectivas de 7 agentes, incluido el editor en jefe, revisores dinámicos y Devil’s Advocate;
Proceso Académico: proceso de 10 etapas con puntos de control adaptativos, verificación de reclamos, Pasaporte de Materiales y control de integridad;
Metadatos del nivel de acceso a datos: marque los niveles de acceso a datos sin procesar, redactados, solo verificados y otros para la habilidad;
Esquema de informes de referencia: limitar los informes de referencia para reducir las comparaciones deshonestas;
Archivo de bloqueo de reproducibilidad de artefactos: registra la configuración relacionada con el experimento de reproducción.

Tiene grandes ambiciones: no se trata de “escribir un resumen para mí”, sino de dividir el flujo de trabajo académico en etapas que puedan ser inspeccionadas, rastreadas y revisadas.

Cómo instalar

README recomienda utilizar el complemento Claude Code para instalar:

1
2

/plugin marketplace add Imbad0202/academic-research-skills
/plugin install academic-research-skills

Después de la instalación, puedes probar:

`1`	`/ars-plan`

Le ayudará a estructurar su artículo a través del diálogo socrático. También puede probar la revisión de la literatura directamente:

`1`	`/ars-lit-review "your topic"`

Los requisitos previos son principalmente:

Última versión del Código Claude;
ANTHROPIC_API_KEY;
Pandoc opcional, para DOCX;
Opcional tectónica y Fuente Han Serif TC para APA 7.0 PDF.

El archivo README también menciona que si usa Codex CLI, puede consultar su distribución hermana: academic-research-skills-codex. En otras palabras, el repositorio principal es nativo de Claude Code, pero el contenido del flujo de trabajo tiene una versión Codex.

¿Por qué enfatizar la participación humana?

Este proyecto rechaza claramente la ilusión del “científico de IA totalmente automatizado”. El README menciona que los sistemas de investigación totalmente automatizados heredarán una serie de modos de falla: errores de implementación, ilusión de resultados, malentendidos de errores como descubrimientos, falsificación de métodos, ilusión de citas, etc.

Las habilidades de investigación académica están diseñadas para centrarse en la colaboración entre humanos y máquinas, en lugar de eliminar a los humanos. Utiliza puertas de integridad, verificación de reclamos, anclajes de citas, verificación entre modelos y otros mecanismos para recordarle: la IA puede ayudar con el trabajo duro, pero no puede asumir responsabilidades académicas por usted.

Esto es importante. En la escritura académica, lo más peligroso de la IA no es que el estilo de escritura sea parecido al de una máquina, sino que las citas, los datos y las conclusiones parecen reales pero en realidad son insostenibles.

¿Para quién es adecuado?

Es más adecuado para estas personas:

Investigadores que estén escribiendo artículos, reseñas, propuestas o refutaciones;
Personas que necesitan organizar sistemáticamente la literatura y las citas;
Personas que quieran utilizar Claude Code para gestionar su proceso de escritura académica;
Personas que quieran que la IA realice simulaciones de revisión y comprobaciones lógicas;
Personas que necesitan ayuda con APA, LaTeX, conversión y formato de citas;
Personas que pueden aceptar la colaboración entre humanos y máquinas, pero no quieren que la IA entregue el manuscrito de forma totalmente automática.

No es adecuado para “limpiar manuscritos” u “ocultar rastros de uso de IA”. El README también establece claramente que no es un humanizador. El objetivo es mejorar la calidad, no ayudarte a hacer trampa.

Riesgo de uso

Tenga mucho cuidado con las herramientas académicas de IA:

Las citas deben cotejarse manualmente con el texto original;
Los hechos y datos no pueden basarse únicamente en modelos;
Los dictámenes de tesis deben surgir de su propio criterio de investigación;
Las escuelas, revistas y conferencias pueden imponer requisitos de divulgación para el uso de IA;
Los datos no divulgados y la información sobre el tema no se pueden entregar al modelo de manera casual;
También se comprueban LaTeX generado automáticamente, explicaciones estadísticas y gráficos.

Mi consejo: utilícelo como asistente de investigación y asistente de revisión, no como herramienta de escritura. Deje que le ayude a hacer preguntas, encontrar lagunas, comprobar formatos y organizar citas, pero usted mismo debe controlar los argumentos clave.

Resumen

academic-research-skills es actualmente un conjunto completo de flujos de trabajo de habilidades de IA de investigación académica. La parte más valiosa no es “poder escribir un artículo”, sino dividir la literatura, la redacción, la revisión, la revisión, la verificación de citas y la verificación de integridad en etapas claras.

Si ya estás usando Claude Code y tienes tareas reales de escritura académica, puedes investigarlo seriamente. Pero recuerda: la IA es el copiloto, no el conductor. La responsabilidad académica en última instancia recae en el autor.

Fuentes de referencia

Imbad0202/habilidades-de-investigación-académica - GitHub

¿Cómo utilizar las operaciones profesionales? Gestiona tu proceso de búsqueda de empleo con Claude Code

Sat, 06 Jun 2026 22:26:00 +0800

santifer/career-ops es un sistema de búsqueda de empleo impulsado por inteligencia artificial construido sobre Claude Code. Divide el proceso de búsqueda de empleo en modos de habilidad, panel de control, generación de PDF y procesamiento por lotes, con el objetivo de convertir la búsqueda de empleo de una operación fragmentada en un sistema manejable.

La búsqueda de empleo en sí es muy parecida a un proyecto complejo: currículum, puesto, empresa, entrega, seguimiento, entrevista, revisión y gestión de versiones, todo requiere un mantenimiento continuo. Care-Ops quiere confiar estas tareas a la asistencia del agente AI.

¿Para qué es adecuado?

Puedes usarlo para gestionar:

Reanudar la versión;
Coincidencia de empleo;
Generar materiales de búsqueda de empleo;
carta de presentación;
Preparación de la entrevista;
Posiciones de procesamiento por lotes;
Salida de PDF;
Registros de entrega y estado de seguimiento.

Lo más destacado es utilizar Claude Code como motor de flujo de trabajo, en lugar de simplemente dejar que un modelo le escriba una carta de presentación.

¿Para quién es adecuado?

Más adecuado para:

Personas que buscan empleo de forma intensiva;
Personas que necesitan ajustar sus currículums para diferentes puestos;
Personas que quieran sistematizar el proceso de búsqueda de empleo;
Alguien familiarizado con Claude Code y la línea de comando;
Personas que necesiten generar, organizar y revisar materiales de solicitud de empleo en lotes.

Si solo solicita uno o dos puestos de vez en cuando, los documentos y formularios regulares pueden ser suficientes.

Usa límites

Es fácil exagerar la automatización de la búsqueda de empleo:

Los currículums no pueden fabricar experiencia;
El contenido generado por IA debe seguir siendo auténtico;
No entregar materiales de baja calidad a granel;
La preparación de la entrevista no puede limitarse a memorizar las respuestas de la IA;
Se deben proteger los datos personales, la información de la empresa y los registros laborales.

La IA puede ayudarte a organizarla y expresarla, pero no puede brindarte una experiencia real.

Resumen

El valor de las operaciones profesionales radica en tratar la búsqueda de empleo como un sistema operativo. Para las personas que están buscando trabajo seriamente, esto es más útil que dejar que la IA cambie temporalmente su currículum.

Si ya estás utilizando Claude Code y tienes muchos procesos de búsqueda de empleo, vale la pena consultar este proyecto; Si solo está solicitando un trabajo liviano, está bien utilizar primero formularios y plantillas de currículum.

Fuentes de referencia

santifer/operaciones profesionales - GitHub

¿Cómo utilizar la habilidad del gusto? Agregue algunas limitaciones estéticas a la generación de interfaz de usuario de IA

Sat, 06 Jun 2026 22:22:56 +0800

Leonxlnx/taste-skill es un proyecto front-end Agent Skill muy interesante. Su objetivo no es crear otra biblioteca de componentes de interfaz de usuario, sino agregar un conjunto de “restricciones estéticas” a las herramientas de programación de IA como Codex, Cursor y Claude Code para reducir la interfaz de plantilla que parece IA a primera vista.

El proyecto README lo llama Anti-Slop Frontend Framework. Esta afirmación es un poco exagerada, pero la dirección es muy precisa: el mayor problema al escribir interfaces para IA a menudo no es la imposibilidad de escribir código, sino que el diseño predeterminado es demasiado plano, la jerarquía es demasiado débil, el espaciado parece generarse automáticamente y los efectos de movimiento y las fuentes no se juzgan.

¿Qué es exactamente?

Taste Skills son esencialmente un conjunto de habilidades de agente que se pueden instalar, copiar y pegar. No son dependencias de tiempo de ejecución ni complementos del navegador, sino reglas de trabajo para los agentes de IA.

Requerirá que el modelo preste más atención al generar la interfaz:

diseño: El diseño no sólo debe centrar la tarjeta;
tipografía: el tamaño de fuente, el grosor de la fuente y la altura de la línea deben ser jerárquicos;
espaciado: los espacios en blanco, los márgenes y la densidad deben coincidir con la escena;
movimiento: los efectos de movimiento deben servir para la interacción, no sólo para añadir animación;
lenguaje de diseño: inferir el lenguaje de diseño según el tipo de producto;
antideslizamiento: evite plantillas, marcadores de posición y resultados a medio terminar.

El valor de este tipo de habilidad no es “escribir algunas indicaciones más”, sino fijar algunos juicios estéticos del front-end en reglas reutilizables para que puedan usarse en diferentes proyectos.

Cómo instalar

README recomienda usar npx skills add para instalar:

`1`	`npx skills add https://github.com/Leonxlnx/taste-skill`

Si solo instala la habilidad de diseño de front-end predeterminada, puede especificar:

`1`	`npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"`

Si confía en el comportamiento heredado, también puede instalar v1:

`1`	`npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend-v1"`

El proyecto también establece que puede copiar cualquier SKILL.md directamente en el proyecto o pegar el contenido en la conversación ChatGPT/Codex para su uso. En otras palabras, no tiene por qué estar vinculado a una plataforma específica.

¿Qué habilidades están integradas?

Taste Skill no es solo un archivo. Hay varias habilidades enumeradas en el archivo README:

Habilidad	Nombre de instalación	Propósito
habilidad gustativa	`design-taste-frontend`	Reglas estéticas predeterminadas del front-end, actualmente la versión 2 todavía se encuentra en iteración experimental
habilidad-gusto-v1	`design-taste-frontend-v1`	Preservar el comportamiento heredado
gpt-tasteskill	`gpt-taste`	Versión estricta más adecuada para GPT/Codex
habilidad de imagen a código	`image-to-code`	Primero genere la imagen de referencia, luego analice y luego escriba el código
rediseño-habilidad	`redesign-existing-projects`	Primero audite los proyectos existentes y luego cambie la interfaz de usuario
habilidades blandas	`high-end-visual-design`	Dirección visual de alta gama, suave y con mucho espacio en blanco
habilidad-minimalista	`minimalist-ui`	Interfaz de usuario de producto restringida de estilo noción/lineal
habilidad brutalista	`industrial-brutalist-ui`	Fuente industrial suiza, estilo experimental con fuerte contraste
habilidad de salida	`full-output-enforcement`	Se utiliza para suprimir la mitad de la salida y los marcadores de posición

También existen habilidades de generación de imágenes para generar imágenes de referencia para sitios web, dispositivos móviles y tableros de marca. No generan código directamente, sino que producen referencias visuales, que luego se entregan a Codex, Cursor o Claude Code para su implementación.

Adecuado para cómo usarlo

Si simplemente le pide a AI que escriba un formulario de antecedentes, simplemente indicar los requisitos puede ser suficiente. Pero si quieres hacer:

Sitio web oficial del producto;
Panel de control SaaS;
Página móvil;
Página de inicio de la marca;
Portafolio;
Interfaz de herramientas de alta gama;
Rediseño de la interfaz de usuario del proyecto existente;
Restaurar la interfaz desde la imagen de referencia.

Entonces Taste Skill será más útil. Le ayuda a limitar “qué tipo de interfaz debería ser” de antemano, en lugar de esperar a que la IA genere un montón de tarjetas y luego regañarlas poco a poco.

Yo lo usaría así:

Los nuevos proyectos utilizan design-taste-frontend primero;
Los proyectos Codex/GPT pueden probar gpt-taste;
Utilice redesign-existing-projects para revisar proyectos existentes;
Agregue minimalist-ui, high-end-visual-design o industrial-brutalist-ui cuando haya un estilo claro;
Si la IA siempre deja TODO u omite código, agregue full-output-enforcement.

No es un botón estético universal

Taste Skill resuelve el problema de que “la salida del front-end de IA tiene demasiadas plantillas”, pero no es un reemplazo del diseñador.

Es necesario dejar claros algunos límites:

No puede definir el posicionamiento de su marca por usted;
No puede garantizar que cada generación luzca bien;
Es más adecuado para personas con una base estética frontal hacer juicios secundarios;
No importa cuán detallada sea la habilidad, aún es necesario proporcionar antecedentes del producto, audiencia y prioridades funcionales;
Los equipos con sistemas de diseño existentes no deben permitir que las habilidades cubran especificaciones internas.

En otras palabras, es más como un “andamio estético generado por el front-end”. Puede aumentar el límite inferior predeterminado, pero el efecto final aún depende de que usted revise, tome capturas de pantalla, ajuste CSS y verifique dispositivos reales.

Resumen

El valor de taste-skill es que convierte una gran cantidad de experiencia en diseño de front-end en reglas ejecutables por el Agente. Para herramientas como Codex, Cursor y Claude Code, esta habilidad es muy adecuada para compensar las deficiencias de “poder escribir código pero perder calidad fácilmente”.

Si utiliza con frecuencia la IA para generar páginas frontales, especialmente si está harto de grandes degradados, grandes esquinas redondeadas, tarjetas de pantalla completa, íconos aleatorios e interfaces sin capas similares a plantillas, puede usarla como punto de partida. Pero no lo consideres un director de diseño, los proyectos reales aún requieren que tomes tus propias decisiones.

Fuentes de referencia

Leonxlnx/taste-skill - GitHub

Claude Opus 4.8 ya está disponible: Anthropic refuerza la programación y las tareas de agentes

Fri, 29 May 2026 15:22:47 +0800

Anthropic publicó Claude Opus 4.8 el 28 de mayo de 2026. Es una nueva versión de la serie Opus, con una posición oficial muy clara: no es un cambio de nombre generacional, sino una mejora sobre Opus 4.7 en programación, tareas de agentes, razonamiento y trabajo de conocimiento experto.

Esta actualización también importa para usuarios normales de chat, por supuesto, pero lo más interesante está en Claude Code y en los escenarios de agent con tareas largas. Anthropic describe Opus 4.8 como un colaborador más fiable: en tareas complejas, debería juzgar mejor cuándo preguntar, cuándo avanzar y cuándo actuar con cautela.

Puntos clave de esta actualización

Claude Opus 4.8 ya está disponible y mantiene el mismo precio. Anthropic también destacó varios cambios relacionados:

Opus 4.8 sigue mejorando frente a la generación anterior en evaluaciones de código, capacidades de agente, razonamiento y trabajo de conocimiento.
Los usuarios de claude.ai pueden controlar cuánto effort dedica Claude a una tarea.
Claude Code añade dynamic workflows para manejar problemas de mayor escala.
El fast mode de Opus 4.8 puede trabajar a unas 2,5 veces la velocidad y cuesta tres veces menos que el fast mode del modelo anterior.

Vistos en conjunto, estos cambios muestran que Anthropic no solo está haciendo una pequeña mejora de puntuación del modelo. Está ajustando el producto alrededor de la idea de “ejecutar tareas complejas durante mucho tiempo”. Un modelo más potente es solo una parte; el control de tareas, la descomposición del flujo de trabajo y la estructura de costes son igual de importantes.

Por qué los usuarios de Claude Code deberían prestarle más atención

Para un agent de programación como Claude Code, el mayor riesgo no es no saber escribir una función concreta, sino perderse dentro de un repositorio real. Necesita leer archivos, entender dependencias, ejecutar pruebas, revisar errores, ajustar el plan y mantener los cambios dentro de un alcance razonable.

Los puntos fuertes de Opus 4.8 encajan justo con estos problemas:

Es más adecuado para agentic tasks, es decir, tareas en las que el modelo debe planificar de forma continua, llamar herramientas, observar resultados y ajustar la estrategia.
Da más importancia al judgement, por lo que puede detenerse y confirmar cuando hay incertidumbre, en lugar de seguir escribiendo algo equivocado con demasiada confianza.
Dynamic workflows hace que Claude Code sea más adecuado para problemas grandes y de varios pasos.

Si estas capacidades se mantienen estables en proyectos reales, la forma de usar Claude Code se acercará más a “darle un objetivo claro y dejar que avance”, no solo pedirle que complete un fragmento de código.

Qué significa el control de effort

Anthropic añadió esta vez control de effort a claude.ai, y el significado es directo: el usuario puede ajustar cuánta energía dedica el modelo a una tarea.

Esto es muy práctico en el uso diario. Las preguntas simples no necesitan razonamiento profundo, mientras que las tareas complejas sí merecen que el modelo piense un poco más. Antes, muchos usuarios solo podían expresar “ten más cuidado” o “responde rápido” mediante el prompt. Ahora ese tipo de control empieza a entrar en la capa de producto.

Para desarrolladores, también es una señal: los futuros productos de agent no solo expondrán “qué modelo elegir”, sino más estrategias de ejecución, como velocidad, coste, profundidad de razonamiento, agresividad al llamar herramientas y preferencia de riesgo.

El cambio de coste en fast mode es clave

Anthropic menciona que el fast mode de Opus 4.8 puede alcanzar unas 2,5 veces la velocidad, con un coste mucho menor que el fast mode del modelo anterior.

Este punto puede quedar tapado por las noticias sobre capacidades del modelo, pero es muy importante para los flujos de trabajo reales. Muchas tareas de agent no se ejecutan una sola vez, sino de forma repetida:

Generar un primer borrador
Ejecutar pruebas
Corregir fallos
Volver a ejecutar pruebas
Seguir modificando según el review

Si fast mode es lo bastante barato, los equipos estarán más dispuestos a integrarlo en procesos frecuentes, en lugar de reservar el modelo superior solo para tareas críticas ocasionales. Cuando bajan la velocidad y el coste, los agents tienen más facilidad para pasar de “efecto demo” a “herramienta diaria”.

Relación con Opus 4.7

Opus 4.8 se parece más a una versión mejorada orientada a la usabilidad. Hereda el posicionamiento de Opus 4.7, pero empuja aún más hacia la programación, las tareas de agentes y el trabajo profesional.

Por la forma en que Anthropic lo describe, Opus 4.8 no solo responde mejor: colabora mejor. Dentro de una tarea, debería tener más claro cuándo necesita información, cuándo un plan no es sólido y cuándo conviene ganar confianza antes de hacer cambios grandes.

Este tipo de capacidades es difícil de juzgar con un único benchmark. La verdadera validación está en cómo se comporta en repositorios grandes, reglas de negocio complejas, tareas de contexto largo y correcciones en varias rondas.

Impacto en la competencia de programación con AI

En 2026, la competencia entre modelos ya se ha desplazado claramente de la “capacidad de chat” a “si puede hacer trabajo”. OpenAI, Anthropic, Google y xAI están uniendo cada vez más los modelos con las cadenas de herramientas: el modelo razona, las herramientas ejecutan y la capa de producto mantiene la tarea dentro de un rango controlable.

El lanzamiento de Claude Opus 4.8 continúa esa tendencia. Su foco no es presumir de una capacidad aislada, sino reforzar tres enlaces:

El modelo en sí es más adecuado para código y tareas de agentes.
Claude Code puede descomponer flujos de trabajo más grandes.
La capa de producto empieza a ofrecer controles de ejecución como effort y fast mode.

Para desarrolladores, el significado práctico es que al elegir un modelo no basta con mirar “cuál es el más inteligente”. También hay que ver si encaja con la herramienta usada, si puede llamar herramientas de forma estable, si el coste de tareas largas es aceptable y si es fácil corregirlo cuando falla.

Mi lectura

Claude Opus 4.8 es una actualización bastante pragmática. No centra su relato en un nuevo parámetro exagerado, sino que sigue cubriendo lo que más necesitan los flujos de agent: judgement, estabilidad, velocidad, coste y control de tareas.

Si ya usas Claude Code, vale la pena probar esta actualización pronto. Es especialmente útil compararla con tareas largas en repositorios reales, como refactorizaciones entre módulos, corrección de pruebas, sincronización de documentación o localización de bugs complejos.

Si solo eres usuario normal de chat, los cambios de Opus 4.8 quizá no resulten tan impactantes de inmediato como el lanzamiento de una nueva generación de modelos. Pero como dirección de producto, muestran que Anthropic sigue empujando Claude hacia la “ejecución fiable de trabajos complejos”.

Enlace original: Introducing Claude Opus 4.8

CLIProxyAPI: envolver Codex, Claude Code y Gemini CLI en una API unificada

Sun, 24 May 2026 10:03:33 +0800

CLIProxyAPI es un proyecto con mucho sabor a ingeniería práctica de comunidad. No es otro gran modelo, ni un simple reenviador de API. Lo que hace es volver a empaquetar un conjunto de herramientas de IA que originalmente son interactivas, orientadas a CLI o basadas en login OAuth, para exponerlas como un servicio API unificado.

Soporta Gemini CLI, OpenAI Codex, Claude Code, Amp CLI, AI Studio Build y servicios ascendentes compatibles con OpenAI. Dicho de otra forma, intenta resolver esta pregunta:

Tengo herramientas CLI, cuentas de suscripción y sesiones OAuth. ¿Puedo conectar esas capacidades a mi propio cliente, scripts, IDE o servicios internos como si llamara a una API normal?

La respuesta de CLIProxyAPI es sí: añadir una capa proxy en medio y convertir capacidades CLI de distintas fuentes en interfaces compatibles con OpenAI, Gemini, Claude y Codex.

El problema real que resuelve

Muchas herramientas de programación con IA son potentes, pero su forma de uso por defecto no encaja bien con la automatización.

Por ejemplo:

Gemini CLI puede usarse con login de cuenta, pero tu programa probablemente prefiera llamar a una API HTTP.
Claude Code es muy útil para programación interactiva, pero al integrarlo con otros clientes aparecen diferencias de protocolo.
Codex CLI soporta login OAuth y capacidades estilo Responses, pero no todas las herramientas superiores saben cómo hablar con él.
Un equipo puede tener varias cuentas y necesitar rotación, balanceo de carga, exclusión de cuentas anómalas y visibilidad de cuotas.
Quizá quieras que algunas herramientas solo vean un formato OpenAI, aunque el backend real sea Gemini, Claude o Codex.

CLIProxyAPI se posiciona como una capa de adaptación de protocolo entre esas herramientas y los clientes.

Oculta el lado complejo detrás: OAuth, login CLI, varias cuentas, diferentes protocolos y distintos providers. En la parte frontal expone interfaces más familiares, como OpenAI Chat Completions, OpenAI Responses, Gemini, Claude Messages y endpoints relacionados con Codex.

Resumen de capacidades

Según el README y la documentación oficiales, CLIProxyAPI se centra actualmente en:

Ofrecer endpoints API compatibles con OpenAI, Gemini, Claude y Codex para modelos CLI.
Conectar OpenAI Codex y Claude Code mediante login OAuth.
Soportar respuestas en streaming y sin streaming, además de WebSocket en algunos escenarios.
Soportar function calling, tool calling y entrada multimodal.
Soportar rotación de varias cuentas y balanceo de carga para Gemini, OpenAI y Claude.
Soportar claves API de Gemini AI Studio.
Soportar pools de cuentas para AI Studio Build, Gemini CLI, Claude Code y OpenAI Codex.
Conectar upstreams compatibles con OpenAI mediante configuración, por ejemplo OpenRouter.
Ofrecer un SDK en Go para incrustar la capacidad proxy en tus propios servicios.

El valor de este tipo de proyecto no está en “soportar unos cuantos nombres de modelo más”, sino en empaquetar login de cuentas, traducción de protocolos y enrutamiento de solicitudes.

Para quién encaja

CLIProxyAPI encaja mejor con varios tipos de usuarios.

El primer grupo son usuarios intensivos de programación con IA. Ya usas Codex, Claude Code y Gemini CLI, pero quieres conectarlos a Cursor, Cline, RooCode, Amp, scripts internos o flujos de trabajo propios.

El segundo grupo son usuarios con pools de varias cuentas. Por ejemplo, tienes varias sesiones de Gemini, OpenAI o Claude y no quieres cambiar manualmente. Quieres rotación automática, uso equilibrado y diagnóstico rápido cuando una cuenta falla.

El tercer grupo son quienes construyen gateways internos para equipos. El equipo no quiere que cada cliente adapte por separado Gemini, Claude y Codex, sino exponer una API unificada mediante una capa intermedia.

El cuarto grupo son quienes disfrutan trabajando con protocolos. Te puede interesar cómo convertir entre Responses, Chat Completions, Claude Messages y Gemini v1beta, o quizá quieras alternar backends desde el mismo cliente.

Si solo haces preguntas ocasionales a la IA, o solo usas las apps oficiales para chatear, el coste de desplegar y mantener CLIProxyAPI puede parecer excesivo.

En qué se diferencia de un proxy API normal

Un proxy API típico suele ser:

`1`	`Cliente -> API proxy -> API del modelo upstream`

La cadena de CLIProxyAPI se parece más a:

`1`	`Cliente -> CLIProxyAPI -> CLI / sesión OAuth / pool de cuentas -> servicio de modelo`

La diferencia es que no solo reenvía API keys. También maneja herramientas CLI, cuentas OAuth, superficies de protocolo y alias de modelos.

Herramientas como Codex y Claude Code no siguen exactamente el patrón tradicional de “dame una API key y puedo llamarlo de forma estable”. CLIProxyAPI envuelve esas sesiones de login y la lógica de llamada para que clientes externos puedan acceder a ellas como si fueran APIs normales.

Eso es lo que lo hace atractivo, y también lo que lo vuelve complejo.

Malentendidos comunes al usarlo

Primero, no asumas que un /v1/... unificado elimina todas las diferencias de protocolo.

La documentación de CLIProxyAPI recuerda que, cuando necesitas la forma de solicitud y respuesta de un tipo concreto de backend, conviene usar rutas provider-specific. Por ejemplo, para estilo messages usa /api/provider/{provider}/v1/messages; para rutas de modelo Gemini usa /api/provider/{provider}/v1beta/models/...; para estilo chat-completions usa /api/provider/{provider}/v1/chat/completions.

Una entrada unificada es cómoda, pero la semántica de cada protocolo no desaparece. Tool calling, respuestas en streaming, entrada multimodal y manejo de mensajes de sistema pueden variar según el backend.

Segundo, el nombre del modelo no identifica de forma única el backend.

Si varios backends exponen el mismo nombre de modelo visible para el cliente, la ruta por sí sola puede no fijar cuál ejecuta realmente la inferencia. Para fijarlo estrictamente, usa alias únicos, prefijos, o evita que varios backends expongan el mismo nombre de modelo.

Tercero, la rotación de varias cuentas no significa cuota infinita.

La rotación solo reparte mejor el uso entre el pool de cuentas. No evita los límites reales del servicio upstream. Cuentas anómalas, cuota agotada, controles de riesgo y sesiones OAuth expiradas necesitan monitoreo separado.

Cuarto, no es una caja mágica sin mantenimiento.

Una vez que lo incorporas a tu flujo diario, tendrás que preocuparte por configuración, logs, estado de cuentas upstream, actualizaciones, compatibilidad de clientes y límites de seguridad.

Gestión y monitoreo

El README oficial indica que desde v6.10.0, CLIProxyAPI y CPAMC ya no incluyen estadísticas de datos integradas. Si necesitas estadísticas de uso, puedes combinarlo con proyectos independientes:

CPA Usage Keeper: sincroniza datos de CLIProxyAPI, los guarda en SQLite y ofrece API de agregación y dashboard.
CLIProxyAPI Usage Dashboard: panel local-first de uso y cuotas, con cuentas, modelos, ventanas de tiempo y cuota restante de Codex.
CPA-Manager: centro de gestión más completo para monitoreo de solicitudes, estimación de costes, inspección de pools de cuentas, localización de cuentas anómalas y sugerencias de limpieza.

Esto muestra que el núcleo de CLIProxyAPI está más cerca de una capa de proxy y protocolo que de un backend comercial todo en uno. Si lo usa un equipo, conviene pensar desde el principio en logs, monitoreo y gestión de cuentas.

Una forma razonable de probarlo

Si quieres probarlo, un orden sensato sería:

Levantarlo con el Quick Start de la documentación oficial.
Conectar solo un provider, por ejemplo Gemini CLI o Codex, y confirmar que las solicitudes básicas funcionan.
Probar después capacidades de mayor riesgo, como streaming, tool calling y entrada multimodal.
Confirmar qué endpoint usa realmente el cliente, sin mezclar rutas de protocolo.
Añadir al final rotación de varias cuentas, paneles de gestión y estadísticas de uso.

No conectes desde el principio Gemini, Codex, Claude, OpenRouter, varias cuentas y todos los clientes a la vez. Cuando algo falle, será difícil saber si el problema es autenticación, protocolo, nombre de modelo o cuenta upstream.

También hay que pensar en el límite de seguridad

CLIProxyAPI puede tocar sesiones de login de cuentas, API keys, credenciales OAuth y contenido de solicitudes. Si solo corre en tu propia máquina, el riesgo es relativamente controlable. Si lo expones a internet o a una intranet de equipo, debes tratar en serio la autenticación, el control de acceso, el enmascaramiento de logs y el aislamiento de red.

Los endpoints de administración, en especial, deberían limitarse a localhost o a una red interna confiable. No expongas interfaces de administración directamente solo por ahorrar tiempo.

Conclusión

El valor de CLIProxyAPI está en reunir capacidades de IA dispersas entre múltiples CLI, cuentas y protocolos en una capa API programable.

Encaja con usuarios intensivos de programación con IA, usuarios con varias cuentas y escenarios de gateway interno para equipos. Encaja menos con usuarios ligeros que solo quieren algo de “abrir y usar” sin mantenimiento.

Si estás experimentando con Codex, Claude Code y Gemini CLI, y quieres conectarlos a tu propio cliente o flujo de automatización, CLIProxyAPI merece una mirada seria. Pero conviene tratarlo como infraestructura, no como una pequeña herramienta desechable.

Referencias:

¿Qué es CodeGraph? Un mapa local de código para Claude Code, Codex y Cursor

Sat, 23 May 2026 21:09:46 +0800

CodeGraph es un grafo local de conocimiento de código pensado para herramientas de programación con IA. Indexa un proyecto por adelantado y organiza relaciones de símbolos, grafos de llamadas, estructura del código, relaciones de rutas y otra información en un grafo consultable. Así, Claude Code, Codex CLI, Cursor, OpenCode, Hermes Agent y herramientas similares no tienen que depender siempre de grep, glob, Read y subagentes exploratorios para entender un proyecto.

Resuelve un problema muy práctico: cuando un AI Agent trabaja sobre una base de código grande, mucho coste no se va en modificar código, sino en encontrar dónde está el código relevante. Si cada tarea empieza con búsquedas, lecturas y filtrado repetidos, se consumen tokens, tiempo y llamadas a herramientas. CodeGraph intenta convertir primero el repositorio en un mapa local, para que el agente consulte el mapa antes de decidir qué archivos leer.

Qué problemas intenta resolver

En proyectos pequeños, las herramientas de programación con IA suelen funcionar bien. Hay pocos archivos, la búsqueda es rápida y leer archivos no cuesta mucho. En proyectos grandes aparecen problemas comunes:

El agente llama repetidamente a grep, find, ls y Read solo para entender un módulo.
Los subagentes exploratorios leen muchos archivos irrelevantes, pero el contexto principal sigue poco claro.
Una pregunta de arquitectura gasta demasiados tokens localizando archivos.
Antes de modificar una función, no está claro quién la llama ni a qué llama ella.
En proyectos web, la relación entre rutas URL y funciones handler no siempre es evidente.

CodeGraph intenta adelantar ese trabajo de “encontrar el camino”. Una vez creado el índice, el agente puede consultar símbolos relacionados, callers, callees, alcance de impacto y fragmentos de código.

Instalación

El proyecto ofrece scripts de instalación multiplataforma y no exige preparar Node.js manualmente:

`1`	`curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh \| sh`

En Windows PowerShell:

`1`	`irm https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.ps1 \| iex`

Si ya tienes un entorno Node, puedes usar npm directamente:

`1`	`npx @colbymchenry/codegraph`

O instalarlo globalmente:

`1`	`npm i -g @colbymchenry/codegraph`

El instalador detecta y configura agentes instalados, como Claude Code, Cursor, Codex CLI, opencode y Hermes Agent. Escribe la configuración MCP server y archivos de instrucciones correspondientes para que esas herramientas sepan cuándo llamar a CodeGraph.

Inicializar un proyecto

Después de instalar, crea el índice dentro del proyecto objetivo:

1
2

cd your-project
codegraph init -i

Este comando genera un índice de grafo de conocimiento a nivel de proyecto. El README indica que, si el proyecto contiene un directorio .codegraph/, los agentes pueden usar automáticamente las herramientas de CodeGraph.

Si quieres dejar de usarlo, puedes eliminar la configuración global:

`1`	`codegraph uninstall`

Esto elimina la configuración MCP server, instrucciones y permisos escritos por el instalador. El índice .codegraph/ del proyecto no se borra automáticamente. Para eliminar el índice del proyecto, usa codegraph uninit.

Por qué ayuda a los agentes

Herramientas como Claude Code, Codex CLI y Cursor suelen explorar antes de modificar: buscan archivos, leen puntos de entrada, inspeccionan referencias y siguen cadenas de llamadas. Para humanos esto parece recorrer el proyecto. Para modelos, se convierte en una serie de llamadas a herramientas y consumo de contexto.

CodeGraph convierte esa fase en consultas al índice. El agente puede usar primero codegraph_context para encontrar puntos de entrada, símbolos y fragmentos relevantes, y luego usar codegraph_explore u otras herramientas para leer lo necesario. Los beneficios son:

Menos archivos irrelevantes leídos.
Menos llamadas a herramientas de búsqueda.
Localización más rápida del código realmente relevante.
Mejor visión del impacto antes de editar.
Respuestas más fáciles a preguntas de arquitectura en repositorios grandes.

El README muestra benchmarks en siete repositorios open source reales comparando ejecuciones con y sin CodeGraph. De media, habilitar CodeGraph redujo coste, tokens, latencia y llamadas a herramientas. Las cifras exactas dependen del tamaño del proyecto, lenguaje, tipo de pregunta y uso del agente, pero la dirección es clara: cuanto más grande el repositorio, más valor tiene el preindexado.

Capacidades principales

1. Construcción inteligente de contexto

Una llamada a herramienta puede devolver puntos de entrada, símbolos relacionados y fragmentos de código, reduciendo la necesidad de que el agente lance muchas tareas exploratorias antes de filtrar resultados. Es útil para entender arquitectura, localizar módulos y analizar entradas de funcionalidades.

2. Búsqueda de texto completo

CodeGraph usa FTS5 para búsqueda de texto completo, lo que permite buscar nombres y texto rápidamente en todo el código. No sustituye todos los usos de grep, pero da al agente una primera parada más estructurada.

3. Análisis de impacto

Antes de cambiar una función, clase, método o ruta, el agente puede consultar callers, callees y radio de impacto. Esto es especialmente útil para refactorizar, corregir bugs y eliminar código antiguo, donde el mayor riesgo es olvidar llamadas aguas arriba o aguas abajo.

4. Actualización automática

El README menciona que CodeGraph usa eventos nativos del sistema de archivos, como FSEvents, inotify y ReadDirectoryChangesW, junto con debounce auto-sync. En la práctica, el índice se actualiza con los cambios locales de código, sin reconstruirlo manualmente tras cada edición.

5. Soporte multilenguaje

El proyecto lista soporte para más de 19 lenguajes, incluyendo TypeScript, JavaScript, Python, Go, Rust, Java, C#, PHP, Ruby, C, C++, Swift, Kotlin, Dart, Lua, Luau, Svelte, Liquid y Pascal / Delphi.

Eso lo hace adecuado para repositorios multilenguaje y proyectos full-stack, no solo para un único lenguaje.

6. Conciencia de rutas web

CodeGraph también detecta archivos y declaraciones de rutas en múltiples frameworks web, conectando URL pattern con funciones handler. El README menciona Django, Flask, FastAPI, Express, NestJS, Laravel, Rails, Spring, Gin, Axum, ASP.NET, Vapor, React Router, SvelteKit y otros.

Esto es práctico. En muchos proyectos web, el punto de entrada real no es una función main obvia, sino rutas, controllers, handlers, views o resolvers. Si el agente entiende primero la relación entre URL y handler, puede comprender mucho más rápido el flujo de negocio.

Diseño local-first

CodeGraph enfatiza que es 100% local. No necesita API key ni depende de servicios externos. Los datos del índice se guardan en una base SQLite local.

Para proyectos empresariales, repositorios privados o código sensible, esto importa. Con herramientas de IA conectadas al código, la preocupación no suele ser solo “si pueden encontrar el código”, sino “si la estructura del código y el índice se envían fuera”. CodeGraph se plantea como construcción local, consulta local y servicio local para agentes.

Por supuesto, local también implica considerar espacio en disco, tiempo de indexado, vigilancia de archivos y tamaño del proyecto. En repositorios muy grandes, la inicialización y la sincronización posterior siguen requiriendo recursos.

Escenarios adecuados

CodeGraph encaja especialmente en:

Bases de código grandes donde se preguntan a menudo cosas de arquitectura y cadenas de llamadas.
Uso de Claude Code, Codex CLI, Cursor y otros agentes para entender y modificar código.
Reducir lecturas aleatorias de archivos, búsquedas amplias y exploración repetida del agente.
Analizar impacto antes de cambios.
Proyectos web con rutas complejas donde importa encontrar rápido el handler de una URL.
Equipos que quieren dar a los AI Agents un índice local más estable del proyecto.

Si el proyecto tiene solo unas decenas de archivos, la búsqueda normal puede ser suficiente y la ventaja de CodeGraph quizá no se note. Su mayor valor aparece en repositorios medianos o grandes y en flujos donde el agente explora mucho.

Qué tener en cuenta

Primero, CodeGraph no sustituye la revisión de código ni los tests. Ayuda al agente a encontrar código relevante más rápido, pero no garantiza que sus cambios sean correctos.

Segundo, la calidad del índice afecta los resultados. Si el proyecto tiene estructura compleja, mucho código generado, lenguajes mezclados o artefactos de build sin excluir, el índice puede volverse ruidoso. Antes de usarlo en serio, revisa .gitignore, la estructura del proyecto y el alcance de indexado.

Tercero, la configuración MCP y las instrucciones del agente son clave. El README también recuerda que CodeGraph ayuda solo cuando se consulta correctamente. Si el agente lo ignora y sigue leyendo muchos archivos directamente, el preindexado se convierte en coste adicional.

Cuarto, aunque sea una herramienta local, los permisos importan. El instalador escribe configuración de agente y listas de permisos. En equipos, conviene revisar esas configuraciones de forma centralizada.

Resumen

CodeGraph puede entenderse de forma sencilla: da a los AI Agents un mapa local del código. No hace más inteligente al modelo; ayuda a que se pierda menos.

Cuando Claude Code, Codex CLI, Cursor y herramientas similares se enfrentan a repositorios grandes, la parte cara suele ser la exploración. CodeGraph usa relaciones de símbolos, grafos de llamadas, grafos de rutas y búsqueda de texto completo preindexados para adelantar la fase de “dónde está el código”, dejando más presupuesto para entender y modificar.

Si ya usas herramientas de programación con IA en proyectos reales y a menudo ves que el agente lee muchos archivos sin encontrar lo importante, vale la pena probar CodeGraph. Representa una dirección importante para estas herramientas: no solo modelos más fuertes, sino mejor contexto local de código para esos modelos.

Referencias:

Proyecto en GitHub: https://github.com/colbymchenry/codegraph

Claude Code ya tiene mercado de plugins: qué puedes instalar, cómo instalarlo y qué revisar antes

Sat, 23 May 2026 19:03:30 +0800

anthropics/claude-plugins-official es el directorio oficial de plugins de Claude Code gestionado por Anthropic. No es un repositorio de código cualquiera. Es un marketplace que el sistema de plugins de Claude Code puede usar directamente, con plugins mantenidos o seleccionados por Anthropic.

Este repositorio importa porque Claude Code está pasando de ser “una herramienta de programación con IA en línea de comandos” a convertirse en “un entorno de desarrollo extensible”. Los plugins pueden empaquetar Skills, Agents, Hooks, MCP servers, LSP servers, monitores en segundo plano y ajustes predeterminados para que equipos y comunidades los distribuyan de forma consistente.

Qué es este repositorio

El README lo define de forma directa: es un directorio curado de plugins de alta calidad para Claude Code.

La estructura principal se divide en dos partes:

/plugins: plugins desarrollados y mantenidos internamente por Anthropic.
/external_plugins: plugins de terceros procedentes de socios y la comunidad.

Es decir, contiene tanto capacidades oficiales como entradas externas seleccionadas del ecosistema. Para usuarios normales, el valor directo es poder descubrir e instalar plugins mediante el sistema /plugin de Claude Code. Para desarrolladores, sirve como una ventana al formato de plugins y a la dirección del ecosistema de Claude Code.

Cómo instalar plugins

El README ofrece un comando sencillo. Puedes instalar directamente desde el sistema de plugins de Claude Code:

`1`	`/plugin install {plugin-name}@claude-plugins-official`

También puedes abrir la entrada de descubrimiento de plugins dentro de Claude Code:

`1`	`/plugin > Discover`

La parte clave es @claude-plugins-official, que apunta al marketplace oficial de plugins. Según la documentación de Claude Code, claude-plugins-official es el marketplace oficial mantenido por Anthropic y está disponible por defecto en las instalaciones de Claude Code.

Cómo es un plugin

El README del repositorio muestra una estructura estándar:

plugin-name/
├── .claude-plugin/
│   └── plugin.json
├── .mcp.json
├── commands/
├── agents/
├── skills/
└── README.md

.claude-plugin/plugin.json es el archivo de metadatos del plugin. Normalmente declara el nombre, la descripción, la versión, el autor y otros campos. El resto de directorios existen según lo que proporcione el plugin:

skills/: instrucciones de habilidades que Claude puede invocar automáticamente.
commands/: slash commands.
agents/: definiciones de agents personalizados.
hooks/: lógica disparada por eventos.
.mcp.json: configuración de MCP server.
.lsp.json: configuración de servidores de lenguaje.
monitors/: configuración de monitores en segundo plano.
settings.json: ajustes predeterminados incluidos con el plugin.

Esto significa que un plugin de Claude Code no es un único tipo de extensión. Es un formato de empaquetado. Puede ser un pequeño comando o un flujo completo para un stack técnico concreto.

Qué direcciones ya aparecen en el directorio oficial

El directorio /plugins ya cubre bastantes escenarios de desarrollo, incluyendo:

Plugins LSP: typescript-lsp, pyright-lsp, rust-analyzer-lsp, gopls-lsp, clangd-lsp, csharp-lsp, jdtls-lsp, kotlin-lsp, lua-lsp, php-lsp, ruby-lsp, swift-lsp.
Flujos de programación: code-review, feature-dev, code-modernization, code-simplifier, commit-commands, pr-review-toolkit.
Configuración de Claude Code y desarrollo de plugins: claude-code-setup, claude-md-management, plugin-dev, skill-creator, mcp-server-dev.
Estilos de salida y capacidades especializadas: explanatory-output-style, learning-output-style, security-guidance, session-report, math-olympiad.

En /external_plugins se ven más herramientas y servicios de terceros, como github, gitlab, linear, asana, firebase, playwright, terraform, context7, serena, telegram y discord.

Este conjunto sugiere una tendencia: Claude Code no solo quiere ayudarte a editar archivos. También quiere conectarse con inteligencia de código, gestión de proyectos, servicios cloud, testing, infraestructura y herramientas de colaboración de equipo.

Por qué importa el sistema de plugins

Antes, muchas personalizaciones de Claude Code podían quedar repartidas en el directorio .claude/ de un proyecto, como commands, agents, skills o hooks. Eso funciona para flujos personales o un solo proyecto, pero no es ideal para reutilizar entre proyectos ni para distribuir de forma consistente dentro de un equipo.

Los plugins resuelven el problema de reutilización y distribución:

La misma configuración se puede instalar en varios proyectos.
Los comandos y skills tienen namespace, reduciendo conflictos.
Los plugins se pueden publicar y actualizar mediante un marketplace.
Los equipos pueden empaquetar buenas prácticas internas como plugins estándar.
La comunidad puede mantener extensiones para frameworks, lenguajes o servicios concretos.

La idea se parece a las extensiones de VS Code, los plugins de JetBrains o las extensiones de navegador. Cuando una herramienta empieza a tener un ecosistema estable de plugins, deja de ser solo un producto y empieza a convertirse en una plataforma.

Para qué sirve a los desarrolladores

Si solo eres usuario de Claude Code, el uso más práctico de este repositorio es encontrar plugins. Por ejemplo, si necesitas soporte LSP para TypeScript, Python, Rust o Go, puedes revisar primero si el directorio oficial ya tiene el plugin correspondiente. Si necesitas flujos de PR review, commit o modernización de código, los plugins oficiales también son un buen punto de partida.

Si desarrollas plugins, este repositorio funciona más como una biblioteca de referencia. Puedes estudiar su organización de directorios, el estilo de plugin.json, la forma de documentar en README y cómo Anthropic combina skills, agents, MCP, LSP y hooks.

La documentación de Claude Code también da una guía clara: usa .claude/ para personalización de un solo proyecto, pero conviértelo en plugin cuando quieras compartirlo con un equipo, reutilizarlo en varios proyectos, versionar releases o distribuirlo mediante un marketplace.

Los límites de seguridad importan

El README del repositorio empieza con una advertencia importante: asegúrate de confiar en un plugin antes de instalarlo, actualizarlo o usarlo. La razón es simple. Un plugin puede incluir MCP servers, archivos, scripts u otro software. Que Anthropic mantenga el directorio no significa que cada plugin vaya a comportarse exactamente como esperas en tu entorno local.

En la práctica, conviene hacer al menos estas comprobaciones:

Leer la página del plugin y su README antes de instalar.
Revisar si incluye .mcp.json, hooks, scripts ejecutables o monitores en segundo plano.
Tener especial cuidado con plugins que acceden a cuentas, repositorios, herramientas de chat o servicios cloud.
Probar plugins en un repositorio de pruebas antes de activarlos en proyectos importantes.
En equipos, revisar de forma centralizada el origen y la versión de los plugins.

Los plugins de programación con IA suelen tener más privilegios que un tema normal de editor. Pueden leer archivos del proyecto, llamar servicios externos, iniciar comandos locales o afectar flujos de commit y despliegue. Por eso el límite de confianza debe ser más estricto que “instalar una pequeña herramienta”.

Relación con el marketplace comunitario

La documentación de Claude Code indica que Anthropic mantiene dos marketplaces públicos de plugins:

claude-plugins-official: un conjunto curado de plugins mantenidos por Anthropic.
claude-community: un directorio comunitario donde las propuestas de terceros pasan por revisión.

Cumplen roles distintos. Los plugins comunitarios pueden entrar al proceso de review mediante formularios de envío. El directorio oficial se cura por separado y Anthropic decide qué incluir, sin un proceso público de solicitud. En resumen, claude-plugins-official se parece más a un directorio oficial seleccionado, mientras que claude-community es el directorio comunitario abierto.

Resumen

La importancia de anthropics/claude-plugins-official no es simplemente que exista otro repositorio en GitHub. Muestra que el mecanismo de extensiones de Claude Code se está volviendo más parecido a una plataforma: Skills, Agents, Hooks, MCP, LSP, monitores en segundo plano y ajustes predeterminados pueden empaquetarse, instalarse, actualizarse y distribuirse.

Para desarrolladores individuales, el directorio oficial de plugins puede reducir el coste de configurar Claude Code. Para equipos, ofrece una vía para estandarizar flujos internos. Para desarrolladores de plugins, muestra la estructura y la dirección del ecosistema que Anthropic está respaldando.

Lo siguiente que conviene observar no es solo un plugin concreto, sino si el ecosistema de plugins de Claude Code forma capas estables: plugins oficiales curados, plugins comunitarios, marketplaces privados de equipo y extensiones especializadas para lenguajes, frameworks y servicios SaaS populares. Si esa ruta funciona, Claude Code se parecerá cada vez más a una plataforma de desarrollo con IA programable, no solo a un asistente de línea de comandos.

Referencias:

Proyecto en GitHub: https://github.com/anthropics/claude-plugins-official
Documentación de plugins de Claude Code: https://code.claude.com/docs/en/plugins

Graphify resuelve la mayor limitación de Claude Code: convertir un codebase en un grafo consultable por IA

Thu, 21 May 2026 08:02:32 +0800

safishamsi/graphify es una herramienta de grafo de conocimiento para asistentes de programación con IA. Su objetivo es directo: tomar el código, documentación, SQL schemas, scripts, papers, imágenes, video y audio dentro de una carpeta de proyecto, convertirlos en un grafo consultable y evitar que los asistentes de IA dependan solo de grep, lectura completa de archivos o búsquedas improvisadas para entender el proyecto.

Proyecto: safishamsi/graphify

En el momento de preparar este artículo, la página de GitHub muestra unas 50.2k stars y 5.4k forks, con licencia MIT. El README lo describe así: escribe /graphify en tu asistente de programación con IA y mapeará todo el proyecto como un grafo de conocimiento consultable.

El problema central que resuelve

Los asistentes de programación con IA son cada vez más potentes, pero en codebases reales todavía encuentran varios problemas:

No saben cómo se conectan los módulos clave.
Leen muchos archivos, pero no forman un mapa general de arquitectura.
La búsqueda encuentra texto, pero no dependencias aguas arriba y aguas abajo.
Código, database schema, documentación e infraestructura están dispersos.
En colaboración de equipo, cada persona puede tener un modelo mental distinto de la estructura del proyecto.

Graphify intenta añadir una “capa de memoria” al proyecto. Conecta entidades de código, conceptos documentales, tablas de base de datos, configuración, notas de diseño y relaciones entre archivos para que el asistente de IA pueda consultar el grafo en lugar de escanear archivos desde cero cada vez.

Uso mínimo

El uso mínimo de Graphify es muy simple. Tras instalarlo, escribe esto en tu asistente de programación con IA:

`1`	`/graphify .`

En PowerShell, el / inicial se interpreta como separador de ruta, así que en Windows PowerShell usa:

`1`	`graphify .`

Después de ejecutarlo, genera el directorio graphify-out/ con tres archivos principales:

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

Cada archivo cumple una función:

graph.html: grafo interactivo que se abre en el navegador, con nodos clicables, filtros y búsqueda.
GRAPH_REPORT.md: puntos destacados del proyecto, conceptos clave, conexiones inesperadas y preguntas sugeridas.
graph.json: grafo completo, consultable después sin volver a leer todos los archivos.

Para generar una página de arquitectura más legible con diagramas Mermaid de flujo de llamadas, ejecuta:

`1`	`graphify export callflow-html`

Instalación y soporte de plataformas

El paquete de Graphify en PyPI se llama graphifyy, con doble y. El README advierte que otros paquetes graphify* en PyPI no están afiliados al proyecto, aunque el comando CLI sigue siendo graphify.

La instalación recomendada es:

`1`	`uv tool install graphifyy`

También puedes usar:

1
2

pipx install graphifyy
pip install graphifyy

Después, regístralo con tu asistente de IA:

`1`	`graphify install`

El proyecto soporta muchas plataformas, incluidas Claude Code, Codex, OpenCode, GitHub Copilot CLI, VS Code Copilot Chat, Aider, Cursor, Gemini CLI, Kimi Code, Kiro y Google Antigravity. Cada plataforma puede usar comandos distintos, por ejemplo:

graphify install --platform codex
graphify install --platform gemini
graphify cursor install
graphify antigravity install

Los usuarios de Codex también deben añadir esto bajo [features] en ~/.codex/config.toml:

`1`	`multi_agent = true`

El README también indica que Codex usa $graphify, no /graphify.

Qué archivos puede procesar

Graphify cubre muchos tipos de entrada.

En código, soporta 31 lenguajes, incluidos Python, TypeScript, JavaScript, Go, Rust, Java, C/C++, Ruby, C#, Kotlin, Scala, PHP, Swift, Lua, Zig, PowerShell, SQL, Shell, JSON y más.

En documentación, soporta:

.md
.mdx
.qmd
.html
.txt
.rst
.yaml
.yml

También puede ampliarse con dependencias opcionales:

pip install "graphifyy[pdf]"
pip install "graphifyy[office]"
pip install "graphifyy[video]"
pip install "graphifyy[mcp]"
pip install "graphifyy[neo4j]"
pip install "graphifyy[sql]"
pip install "graphifyy[all]"

pdf sirve para extracción PDF, office para .docx y .xlsx, video para transcripción de video y audio, mcp para MCP stdio server, neo4j para enviar a Neo4j, y sql para extracción de SQL schema.

Qué valor tiene el informe generado

GRAPH_REPORT.md no es un resumen normal. Selecciona relaciones del proyecto que son especialmente útiles para asistentes de IA.

El README menciona contenidos como:

God nodes: los conceptos centrales más conectados del proyecto.
Surprising connections: enlaces inesperados entre archivos o módulos.
The why: razones de diseño extraídas de comentarios, docstrings y documentos de diseño.
Suggested questions: preguntas que el grafo está especialmente preparado para responder.
Confidence tags: cada relación se marca como EXTRACTED, INFERRED o AMBIGUOUS.

Esto es importante. Una búsqueda normal solo dice “dónde aparece esta palabra”. Un grafo puede responder “con qué módulos, configuraciones, tablas y documentos se conecta este concepto”. En codebases grandes, eso se acerca más a entender la arquitectura que una simple búsqueda de texto completo.

Comandos comunes

Comandos comunes de Graphify:

/graphify .
/graphify ./docs --update
/graphify . --cluster-only
/graphify . --no-viz
/graphify . --wiki
graphify export callflow-html
/graphify query "what connects auth to the database?"
/graphify path "UserService" "DatabasePool"
/graphify explain "RateLimiter"

También puedes añadir un paper o video al grafo:

1
2

/graphify add https://arxiv.org/abs/1706.03762
/graphify add <youtube-url>

Para análisis asistido de PR:

graphify prs
graphify prs 42
graphify prs --triage
graphify prs --conflicts

Estos comandos encajan con revisiones de código: ver qué comunidades del grafo afecta un PR, si hay riesgo de conflicto con otros PRs y qué review queue conviene priorizar.

Relación con MCP, Neo4j y CI

Graphify no solo genera un grafo HTML. También puede exponer el grafo a asistentes de IA para uso repetido.

Por ejemplo, puedes iniciar un MCP server:

`1`	`python -m graphify.serve graphify-out/graph.json`

El MCP server ofrece capacidades como query_graph, get_node, get_neighbors, shortest_path, list_prs, get_pr_impact y triage_prs.

También soporta exportación o push a Neo4j:

1
2

/graphify ./raw --neo4j
/graphify ./raw --neo4j-push bolt://localhost:7687

Para trabajo en equipo, el README recomienda poder commitear graphify-out/, de modo que todos empiecen con el mismo mapa del proyecto. También puedes ejecutar:

`1`	`graphify hook install`

Así el grafo se reconstruye automáticamente después de cada git commit y se configura un merge driver para evitar que graph.json quede con marcadores de conflicto cuando varias personas commitean en paralelo.

Privacidad y coste

El README de Graphify explica bastante bien los límites de privacidad.

Los archivos de código se parsean localmente con tree-sitter y no generan llamadas API. Video y audio pueden transcribirse localmente con faster-whisper. Docs, PDFs e imágenes para extracción semántica pasan por la API del modelo usado por tu asistente de IA.

Si usas headless graphify extract, puede que necesites estas variables de entorno:

ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
OPENAI_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY
OLLAMA_BASE_URL

También pueden usarse backends como Ollama local, AWS Bedrock o Claude Code CLI. El README indica además que el proyecto no tiene telemetry, usage tracking ni analytics.

En la práctica, conviene recordar que parsear código localmente no significa que todo se quede offline. Si intervienen docs, PDFs, imágenes o modelos cloud, hay que revisar backend, API keys, cumplimiento empresarial y límites de datos.

Escenarios adecuados

Graphify encaja con varios tipos de usuarios:

Desarrolladores que quieren que Claude Code, Codex, Cursor y Gemini CLI entiendan mejor la estructura del proyecto.
Personas que necesitan comprender rápido un codebase grande y desconocido.
Equipos que quieren analizar juntos código, SQL schema, documentación y configuración.
Personas que hacen revisión de arquitectura, PR review o análisis de impacto de refactors.
Equipos que quieren exponer conocimiento del proyecto como herramienta MCP para Agents.
Líderes técnicos que quieren conservar un “mapa del proyecto” para el equipo.

No es necesario para todos los proyectos. En scripts pequeños, demos puntuales o repositorios muy simples, una búsqueda normal y el README quizá basten. El valor de Graphify aparece con más claridad en proyectos con muchos módulos, mucha documentación, mucha colaboración y uso frecuente de asistentes de IA.

Resumen

Graphify importa porque mueve el contexto de los asistentes de programación con IA desde “leer archivos temporalmente” hacia “un grafo de conocimiento del proyecto consultable y persistente”.

Para desarrolladores, no reemplaza el IDE, la búsqueda o el LSP. Añade una capa de memoria estructurada para asistentes de IA: qué módulos importan, qué conceptos están muy conectados, qué documentos explican decisiones de diseño y qué comunidades puede afectar un PR. A medida que herramientas Agent como Codex, Claude Code, Gemini CLI y Antigravity se vuelvan más comunes, esta capa de grafo del proyecto será cada vez más útil.

Referencias:

GitHub: safishamsi/graphify

Open Design explicado: convertir Claude Code y Codex en herramientas de diseño con IA

Mon, 18 May 2026 18:57:16 +0800

Open Design es un proyecto open source de diseño con IA creado por nexu-io. Se posiciona como una alternativa local-first y abierta a Claude Design y Figma.

El problema que intenta resolver es claro: Claude Design demostró que los modelos grandes pueden generar artefactos de diseño directamente, pero si esta capacidad solo existe dentro de un producto cerrado, en la nube y atado a un único modelo, los usuarios no pueden autohospedar, conectar sus propios agentes, cambiar modelos, crear sistemas de diseño privados ni integrar los resultados en un flujo local.

Open Design no intenta construir un nuevo modelo base. En su lugar, conecta los coding-agent CLI que ya tienes en tu equipo a un espacio de trabajo de diseño. Claude Code, Codex, Cursor Agent, Gemini CLI, OpenCode, Qwen, Copilot CLI, Kimi, DeepSeek TUI y herramientas similares pueden convertirse en su motor de diseño.

Qué es Open Design

Open Design puede entenderse como la combinación de tres partes:

Una Web UI para conversar, previsualizar, gestionar proyectos y exportar.
Un daemon local que coordina agentes, gestiona archivos, guarda proyectos y ofrece APIs.
Un conjunto de Skills, Design Systems y plantillas que guían al agente para generar artefactos de diseño, no páginas genéricas de IA.

Después de que el usuario introduce una petición, Open Design no se limita a enviar una frase al modelo. Primero pide completar el brief de diseño, elegir escenario y dirección, y luego inyecta metadatos del proyecto, el sistema de diseño activo, archivos de Skill, plantillas y checklists en el contexto del agente. El agente lee y escribe archivos en una carpeta real de proyecto y genera un artifact que se previsualiza en un iframe con sandbox.

Eso lo acerca más a un flujo de diseño con IA que a un generador de páginas de un solo disparo.

Por qué no es un generador web de IA común

Muchas herramientas de IA pueden generar una página HTML. El foco de Open Design no es “hacer que el modelo escriba una página”, sino “hacer que el modelo siga un proceso de diseño para entregar artefactos que puedan previsualizarse, exportarse e iterarse”.

Destaca varias decisiones:

Preguntar antes de generar. Un nuevo design brief empieza con un question form interactivo para fijar audiencia, tono, contexto de marca, restricciones y dirección visual.
Skills son archivos, no plugins de caja negra. Cada Skill contiene SKILL.md, assets/ y references/, por lo que puede leerse, reemplazarse y ampliarse.
Design Systems son Markdown, no JSON de tema fijo. Color, tipografía, espaciado, componentes, movimiento, voz de marca y antipatrones pueden escribirse en DESIGN.md.
El agente trabaja en un directorio real de proyecto. Puede leer plantillas, escribir archivos, generar imágenes y producir .pptx, .pdf, .zip y otros archivos.
Los artifacts se previsualizan en un iframe con sandbox, reduciendo el riesgo de ejecutar directamente código no controlado.

El objetivo es que la IA se parezca más a un colaborador de diseño con reglas, materiales y checklists.

Qué agentes soporta

Uno de los puntos fuertes de Open Design es que trata a los agentes como runtime, en lugar de fijarse a un solo proveedor de modelos.

El README lista soporte para Claude Code, Codex CLI, Devin for Terminal, Cursor Agent, Gemini CLI, OpenCode, Qwen Code, Qoder CLI, GitHub Copilot CLI, Hermes, Kimi, Pi, Kiro, Kilo, Mistral Vibe, DeepSeek TUI y otros. Detecta estos CLI desde PATH y permite cambiar entre ellos.

Si no hay un CLI local adecuado, también puede usar un proxy BYOK compatible con OpenAI. El usuario proporciona baseUrl, apiKey y modelo, y el daemon normaliza la salida en streaming al mismo flujo de chat.

Este diseño aporta varios beneficios:

No bloquea al usuario en un único modelo.
Reutiliza agentes ya instalados y configurados por el usuario.
El daemon gestiona lecturas y escrituras locales de archivos, con límites de permisos más claros.
Para empresas y usuarios avanzados, facilita conectar modelos propios y proveedores de API.

Skills y Design Systems son sus activos centrales

Open Design incluye muchas Skills y Design Systems. El README menciona Skills para prototipos web, SaaS landing pages, dashboards, mobile apps, gamified apps, carruseles sociales, posters tipo revista, decks, actualizaciones semanales, informes financieros, HR onboarding, facturas, kanban, OKRs y más.

Design Systems proporciona restricciones visuales de marca al agente. La descripción del repositorio menciona fuentes como Linear, Stripe, Vercel, Airbnb, Tesla, Notion, Apple, Anthropic, Cursor, Supabase, Figma, Xiaohongshu y otras.

La relación es sencilla:

Skill decide qué tipo de artifact se debe entregar.
Design System decide qué estilo de marca debe seguir.

Sin estas dos capas, la IA tiende a generar páginas genéricas que se ven familiares pero carecen de criterio. Con Skills y Design Systems, el modelo tiene límites de tarea, referencias visuales y reglas de revisión más claras.

Qué puede generar

Open Design no se limita a prototipos web.

Según el README, cubre web, desktop, mobile prototypes, slides, images, videos, HyperFrames y más. También soporta exportación a HTML, PDF, PPTX, ZIP y Markdown. La generación multimedia entra en el mismo ciclo de diseño: posters, avatares, infografías, mapas ilustrados, videos cortos y motion graphics HTML a MP4.

Esto amplía los usos posibles:

Equipos startup pueden crear pitch decks rápidamente.
Equipos de producto pueden generar landing pages o prototipos funcionales.
Equipos de operaciones pueden crear páginas de campaña, imágenes sociales y reportes semanales.
Diseñadores pueden usarlo para moodboards, direcciones visuales y primeros layouts.
Desarrolladores pueden convertir requisitos en artifacts frontend ejecutables.

Su valor no es solo generar una página, sino poner múltiples formatos de contenido dentro del mismo workflow de agentes.

Qué significa local-first

Open Design enfatiza local-first. No entrega todo a un backend SaaS remoto, sino que ejecuta un daemon local y un workspace de proyecto local.

La arquitectura descrita en el README se resume así:

Frontend con Next.js, React y TypeScript.
Daemon local con Node, Express, SQLite y SSE.
Proyectos, sesiones, mensajes, tabs y plantillas guardados en SQLite local y .od/projects/<id>/.
Agentes iniciados con child_process.spawn, leyendo y escribiendo en carpetas de artifact del proyecto.
Vista previa mediante iframe con sandbox.
Exportación a HTML, PDF, PPTX, ZIP y Markdown.

Esta estructura encaja con usuarios que quieren mantener los resultados en su máquina, conectar agentes locales, controlar API keys y mantener workspaces privados.

Pero local-first no significa totalmente offline. La generación real depende del agente y modelo utilizados. Si usas una API de modelo en la nube, el contenido irá a ese proveedor. Una descripción más precisa es que Open Design trae workspace, scheduling, archivos y preview al control local, y deja la capa de modelo a elección del usuario.

Relación con Claude Design y Figma

Open Design se describe en el README como una alternativa open source a Claude Design y Figma, pero no es un clon tradicional de Figma.

Figma es una herramienta profesional para edición manual, colaboración y entrega de diseño. Open Design es más agent-native: el usuario guía agentes mediante lenguaje natural, formularios, Skills y sistemas de diseño para producir artifacts ejecutables.

Combina varias ideas:

La experiencia artifact-first de Claude Design.
La conciencia de sistemas de diseño de Figma.
La capacidad de lectura, escritura y ejecución de agentes como Claude Code y Codex.
Gestión local de proyectos y preview en sandbox mediante daemon.

Por eso quizá no reemplace todo el flujo profesional de diseño, pero sí funciona como ruta rápida desde una idea hasta un prototipo previsualizable.

Para quién es

Open Design encaja mejor con:

Desarrolladores que ya usan Claude Code, Codex, Cursor, Gemini CLI y agentes similares.
Usuarios que quieren gestionar outputs de diseño con IA dentro de carpetas locales de proyecto.
Equipos startup que necesitan prototipos web, decks, posters y materiales de marketing rápidamente.
Usuarios avanzados que quieren personalizar Skills, Design Systems y prompt stacks.
Equipos que no quieren quedar atados a un solo modelo o producto cloud.

Encaja peor con:

Usuarios ligeros que solo quieren abrir una web, escribir una frase y descargar una imagen.
Personas que no quieren tocar Node, pnpm, daemons, CLIs ni configuración local.
Flujos Figma profesionales que necesitan colaboración madura, revisión de diseño y edición vectorial.

En resumen, Open Design parece más una herramienta para usuarios de agentes y equipos de diseño técnicos que un SaaS ligero de diseño para todo el mundo.

Aspectos a tener en cuenta

El README marca el proyecto como 0.8.0-preview y señala que aún evoluciona rápidamente. Esa actividad es buena, pero también significa que APIs, directorios de datos, migración de la app desktop, estructura de Skills y flujos de exportación pueden cambiar.

Antes de usarlo en serio:

No lo trates como una plataforma empresarial de diseño plenamente estable.
Prueba el flujo con proyectos de test antes de importar materiales importantes.
Haz backup de .od/ antes de migrar datos y asegúrate de detener el daemon y la app desktop.
Al usar BYOK, cuida API keys, URLs de proxy y riesgos de acceso a redes privadas locales.
Revisa manualmente los diseños generados, especialmente marca, copyright, copy y consistencia visual.

La ventaja del open source es que puede inspeccionarse, modificarse y recibir contribuciones. El costo es aceptar cierta fricción de ingeniería.

Resumen

Lo interesante de Open Design no es solo ser una alternativa open source a Claude Design. Lo importante es cómo organiza Agent CLIs, Skills, Design Systems, daemon local y preview en sandbox dentro de un mismo workflow de diseño.

Mueve la generación de diseño desde un prompt único hacia un proceso más estructurado: preguntar, elegir dirección, cargar un sistema de diseño, leer la Skill, escribir archivos reales, previsualizar el artifact y exportar el resultado.

Si ya usas Claude Code, Codex o Cursor para trabajar con código, Open Design merece atención. Representa una nueva forma de producto: la IA no solo dibuja una imagen, sino que trabaja dentro de un espacio de proyecto local, siguiendo sistemas de diseño y habilidades de tarea, para generar artefactos de diseño que pueden seguir iterándose.

Referencias

Repositorio GitHub nexu-io/open-design

Guía para ahorrar tokens en Claude Code: cómo modelos, MCP, CLAUDE.md y Skills afectan la caché

Mon, 18 May 2026 18:30:24 +0800

En tareas largas con Claude Code, la tasa de aciertos de Prompt Cache afecta directamente el costo y la velocidad. Muchos usuarios saben que la caché puede ahorrar tokens, pero no qué acciones hacen que falle de repente.

La forma más simple de entenderlo es imaginar cada petición como una cadena de contexto de izquierda a derecha:

`1`	`tools -> system -> CLAUDE.md / skills -> messages`

Cuanto más a la izquierda está un contenido, más estable debería ser y mayor es el beneficio de cachearlo. Si cambia una sección de la izquierda, todo lo que va después puede necesitar recalcularse. Si cambia algo a la derecha, el impacto suele ser menor.

Optimizar Prompt Cache en Claude Code no es magia. La regla es simple: antes de iniciar una tarea, prepara modelo, servidores MCP, Skills, CLAUDE.md y el contexto base. Una vez iniciada, cambia lo menos posible esa parte fija.

Prompt Cache no guarda texto plano

Prompt Cache no es solo una caché de cadenas de texto. En la inferencia Transformer, lo importante es el estado Key/Value calculado por las capas de atención a partir del prefijo de contexto, lo que solemos llamar KV cache.

Eso implica dos cosas:

Si el prefijo se mantiene estable, parte del cálculo previo puede reutilizarse.
Si cambian el modelo, las definiciones de herramientas, el prompt del sistema o los mensajes iniciales, las entradas antiguas de caché pueden dejar de coincidir.

La documentación de Anthropic resume la jerarquía de invalidación como tools -> system -> messages. Cambiar definiciones de herramientas puede invalidar toda la caché; cambios en system afectan system y messages; cambios en messages afectan sobre todo la caché de mensajes.

Claude Code añade otras fuentes de contexto como CLAUDE.md, Skills, MCP, plugins y subagents, así que es fácil romper la caché sin querer.

Asesino de caché 1: cambiar de modelo a mitad de tarea

Cambiar de modelo es una de las operaciones más caras.

Prompt Cache está aislada por modelo. Opus, Sonnet y Haiku tienen arquitecturas y pesos distintos, así que el KV cache calculado desde el mismo texto no es intercambiable. Si construyes un contexto largo en Opus y luego cambias a Sonnet, Sonnet no puede reutilizar la caché de Opus.

Esto produce un resultado poco intuitivo: cambiar a un modelo más barato a mitad de tarea puede hacer inútil la caché acumulada. El contexto que podría leerse a precio de cache read quizá tenga que escribirse y calcularse de nuevo.

Un patrón más estable:

Mantén la conversación principal en un solo modelo.
Usa un subagent para tareas laterales que puedan ejecutarse con un modelo más barato.
Deja que el agente lateral busque, explore o resuma, y devuelva un resultado breve a la conversación principal.

Así el prefijo largo de la conversación principal se mantiene estable y la caché acierta con más consistencia.

Asesino de caché 2: añadir MCP o recargar plugins a mitad de tarea

MCP proporciona herramientas a Claude Code. Al añadir un servidor MCP, cambia la lista de herramientas, y las definiciones de herramientas están en el extremo izquierdo de la cadena de contexto.

Desde la perspectiva de Prompt Cache, cuando cambia la lista de herramientas, system y messages pueden necesitar recalcularse. Si usas muchos MCP, las definiciones de herramientas pueden ocupar muchos tokens, y el costo de invalidación se nota.

Un detalle importante: Claude Code suele leer la configuración MCP al iniciar la sesión. Cambiar configuración durante la sesión no siempre afecta de inmediato. Los momentos peligrosos son reiniciar, hacer resume, recargar plugins o reconstruir la lista de herramientas.

Recomendaciones:

Instala los MCP necesarios antes de iniciar una tarea larga.
Evita descubrir a mitad de trabajo que falta una herramienta y recargar.
Reduce los MCP habilitados por defecto cuando sea posible.
No mantengas servidores MCP raramente usados siempre activos.

Las definiciones de herramientas estables son la base de una Prompt Cache estable.

Asesino de caché 3: editar CLAUDE.md durante la sesión

CLAUDE.md es el archivo de memoria de proyecto de Claude Code. Sirve para comandos de build, tests, convenciones de arquitectura, estilo de código y restricciones del proyecto.

Es útil, pero también entra en el contexto. La ayuda de Claude explica que CLAUDE.md se lee al iniciar la sesión y se entrega como mensaje de usuario. También se beneficia de Prompt Cache: la primera petición paga el precio completo de entrada, y las siguientes pueden usar el precio menor de cache read si la caché sigue válida.

El problema es que CLAUDE.md se identifica por contenido. Si cambias el archivo, la caché antigua deja de coincidir.

Por eso conviene no editar CLAUDE.md con frecuencia durante tareas largas. Mejor:

Revisa si CLAUDE.md es suficiente antes de empezar.
Coloca reglas estables en el archivo e instrucciones temporales en la conversación.
No edites la memoria de largo plazo por una necesidad puntual.
Si debes cambiarlo, trata la siguiente fase como una nueva sesión o etapa.

CLAUDE.md debería ser guía estable de proyecto, no un borrador temporal que cambia cada ronda.

Asesino de caché 4: instalar o actualizar Skills a mitad de tarea

Skills también forman parte del contexto. Instalar una Skill nueva, actualizar una Skill o cambiar la lista de Skills cambia lo que se inyecta en la sesión.

Estos cambios suelen aplicarse al recargar, reanudar o abrir una nueva sesión. Cuando messages se reconstruye, las entradas antiguas de caché pueden dejar de servir.

La recomendación es similar a MCP:

Decide qué Skills necesitas antes de empezar.
Mantén estable el conjunto de Skills para tareas similares.
Evita instalar Skills en mitad de una tarea larga.
Si instalas una Skill nueva, trátalo como inicio de una nueva etapa.

Para flujos repetibles como producción de contenido, review, despliegue o traducción, mantener un conjunto fijo de Skills ayuda a estabilizar la estructura del contexto.

Asesino de caché 5: estar inactivo más allá del TTL

Prompt Cache no dura para siempre. Un TTL común está en el orden de minutos, y la documentación relacionada con Claude Code suele hablar de una ventana cercana a cinco minutos. Pasado el TTL, incluso la misma petición puede requerir reconstruir la caché.

Esto explica una sensación común en tareas largas: todo iba rápido y barato, sales por un café, vuelves y el costo de tokens sube otra vez.

Es fácil que ocurra. Lees la salida de Claude Code, inspeccionas archivos, ejecutas tests o piensas el siguiente paso. Cinco minutos pasan rápido.

Si tu entorno lo permite, puedes pedir un TTL de una hora antes de tareas largas:

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

En Windows PowerShell:

`1`	`$env:ENABLE_PROMPT_CACHING_1H="1"`

Las escrituras de caché de una hora suelen costar más que las de cinco minutos. No siempre conviene para tareas cortas, pero en bases de código grandes, conversaciones largas y trabajos complejos de varias etapas, puede ser más barato que sufrir expiraciones repetidas.

Un flujo de Claude Code que ahorra tokens

Un flujo más estable sería:

Elegir el modelo antes de empezar y evitar cambios frecuentes.
Habilitar los MCP necesarios y desactivar los que no usarás.
Mantener CLAUDE.md breve, estable y centrado en reglas duraderas.
Preparar por adelantado las Skills necesarias.
En tareas complejas, considerar TTL de una hora.
Dividir la tarea en fases, pero mantener estable la estructura de contexto dentro de cada fase.
Usar subagents o sesiones separadas para exploraciones laterales, sin alterar la conversación principal.

El objetivo no es eliminar todos los fallos de caché. Es evitar los fallos caros y fáciles de pasar por alto.

Regla rápida

Hazte esta pregunta:

¿Esta operación cambia el modelo, las definiciones de herramientas, el contexto del sistema o los mensajes fijos del inicio de la sesión?

Si la respuesta es sí, probablemente afecte a Prompt Cache. Cuanto más a la izquierda esté en la cadena de contexto, mayor será el impacto.

Operaciones comunes:

Cambiar modelo: alto riesgo, cachés aisladas por modelo.
Añadir MCP o recargar plugins: alto riesgo, cambia la lista de herramientas.
Editar CLAUDE.md: riesgo medio-alto, cambia la memoria del proyecto.
Instalar Skills: riesgo medio-alto, cambia el contexto inyectado.
Continuar una conversación normal: bajo riesgo, principalmente añade messages.
Superar el TTL en inactividad: alto riesgo, la caché del servidor expira.

Resumen

Optimizar Prompt Cache en Claude Code consiste en mantener estable el prefijo de la sesión.

No cambies modelos sin necesidad. No instales MCP y Skills a mitad de trabajo. No uses CLAUDE.md como borrador temporal. En tareas complejas, considera un TTL más largo. Con estas bases estables, el costo en tokens y la velocidad de respuesta se vuelven mucho más predecibles.

La frase práctica es: configura antes de empezar, cambia menos después.

Referencias

Anthropic Founder’s Playbook explicado: cómo Claude ayuda a los equipos startup a moverse más rápido

Mon, 18 May 2026 18:02:58 +0800

Anthropic publicó The Founder’s Playbook en el blog oficial de Claude, dirigido a fundadores. La pregunta central es directa: ¿cómo puede una startup AI-native avanzar más rápido desde una idea hasta producto, lanzamiento y escala?

El playbook no es simplemente una lista de funciones de Claude. Divide el proceso de construir una empresa en cuatro etapas: Idea, MVP, Launch y Scale. El punto no es dejar que la IA reemplace el juicio del fundador, sino entregar primero a Claude tareas repetitivas como investigación de mercado, borradores de texto, andamiaje de código, flujos operativos y materiales de ventas, para que los fundadores dediquen más tiempo a juicio, criterio, decisiones y construcción de confianza.

De qué trata este playbook

Las startups de IA enfrentan cada vez más una carrera de compresión: los ciclos de producto son más cortos, hay más competidores y los usuarios exigen velocidad y calidad al mismo tiempo. Trabajos que antes requerían un equipo de varias personas ahora pueden tener una primera versión generada por IA, y luego ser revisados, corregidos y empujados por el equipo fundador.

El marco de Anthropic es claro: no intentes convertir toda la empresa en “AI-powered” desde el primer día. Primero encuentra un proceso que consuma tiempo, sea repetitivo y tenga baja densidad creativa. Deja que Claude genere un primer borrador, script, resumen de investigación o lista de ejecución. Los fundadores siguen siendo responsables de definir objetivos, calibrar la dirección, juzgar la calidad y conectar los resultados útiles con el negocio real.

Primera etapa: Idea

La etapa Idea no consiste en imaginar un concepto llamativo. Consiste en validar si la idea merece más inversión.

Claude puede ayudar a los fundadores en esta etapa a mapear mercados, resumir dolores de usuarios, comparar posicionamiento de competidores, proponer posibles puntos de entrada y convertir ideas vagas en propuestas de valor más concretas.

Pero lo más importante sigue siendo el juicio humano. La IA puede ayudarte a ver más posibilidades con mayor rapidez, pero no puede asumir la responsabilidad de decidir si un mercado tiene una demanda realmente fuerte. Los fundadores todavía necesitan hablar con usuarios reales, observar si están dispuestos a cambiar sus flujos de trabajo existentes e incluso si están dispuestos a pagar.

Segunda etapa: MVP

La etapa MVP es donde Claude Code puede ser especialmente útil.

Para equipos pequeños, el recurso más escaso no suele ser la idea, sino la velocidad para convertirla en un producto que los usuarios puedan probar. Claude Code puede ayudar a generar andamiaje, escribir scripts, completar componentes, revisar casos límite y producir notas de plan técnico, ayudando al equipo a llegar antes a una versión verificable.

La clave no es pedirle a la IA que escriba un producto perfecto de una sola vez. Es reducir la fricción desde cero hasta la primera versión. Los fundadores e ingenieros aún deben revisar arquitectura, seguridad, manejo de datos y experiencia de usuario, pero no necesitan gastar tanto tiempo en borradores mecánicos.

Tercera etapa: Launch

La etapa Launch pone a prueba narrativa, distribución y velocidad de feedback.

Muchos equipos startup subestiman la complejidad de un lanzamiento: copy del sitio web, demos de producto, correos, contenido para redes sociales, entrevistas con usuarios, guiones de venta, actualizaciones para inversores. Cada pieza debe explicar claramente por qué este producto es necesario ahora.

Claude puede actuar aquí como un colaborador de alta frecuencia: generar variantes de posicionamiento, reescribir introducciones para distintos grupos de usuarios, simular preguntas de usuarios, ordenar el ritmo de lanzamiento y convertir feedback temprano en la siguiente ronda de acciones de producto y mercado.

Cuarta etapa: Scale

La etapa Scale cambia el foco de “construirlo” a “crecer de forma repetible”.

Cuando una empresa empieza a tener usuarios e ingresos estables, el equipo fundador se ve arrastrado por operaciones, ventas, soporte, análisis de datos y coordinación interna. Capacidades tipo agente como Claude Cowork encajan mejor con tareas más completas: hacer investigación de mercado, diseñar campañas, organizar una estrategia de fundraising, resumir métricas de crecimiento o convertir un proceso operativo en pasos repetibles.

Aquí también empieza a verse la diferencia entre empresas AI-native y compañías de software tradicionales. El cambio real no es solo que los empleados usen herramientas de IA. Es que los procesos de la empresa se diseñan desde el inicio alrededor de la colaboración con IA: qué tareas requieren que humanos definan estándares, cuáles debe ejecutar primero la IA, qué resultados deben revisarse y qué flujos pueden convertirse en plantillas reutilizables.

Para qué sirven Claude Code, Claude Cowork y Chat

Según la publicación oficial, Anthropic quiere que los fundadores piensen en Claude en tres tipos de uso.

Claude Code está más orientado a ingeniería. Sirve para escribir código, generar scripts, analizar casos límite, producir especificaciones de componentes y redactar documentación técnica. Ayuda a convertir ideas en algo que pueda ejecutarse.

Claude Cowork se parece más a un agente de trabajo delegable. Encaja con tareas que requieren ejecución continua, como investigación de mercado, diseño de campañas, estrategia de fundraising y análisis operativo. Ayuda a avanzar una primera ronda de una tarea de negocio relativamente completa.

Claude Chat encaja mejor en momentos de juicio del fundador: pensar una estrategia go-to-market, poner a prueba el posicionamiento del producto, comparar prioridades de roadmap y pulir narrativas clave. No es una máquina de ejecución, sino un compañero de pensamiento para iterar rápido.

Qué es realmente útil para los equipos startup

El valor de este playbook no está en decirles a los fundadores que “la IA es importante”. Eso ya no es nuevo.

Su aporte más útil es mover el uso de IA desde llamadas sueltas a herramientas hacia una metodología de construcción de empresa. Cada etapa tiene cuellos de botella distintos, y cada cuello de botella puede dividirse en partes donde la IA puede participar.

En la etapa Idea, la IA amplía el espacio de búsqueda. En MVP, comprime el ciclo de implementación. En Launch, acelera la expresión y los experimentos de distribución. En Scale, ayuda a convertir procesos en flujos repetibles.

Esta lógica es especialmente importante para equipos pequeños. Un equipo pequeño no tiene suficientes personas para cubrir todas las funciones, pero puede usar IA para crear una primera versión de una capacidad, y luego concentrar la energía humana limitada en las partes que más requieren juicio y construcción de relaciones.

Errores que conviene evitar

El primer error es tratar la salida generada por IA como una conclusión. Investigación de mercado, análisis de competidores, personas de usuario y estrategias de crecimiento deben validarse con datos reales y feedback de usuarios.

El segundo error es subestimar el costo de revisión. La IA puede reducir mucho el costo del primer borrador, pero calidad de código, riesgo legal, expresión de marca, promesas comerciales y seguridad siguen requiriendo responsabilidad humana.

El tercer error es automatizar demasiado pronto. Un proceso que todavía no funciona manualmente no debería entregarse a un agent para ejecución automática. Un enfoque más estable es dejar que la IA participe en una parte pequeña del flujo, observar la calidad del resultado y luego ampliar gradualmente el alcance.

Resumen

La señal de The Founder’s Playbook de Anthropic es clara: la ventaja de una startup AI-native no es solo saber usar IA para escribir código. Es incorporar la IA desde el primer día como una capa de colaboración en producto, ingeniería, marketing, ventas y operaciones.

Para los fundadores, el punto de partida más práctico no es construir un gran flujo de trabajo de IA. Es elegir una tarea que consuma demasiado tiempo, se repita demasiado y frene más el avance, y dejar que Claude produzca la primera versión. La competitividad real viene del control humano sobre dirección, calidad y confianza, y de si el equipo puede integrar este patrón de colaboración en el trabajo diario.

Referencias

The founder’s playbook for the age of AI

easy-vibe: un mapa de aprendizaje para principiantes de Vibe Coding

Sat, 16 May 2026 22:44:43 +0800

easy-vibe es un proyecto open source de Datawhale para aprender Vibe Coding. No está dirigido a desarrolladores que ya dominan herramientas de AI Coding, sino a estudiantes, product managers, diseñadores, equipos de operaciones, indie developers y personas con interés técnico que apenas empiezan con Vibe Coding.

El valor del proyecto no está en listar otro grupo de herramientas de IA, sino en convertir “cómo empezar a construir proyectos con IA” en una ruta de aprendizaje más fácil de entender. Para muchos principiantes, lo difícil no es saber que existen Claude Code, Cursor, MCP o los Agents. Lo difícil es saber qué aprender primero, cómo practicar y cuándo pasar a herramientas más avanzadas.

Lo que más necesitan los principiantes es una ruta

Vibe Coding se ha vuelto popular en los últimos años, pero no es especialmente amigable para principiantes.

En apariencia, si sabes describir un requisito, puedes pedir a la IA que escriba código. En la práctica, en cuanto la tarea se vuelve un poco más compleja, aparecen problemas: el requisito no está claro, el modelo modifica el archivo equivocado, la estructura del proyecto no se entiende, los errores no se saben resolver, las dependencias no se instalan, los prompts se vuelven cada vez más confusos y el flujo termina regresando a “copiar código en una caja de chat”.

Por eso aprender Vibe Coding no puede limitarse a “cómo escribir prompts”. Como mínimo debe resolver varias cosas:

Cómo dividir una idea en tareas ejecutables;
Cómo hacer que la IA entienda la estructura del proyecto;
Cómo leer el código generado por el modelo;
Cómo manejar errores e iterar;
Cómo usar la terminal y el entorno local de desarrollo;
Cómo pasar del chat web a herramientas reales de AI Coding.

Ahí está el sentido de easy-vibe: intenta organizar estos temas en una ruta de aprendizaje, en lugar de dejar que los principiantes se pierdan entre herramientas, tutoriales y términos.

No es un tutorial aislado, sino una hoja de ruta

Según la presentación del proyecto, easy-vibe cubre tutoriales básicos, ejercicios interactivos, contenido visual, RAG, herramientas de terminal, herramientas de AI Coding y temas más avanzados como Claude Code, MCP, Skills y Agent Teams.

Esta forma de organizar el contenido es adecuada para principiantes. AI Coding no es una sola habilidad, sino una combinación de capacidades:

Describir requisitos;
Dividir tareas;
Leer proyectos;
Pedir al modelo que modifique código;
Ejecutar y verificar;
Iterar según los errores;
Convertir flujos repetidos en herramientas o skills.

Si solo aprendes una herramienta, es fácil quedar limitado por su interfaz. Cambias de modelo, editor o CLI, y el flujo vuelve a no estar claro. La ventaja de una hoja de ruta es construir primero el método de trabajo y luego poner las herramientas en el lugar adecuado.

Es especialmente útil para no programadores

El mayor atractivo de Vibe Coding es que permite a personas que no son programadoras profesionales crear prototipos.

Un product manager puede convertir una idea de producto en un demo interactivo. Un diseñador puede validar lógica de interacción. Un equipo de operaciones puede crear herramientas internas. Un estudiante puede construir proyectos de clase rápidamente. Un fundador puede validar demanda en etapas tempranas. Estas personas no necesariamente necesitan convertirse en ingenieros full-time en el sentido tradicional, pero sí necesitan un método para “hacer que la IA me ayude a llevar una idea a algo funcional”.

Por eso easy-vibe encaja bien con la comunidad china. Muchos usuarios chinos ya saben que la IA puede escribir código, pero aún faltan materiales sistemáticos para empezar: entorno de desarrollo, prompts, estructura de proyecto, depuración y uso de herramientas Agent. Es mejor cuando todo se explica con claridad en chino y se acompaña con ejercicios graduales.

Para este tipo de usuarios, lo más importante no es aprender un framework complejo desde el primer día, sino completar un ciclo completo: plantear un requisito, generar un proyecto, ejecutarlo, encontrar problemas, seguir modificando y terminar con una versión usable.

La parte avanzada se acerca a flujos reales de desarrollo con IA

Claude Code, MCP, Skills y Agent Teams, que aparecen en easy-vibe, ya no son solo conceptos introductorios.

Claude Code representa los Agents de programación en terminal: el modelo puede entrar en un proyecto local, leer archivos, modificar código y ejecutar comandos. MCP resuelve la conexión con herramientas y fuentes de datos, para que el modelo no se quede encerrado en una caja de chat. Skills permite conservar flujos reutilizables, como generación fija de proyectos, organización de documentos, revisión de tests o procesos de producción de contenido. Agent Teams va un paso más allá y divide tareas entre varios agentes.

Para principiantes, estos temas pueden parecer lejanos, pero vale la pena conocerlos pronto. La dirección de Vibe Coding ya está clara: pasar de “hacer que la IA escriba un fragmento de código” a “hacer que la IA participe en un flujo completo de proyecto”.

Si una ruta de aprendizaje se queda solo en prompts, pronto quedará atrás frente a la evolución de las herramientas. Pero si al principio se lanzan todos los conceptos avanzados a la vez, el principiante no sabrá por dónde empezar. El valor razonable de easy-vibe es colocar esos temas en una ruta de actualización gradual.

Dos errores que conviene evitar

El primer error es creer que Vibe Coding significa que, aunque no sepas código, puedes desentenderte por completo del código.

La IA puede generar muchas cosas, pero el usuario sigue necesitando juzgar si el resultado es correcto. Como mínimo, hay que entender la estructura del proyecto, saber cómo ejecutarlo y ubicar aproximadamente dónde ocurre un error. Aunque no escribas código complejo, necesitas sentido común básico de ingeniería.

El segundo error es creer que cuanto más avanzada sea la herramienta, mejor.

Un principiante no necesariamente necesita Claude Code, MCP o múltiples Agents al inicio. Un orden mejor es crear primero un ciclo de feedback con proyectos simples, y luego introducir poco a poco terminal, control de versiones, tests, llamadas a herramientas y flujos automatizados. Las herramientas deben coincidir con la complejidad de la tarea; si no, se convierten en algo que parece potente pero no se sabe para qué usar.

Cómo usarlo

Si apenas empiezas con Vibe Coding, puedes usar easy-vibe como una lista de aprendizaje.

Empieza con conceptos básicos y ejercicios simples. No hace falta perseguir todas las herramientas. Construye un proyecto pequeño, como una página personal, un dashboard de datos, una herramienta de formularios, un script de automatización o una demo de base de conocimiento. Durante el proceso, observa en qué partes ayuda la IA y en cuáles necesitas confirmar por tu cuenta.

Cuando puedas completar proyectos pequeños de forma estable, empieza con temas más complejos:

Usar herramientas de terminal para trabajar con proyectos locales;
Usar Git para gestionar cada cambio;
Usar RAG para conectar tus propios materiales;
Usar MCP para conectar herramientas externas;
Usar Skills para fijar flujos repetidos;
Usar Agent Teams para dividir tareas complejas.

Aprender Vibe Coding así no es solo aprender a preguntar a la IA. Es aprender a poner la IA dentro de tu propio flujo de trabajo.

Conclusión

easy-vibe puede verse como un mapa de entrada en chino para Vibe Coding. Organiza conceptos, herramientas y ejercicios dispersos de AI Coding en una ruta que ayuda al principiante a pasar de “he oído que la IA puede escribir código” a “puedo construir un proyecto con IA”.

El valor real de Vibe Coding no es saltarse todo aprendizaje, sino bajar la barrera entre idea y prototipo. Aún necesitas entender requisitos, organizar tareas, verificar resultados y controlar riesgos. Pero muchos pasos repetitivos, tediosos y fáciles de bloquear pueden hacerse con ayuda de la IA.

Si quieres una entrada sistemática al AI Coding y no quieres perderte desde el principio entre nombres de herramientas y configuraciones de ingeniería complejas, easy-vibe es un buen punto de partida.

Guía de despliegue local de Claude Code + Ollama: crear un asistente de programación AI gratuito con CC Switch

Fri, 15 May 2026 23:27:50 +0800

Claude Code se ha vuelto un asistente de programación AI muy popular. Su atractivo no está solo en conversar sobre código, sino en leer un proyecto, modificar archivos, ejecutar comandos, instalar dependencias y seguir corrigiendo errores como un Agent operativo.

El problema es el coste. Cuando el proyecto crece, el contexto se alarga y varias rondas de trabajo tipo Agent pueden consumir cuota de API muy rápido. Si solo quieres experimentar, modificar herramientas pequeñas, escribir scripts o trabajar con proyectos privados locales, surge una pregunta natural: ¿se puede mantener la experiencia de Claude Code, pero ejecutar el modelo en local?

La herramienta clave de esta configuración es CC Switch. Permite que Claude Code se conecte al servicio local de Ollama mediante una API compatible con OpenAI, de modo que las solicitudes se reenvían al modelo local en lugar de ir directamente a la API oficial de Claude.

Qué Problema Resuelve Esta Configuración

Puedes entender el flujo completo así:

1
2
3

Claude Code desktop
+ CC Switch API forwarding layer
+ Ollama local model

Claude Code sigue encargándose del flujo de programación y de las operaciones sobre el proyecto. CC Switch gestiona la configuración del proveedor de modelos y la compatibilidad de API. Ollama ejecuta el modelo en la máquina local.

Esto no significa que un modelo local se convierta de pronto en Claude. Su valor real está en poder usar el flujo tipo Agent de Claude Code en escenarios locales, privados, sin conexión o de menor coste.

Preparación Básica

Antes de empezar, prepara estos componentes:

Instala Git.
Instala Ollama.
Descarga un modelo local adecuado para programación.
Instala CC Switch.
Ten Claude Code disponible en tu máquina.

Para el modelo, puedes empezar con opciones orientadas a código, como Qwen Coder, DeepSeek Coder u otros modelos con buen comportamiento en generación de código y llamadas a herramientas. Cuanto más grande sea el modelo, mejores pueden ser los resultados, pero también aumentará la presión sobre la memoria y la GPU.

Si tu equipo tiene memoria limitada, empieza con un modelo más pequeño. Primero confirma que el flujo funciona bien y luego prueba modelos más grandes.

Configuración Clave De CC Switch

Después de iniciar Ollama, su dirección local de API suele ser:

`1`	`http://127.0.0.1:11434/v1`

En CC Switch, elige un tipo de proveedor compatible con OpenAI. Una opción habitual es:

`1`	`OpenAI Chat Completions`

Después apunta el base URL a la dirección local de Ollama.

Para el campo de API key, Ollama local normalmente no necesita una clave real, pero muchas herramientas siguen exigiendo una variable de entorno o un valor de relleno. Puedes usar:

`1`	`ANTHROPIC_API_KEY`

o cualquier otra variable de relleno aceptada por tu configuración local.

Hay un punto de configuración que merece especial atención:

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

Esto mapea los roles de modelo que Claude Code espera hacia el proveedor local. En la práctica, debes vincular haiku, sonnet y opus con los nombres de modelo expuestos por Ollama o CC Switch. Si este mapeo es incorrecto, Claude Code puede fallar al llamar al modelo o volver a una configuración inesperada.

Dónde Destaca Claude Code

La mayor ventaja de Claude Code no es una finalización aislada, sino el flujo completo de desarrollo:

leer y entender la estructura del proyecto;
localizar archivos relacionados con una tarea;
editar código directamente;
ejecutar comandos y pruebas;
observar errores e iterar;
completar tareas de varios pasos en una sola sesión.

Por eso muchas personas quieren conservar Claude Code aunque cambien a un modelo local. Una interfaz de chat normal puede generar fragmentos de código, pero no trabaja de forma natural dentro de un repositorio. Claude Code se parece más a un asistente de desarrollo capaz de actuar.

Qué Papel Cumple Ollama

Ollama se encarga de ejecutar y gestionar los modelos locales. Gestiona la descarga, la carga y la inferencia local.

La ventaja es clara: las solicitudes permanecen en tu máquina, el uso repetido no genera facturas de API y también puedes trabajar cuando la red está limitada. Para código privado, también resulta más aceptable que enviar cada ventana de contexto a un modelo en la nube.

La contrapartida también es clara. Los modelos locales dependen mucho del hardware y de la calidad del modelo. Un modelo pequeño puede manejar ediciones simples, explicaciones y generación de scripts, pero puede sufrir con refactorizaciones grandes entre varios archivos o decisiones de arquitectura delicadas.

Dónde Están Los Límites De La Experiencia

Esta configuración no debe verse como un reemplazo completo de los modelos cloud más potentes de Claude.

Puedes encontrarte con estos problemas:

comprensión más débil de contextos largos;
llamadas a herramientas inestables en tareas complejas;
inferencia lenta en máquinas solo con CPU;
más alucinaciones de rutas de archivo o APIs inexistentes;
planificación menos fiable en varias rondas;
menor tasa de éxito en refactorizaciones de repositorios grandes.

La expectativa más razonable es usarlo como un asistente de desarrollo local gratuito, no como un sustituto perfecto de un modelo cloud de primera línea.

La Compatibilidad Multimodal Sigue Siendo Inestable

Algunos usuarios quieren que Claude Code maneje capturas de pantalla, imágenes de UI, diagramas u otras entradas multimodales. Esta parte depende del modelo local y de la capa de reenvío.

Si el modelo de Ollama seleccionado no admite visión, o si CC Switch no traduce correctamente el formato de solicitud, las funciones multimodales pueden fallar. Incluso con un modelo de visión, el comportamiento puede diferir de la API oficial de Claude.

Por ahora, esta configuración es más adecuada para flujos de texto y código. Conviene tratar el soporte multimodal como algo experimental.

Para Quién Tiene Sentido Probarlo

Esta configuración es adecuada para:

desarrolladores que quieren probar el flujo de Claude Code a bajo coste;
usuarios que escriben scripts, herramientas pequeñas y automatizaciones con frecuencia;
equipos que prefieren mantener el código en máquinas locales;
principiantes que quieren un asistente de programación AI sin gasto continuo de API;
personas que evalúan distintos modelos locales para código.

Es menos adecuada si dependes mucho de contexto largo, monorepos grandes, calidad estricta de revisión de código o refactorizaciones complejas de proyectos completos.

Recomendaciones De Uso

Empieza con tareas pequeñas.

Por ejemplo:

explicar un solo archivo;
refactorizar una función pequeña;
generar un script de shell;
corregir un error simple;
añadir una función pequeña;
escribir pruebas unitarias para un módulo acotado.

Después de cada cambio, ejecuta pruebas o al menos revisa el diff. Un modelo local puede ser útil, pero no conviene aceptar a ciegas todas sus ediciones.

Si el modelo pierde el contexto con frecuencia, reduce el alcance de la tarea. En lugar de pedirle “refactoriza todo el proyecto”, pídele “refactoriza esta función” o “añade validación en este archivo”.

Resumen

Claude Code + CC Switch + Ollama es una combinación interesante. Mantiene el flujo de desarrollo tipo Agent de Claude Code y mueve la inferencia a un modelo local.

Sus mayores ventajas son el menor coste, la privacidad local y un flujo de desarrollo cómodo. Sus límites también son evidentes: la calidad del modelo, el rendimiento del hardware, el contexto largo y la estabilidad de las llamadas a herramientas afectan directamente la experiencia final.

Si ya usas Ollama y quieres un flujo de programación AI local más práctico, vale la pena probar esta configuración. Solo recuerda empezar con tareas pequeñas, verificar cada cambio y tratar el modelo local como un asistente, no como un ingeniero automático.

Superpowers: un framework de skills que devuelve los coding agents al proceso de ingeniería

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers es un framework de skills para coding agents y también una metodología de desarrollo de software. Su objetivo no es crear otro prompt universal, sino hacer que el agente siga un proceso: aclarar objetivos, producir diseño, escribir un plan, implementar con TDD, revisar y cerrar.

Proyecto: https://github.com/obra/superpowers

En el momento de escribir, la API de GitHub muestra más de 190.000 stars, licencia MIT y actividad reciente. El README lo describe como An agentic skills framework & software development methodology that works.

Qué problema resuelve

Muchas herramientas de AI Coding no fallan por no saber escribir código, sino por escribirlo demasiado pronto.

El usuario da una petición vaga, el agente edita archivos y el resultado parece terminado, aunque los límites, tests y arquitectura sigan sin estar claros. En tareas pequeñas puede pasar; en proyectos complejos se convierte en retrabajo y deuda técnica.

Superpowers hace que el agente entre en un workflow antes de tocar código:

Si detecta que el usuario quiere construir algo, pregunta primero por el objetivo.
Convierte la conversación en una especificación y la confirma por partes.
Tras aprobar el diseño, genera un plan de implementación.
Solo cuando el usuario dice “go” empieza a implementar.
Durante la implementación enfatiza TDD, YAGNI, DRY y revisión.

No es ingeniería nueva, pero los agentes rápidos necesitan barandillas más fuertes.

Herramientas soportadas

Superpowers no está ligado a un único agente. El README lista Claude Code, Codex CLI, Codex App, Factory Droid, Gemini CLI, OpenCode, Cursor y GitHub Copilot CLI.

Su papel se parece más a una capa de workflow entre harnesses que a un truco para un modelo concreto.

Workflow base

Primero está brainstorming: antes de implementar, el agente convierte ideas vagas en diseño ejecutable y lo confirma.

Después using-git-worktrees: crea un worktree y una rama aislados, y comprueba que instalación y tests parten de una base limpia.

Luego writing-plans: divide el diseño en tareas pequeñas con rutas, alcance de código y pasos de validación.

En ejecución puede usar subagent-driven-development para delegar o executing-plans para avanzar por lotes. Cada tarea debe poder revisarse y verificarse.

Después llega test-driven-development: RED-GREEN-REFACTOR real. Escribir un test que falla, confirmar el fallo, implementar lo mínimo, confirmar el paso y refactorizar.

requesting-code-review introduce revisión entre tareas, y los hallazgos críticos bloquean el avance.

Finalmente finishing-a-development-branch valida tests y ofrece opciones como merge, PR, conservar o descartar el worktree.

Qué hay en la Skills Library

La parte de testing gira alrededor de test-driven-development.

La parte de debugging incluye systematic-debugging y verification-before-completion: reproducir, minimizar, formular hipótesis, validar y no declarar completado sin verificar.

Las skills de colaboración incluyen:

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

También hay skills meta como writing-skills y using-superpowers.

Juntas dan al agente hábitos de ingeniería: cuándo preguntar, planificar, testear y detenerse para review.

Diferencia frente a un prompt normal

Un prompt normal suele apilar reglas en un system prompt: no cambies de más, piensa primero, prueba, explica, sé breve. Cuantas más reglas, más fácil es que el modelo olvide algunas en tareas complejas.

Superpowers divide las reglas en módulos de workflow activables. Cada skill es más corta y enfocada. El agente sabe en qué fase está, el proceso se vuelve revisable y el equipo puede codificar sus propias prácticas.

La lección no es solo usar un modelo más inteligente, sino darle una forma repetible de trabajar.

Para quién sirve

Superpowers encaja mejor con desarrolladores que ya usan coding agents en proyectos reales: tareas de varios archivos, diseño antes de implementación, TDD o validación, ramas o worktrees paralelos, subagents para implementación o review, y equipos que quieren convertir su flujo en skills reutilizables.

Para cambiar una línea de configuración puede ser pesado. Para trabajos de varias fases, sus restricciones aportan valor.

Precauciones

No es piloto automático. Da proceso al agente, pero requisitos, límites y aceptación final siguen siendo humanos.

TDD y review añaden coste inicial. En tareas pequeñas pueden parecer lentos; en tareas complejas reducen retrabajo.

Los subagents en paralelo no siempre ayudan. Funcionan si los límites y el alcance de escritura son claros. Si el requisito es borroso, el paralelismo multiplica la confusión.

También hay que mantener la calidad de las skills. Procesos obsoletos, instrucciones vagas y reglas conflictivas perjudican al agente.

Resumen

Superpowers vale porque aleja al coding agent de “recibir petición y editar código” y lo devuelve al proceso de ingeniería de software.

Lo que falta en AI Coding no suele ser velocidad de generación, sino aclaración, planificación, verificación, review y cierre. Cuanto más fuerte sea el modelo, menos conviene saltarse esos pasos.

Si usas Codex, Claude Code, Cursor o Gemini CLI en proyectos reales, Superpowers merece una lectura. Aunque no lo instales, su forma de dividir skills sirve como referencia para diseñar tu propio workflow de agentes.

Rechazar el Vibe Coding: el repositorio skills de Matt Pocock añade restricciones de ingeniería a la programación con IA

Fri, 15 May 2026 08:46:23 +0800

Cuanto más rápido escribe código la IA, más rápido puede perder el control un proyecto. La cuestión real no es si un modelo puede generar funciones, sino si entiende el requisito, respeta el lenguaje del equipo y avanza con cambios pequeños dentro de la arquitectura existente.

El repositorio mattpocock/skills de Matt Pocock apunta en la dirección opuesta al vibe coding: no dejar que la IA tome todo el proceso de desarrollo, sino ponerla dentro de restricciones maduras de ingeniería de software.

Proyecto: https://github.com/mattpocock/skills

No se trata de un prompt mágico. Es un conjunto de agent skills que convierten aclaración de requisitos, modelado de dominio, TDD, diagnóstico y revisión arquitectónica en workflows adecuados para herramientas de AI Coding.

Primero resolver la falta de alineación

El fallo más común en AI Coding es creer que el modelo entendió cuando en realidad solo adivinó a partir de una descripción vaga.

grill-me invierte la interacción. Antes de escribir código, el agente actúa como un revisor exigente y pregunta por ramas, límites y decisiones pendientes.

Si pides una página de login, debería preguntar primero:

Cómo funcionará recuperar contraseña.
Si habrá login de terceros.
Qué error mostrar cuando falle el login.
Si bloqueo de cuenta, CAPTCHA o control de riesgo están dentro del alcance.
A dónde redirigir tras el éxito.

Parece más lento, pero reduce retrabajo. Cuanto más barato es generar código, más caro se vuelve no haber aclarado el requisito.

Escribir el lenguaje de dominio en el contexto

Otro problema es el vocabulario genérico. El modelo no conoce los términos internos del equipo, así que los nombres de variables, funciones y documentos empiezan a desviarse.

grill-with-docs pregunta mientras revisa CONTEXT.md, ADRs o documentos de dominio. Los términos y decisiones confirmados pueden volver a esos documentos.

Esto se parece al lenguaje ubicuo de DDD. Si el equipo dice customer en lugar de user, o transaction en lugar de order, la IA debe heredar esa terminología.

El valor del contexto no está en acumular datos, sino en reducir la necesidad de adivinar.

Usar TDD para limitar la velocidad

La IA es peligrosa porque es rápida. Antes, escribir mucho mal código tomaba tiempo; ahora aparecen cientos de líneas en segundos. El problema no es la velocidad, sino la falta de ciclos de feedback.

El skill tdd devuelve el ciclo rojo-verde-refactor:

Escribir un test fallido para un comportamiento.
Implementar lo mínimo para pasarlo.
Refactorizar.
Continuar con el siguiente corte vertical.

La clave es avanzar comportamiento por comportamiento. La IA ejecuta; la persona controla dirección y límites.

Diagnosticar con un ciclo

Ante un bug, muchos agentes adivinan y parchean varias veces hasta empeorar el código.

diagnose exige crear primero un ciclo de feedback:

Reproducir el problema
Minimizar el caso
Formular una hipótesis
Añadir observación o logs
Corregir
Añadir una prueba de regresión

Es un proceso clásico, pero en AI Coding es aún más importante. La IA prueba rápido; el proceso la mantiene cerca de la causa raíz.

Revisar la arquitectura con regularidad

Que una tarea pase no significa que el código esté mejor. Muchas pequeñas modificaciones de IA pueden difuminar límites de módulos, complicar interfaces y hacer más difíciles los tests.

Skills como improve-codebase-architecture hacen que el agente mire el código desde más arriba:

Qué módulos mezclan responsabilidades.
Qué interfaces son demasiado complejas.
Qué rutas son difíciles de probar.
Qué nombres no encajan con el lenguaje de dominio.
Qué duplicaciones conviene consolidar.

No es una gran refactorización automática. Es observación estructurada y dirección de mejora; la decisión sigue siendo humana.

Lo que hay que limitar es la libertad

La idea central es sencilla: programar con IA no consiste en dejar improvisar al modelo, sino en darle objetivos, contexto, tests y condiciones de parada.

Las personas definen el problema, los límites de arquitectura, las decisiones de negocio y los criterios de aceptación. La IA genera código, completa tests, repite cambios y hace refactors locales.

Los fundamentos de ingeniería de software no quedaron obsoletos porque la IA mejoró. Aclarar requisitos, usar lenguaje de dominio, TDD, diagnóstico y revisión de arquitectura es cada vez más importante.

Cada vez más personas podrán escribir código. La diferencia estará en quién puede insertar la IA en un sistema de ingeniería mantenible, verificable y capaz de evolucionar.

Qué es cc-haha: un proyecto que convierte Claude Code en un banco de trabajo de escritorio

Thu, 14 May 2026 22:38:04 +0800

cc-haha es un proyecto construido alrededor de un flujo de trabajo modificado de Claude Code. Su repositorio completo es NanmiCoder/cc-haha. La página del proyecto lo dice de forma directa: está basado en el código fuente de Claude Code filtrado desde el Anthropic npm registry el 2026-03-31, y su forma principal actual es un banco de trabajo de escritorio para Claude Code.

Proyecto: https://github.com/NanmiCoder/cc-haha

Hay dos puntos importantes en esa descripción.

Primero, no es Claude Code oficial de Anthropic. El README también indica que el copyright del código fuente original pertenece a Anthropic y que el proyecto es solo para aprendizaje e investigación.

Segundo, su foco ya no es simplemente “ejecutar un Claude Code CLI local”. Por lo que muestran el README y el release más reciente, cc-haha se parece más a una app de escritorio que reúne sesiones de Claude Code, proyectos, permisos, diffs, Computer Use, acceso remoto y configuración de proveedores de modelos.

Qué problema intenta resolver

Claude Code nació como una herramienta orientada a la terminal. Las sesiones, la ejecución de comandos, las confirmaciones de permisos, las ediciones de archivos y el cambio de contexto ocurren en la terminal. Para quien está cómodo con CLI, eso funciona. Pero en uso prolongado aparecen varias incomodidades:

Varios proyectos y sesiones son difíciles de gestionar a la vez.
Para ver qué archivos modificó la IA, hay que cambiar a Git o al editor.
Las aprobaciones, la ejecución de comandos y los diffs quedan repartidos en varias superficies.
Ver la sesión actual desde un teléfono u otro dispositivo requiere una solución adicional.
Conectar modelos que no sean de Anthropic exige manejar compatibilidad de protocolos.

La dirección de cc-haha es empaquetar todo eso en un banco de trabajo gráfico. No es solo una capa visual para Claude Code; mueve la gestión de sesiones y el control del flujo de desarrollo local a la app de escritorio.

Banco de trabajo de escritorio: de terminal a centro de control

Según el README, la app de escritorio de cc-haha reúne estas capacidades en macOS / Windows:

Banco de trabajo multisesión: pestañas, cambio de proyecto, entrada a terminal e historial de sesiones.
Arranque por branch / Worktree: una nueva sesión puede elegir rama del repositorio y decidir entre el árbol actual o un Worktree aislado.
Panel derecho de cambios de código: ver archivos modificados, líneas añadidas/eliminadas y estado del workspace mientras se chatea.
Visualización de cambios: inspeccionar ediciones de la IA, diffs y proceso de ejecución.
Flujo de permisos y confirmaciones: aprobar comandos peligrosos, tool calls y preguntas de la IA desde el escritorio.
Varios proveedores de modelos: API compatibles con Anthropic, modelos de terceros, WebSearch fallback y configuración local.
Acceso remoto H5: usar un token de un solo uso para entrar a la sesión de escritorio desde un teléfono u otro dispositivo.
Integración con IM: conversar, cambiar proyectos y aprobar permisos desde Telegram, Feishu, WeChat o DingTalk.
Tareas programadas y uso de tokens: crear tareas planificadas y ver tendencias de consumo local de tokens.

Estas funciones lo acercan más a un “banco de trabajo de programación con IA” que a un simple sustituto de la línea de comandos. Intenta poner en un solo lugar las superficies más comunes al programar con IA: chat, cambios de archivos, permisos, proyectos, entrada remota y configuración de modelos.

Instalación y arranque

Para usuarios normales, lo más razonable es descargar el instalador de escritorio desde Releases.

El flujo indicado en el README es:

Ir a GitHub Releases y descargar el instalador de macOS o Windows.
En el primer arranque, configurar proveedor de modelo, API Key y modelo por defecto en los ajustes de escritorio.
Si macOS indica que la app no se puede abrir, seguir la guía de instalación para resolver permisos de Gatekeeper.

La página del release más reciente muestra que v0.2.6 se publicó el 2026-05-13. Esa versión se centra en recuperar de forma segura el acceso móvil H5, mejorar la gestión de sesiones de escritorio, la búsqueda de menciones de archivos y detalles de experiencia de escritorio.

Si quieres arrancar el CLI desde código fuente, el README da estos comandos:

1
2
3

bun install
cp .env.example .env
./bin/claude-haha

Ese camino es más adecuado para quien quiera depurar el CLI inferior, el servidor o desarrollar cambios propios. Para uso normal, la app de escritorio es más directa.

Qué cambió en v0.2.6

El punto principal de v0.2.6 es que el acceso H5/LAN volvió de una apertura temporal a un modelo de activación explícita y emparejamiento por token.

Cambios destacados:

El acceso H5/LAN debe activarse explícitamente en local.
Los enlaces QR llevan un token visible una sola vez.
Las API remotas, proxy y WebSocket ya no quedan expuestos sin protección.
Settings añadió una página independiente de H5 Access.
La barra lateral de escritorio añadió modo de gestión masiva, con selección múltiple y borrado de sesiones.
La búsqueda de menciones de archivos ahora es git-first, respeta reglas ignore y reduce ruido de node_modules y artefactos de build.
Se añadió un tema blanco puro y se corrigieron problemas como URLs largas rompiendo el layout del chat o borradores cruzados entre tabs.

Esto muestra que el proyecto ya no está solo en la fase de “funciona”, sino que empieza a cubrir límites de seguridad y detalles diarios propios de un producto de escritorio.

La parte de H5 merece especial cuidado. El autor avisa en el release que H5 es una entrada de navegador para individuos o equipos confiables, no un sistema público de login multi-tenant. En la práctica, no debería tratarse como un panel SaaS expuesto a internet.

Computer Use: dejar que el Agent opere el escritorio

Otro punto importante de cc-haha es Computer Use.

La documentación del proyecto explica que esta función parte de una versión muy modificada del Computer Use interno del código filtrado de Claude Code. La implementación oficial depende de módulos nativos privados de Anthropic, como @ant/computer-use-swift y @ant/computer-use-input, que no están disponibles públicamente. cc-haha reemplaza la capa inferior por un Python bridge basado en bibliotecas públicas como pyautogui, mss y pyobjc.

Computer Use soporta operaciones como:

Captura de pantalla: screenshot, zoom
Ratón: clic, arrastre, movimiento, scroll y lectura de posición del cursor
Teclado: escribir texto, pulsar teclas, mantener teclas
Aplicaciones: abrir apps, cambiar pantalla
Permisos: solicitar acceso a apps, listar aplicaciones autorizadas
Portapapeles: leer y escribir contenido
Otros: esperar, operaciones por lote

Su flujo es un ciclo de “captura - análisis - acción”:

El modelo recibe la solicitud del usuario.
Llama a screenshot para capturar la pantalla.
El modelo usa visión para identificar botones, campos y coordenadas.
Llama a herramientas de clic, escritura u operación de apps.
Vuelve a capturar pantalla para confirmar el resultado y continúa.

Según la documentación, la plataforma con soporte completo es principalmente macOS, tanto Apple Silicon como Intel. Windows / Linux son teóricamente posibles, pero las partes de gestión de aplicaciones basadas en pyobjc deben reemplazarse por soluciones de cada plataforma, y hoy no están completamente adaptadas.

Los requisitos de ejecución incluyen:

Bun >= 1.1.0
Python >= 3.8
permiso de Accessibility en macOS
permiso de Screen Recording en macOS

Esta función es potente, pero también aumenta el riesgo de permisos. Al dejar que la IA opere apps de escritorio, conviene autorizar solo las aplicaciones realmente necesarias y no dejar contenido sensible abierto en ventanas no relacionadas.

Varios modelos mediante una capa compatible con Anthropic

La comunicación base de cc-haha sigue siendo el protocolo Anthropic Messages API. La documentación recomienda usar LiteLLM como proxy de conversión de protocolo.

La estructura básica es:

`1`	`claude-code-haha ──Anthropic协议──▶ LiteLLM Proxy ──OpenAI协议──▶ 目标模型 API`

Es decir, cc-haha envía solicitudes Anthropic Messages API, LiteLLM las convierte a formatos como OpenAI Chat Completions y las reenvía a OpenAI, DeepSeek, Ollama u otros servicios de modelos.

La instalación de LiteLLM indicada en la documentación es:

`1`	`pip install 'litellm[proxy]'`

Después se pueden configurar OpenAI, DeepSeek, Ollama y otros modelos en litellm_config.yaml. Una vez iniciado el proxy, se configuran estas variables en .env o ~/.claude/settings.json:

ANTHROPIC_AUTH_TOKEN=sk-anything
ANTHROPIC_BASE_URL=http://localhost:4000
ANTHROPIC_MODEL=gpt-4o
ANTHROPIC_DEFAULT_SONNET_MODEL=gpt-4o
ANTHROPIC_DEFAULT_HAIKU_MODEL=gpt-4o
ANTHROPIC_DEFAULT_OPUS_MODEL=gpt-4o
API_TIMEOUT_MS=3000000
DISABLE_TELEMETRY=1
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

Hay varios detalles prácticos:

drop_params: true es importante, porque parámetros de Anthropic como thinking o cache_control no existen en la API de OpenAI.
Extended Thinking es una función propia de Anthropic y no está disponible con modelos de terceros.
Prompt Caching tampoco funciona en la forma nativa de Anthropic.
Los tool calls pasan de Anthropic tool_use a OpenAI function calling, así que algunos tool calls complejos pueden tener problemas de compatibilidad.
Modelos locales pequeños en Ollama pueden no manejar de forma estable este flujo intensivo en herramientas.

Así que conectar varios modelos puede funcionar, pero no significa que todos ofrezcan la misma experiencia. cc-haha sigue exigiendo al modelo buena capacidad de tool use, comprensión de código y contexto largo.

Para quién tiene sentido

cc-haha encaja mejor con:

Usuarios que ya conocen Claude Code y quieren gestión de sesiones en escritorio.
Personas que trabajan con varios repositorios, ramas y sesiones de IA al mismo tiempo.
Quienes quieren ver cambios de archivos, diffs y estado del workspace en un panel lateral.
Usuarios que quieren probar Computer Use y dejar que un Agent opere apps de escritorio.
Personas que quieren conectar OpenAI, DeepSeek, Ollama u otros modelos mediante un protocolo compatible con Anthropic.
Usuarios que necesitan ver sesiones o aprobar permisos desde móvil o IM.

Encaja peor con:

Usuarios que solo quieren la experiencia oficial y estable de Claude Code.
Personas que no aceptan el origen en código filtrado y la incertidumbre de copyright.
Usuarios que no quieren conceder permisos altos del sistema a herramientas locales.
Equipos que necesitan cumplimiento empresarial, auditoría y soporte oficial.
Personas que no están cómodas con API keys, proxies, compatibilidad de modelos y servicios locales.

Riesgos y límites

Este artículo no puede hablar solo de funciones; también debe hablar de riesgos.

El origen de cc-haha hace que no sea una reimplementación comunitaria normal. El README indica claramente que está basado en código fuente filtrado de Claude Code, y que el código original pertenece a Anthropic. Eso crea incertidumbre de copyright, cumplimiento y mantenimiento a largo plazo.

Además, Computer Use, acceso remoto H5, integración IM y aprobación local de permisos son capacidades de alto privilegio. Cuanto más cómodas son, más claros deben ser sus límites:

No abrir H5 access en redes no confiables.
No tratar el token como una credencial pública de login a largo plazo.
No permitir que el Agent opere aplicaciones sensibles no relacionadas.
No integrarlo casualmente en producción o entornos corporativos regulados.
No exponer configuración de proxies de modelos ni API keys en repositorios públicos.

Si el objetivo es estudiar arquitectura de herramientas de programación con IA, flujos de escritorio e implementación de Computer Use, es una referencia útil. Si se quiere usar en un flujo de producción a largo plazo, hay que evaluar primero riesgos legales, de permisos, seguridad y mantenimiento.

Resumen

Lo más interesante de cc-haha no es si puede replicar Claude Code, sino que empuja las herramientas de programación con IA tipo Claude Code hacia una forma de banco de trabajo de escritorio.

Sesiones, proyectos, Worktree, diffs, permisos, acceso remoto, Computer Use, proveedores de modelos, tareas programadas y estadísticas de tokens se reúnen en una sola experiencia de escritorio. Esto muestra que el siguiente paso de las herramientas de programación con IA no es solo tener modelos más fuertes, sino también interfaces de flujo de trabajo más completas.

Pero sus límites también son claros: no es un producto oficial de Anthropic, tiene un origen sensible y sus funciones de alto permiso requieren cuidado. La actitud más razonable es verlo como un proyecto para observar la evolución de las herramientas de programación con IA, no como un reemplazo despreocupado de Claude Code oficial.

Referencias

Repositorio de GitHub: https://github.com/NanmiCoder/cc-haha
Último release: https://github.com/NanmiCoder/cc-haha/releases/tag/v0.2.6
Documentación de Computer Use: https://github.com/NanmiCoder/cc-haha/blob/main/docs/computer-use.md
Documentación de modelos de terceros: https://github.com/NanmiCoder/cc-haha/blob/main/docs/guide/third-party-models.md

Codex /goal vs Claude Code /goal: ejecutar tareas largas hasta terminarlas

Thu, 14 May 2026 22:25:31 +0800

/goal se está convirtiendo en un comando importante dentro de las herramientas de programación con IA.

No se trata de hacer que el modelo escriba unas cuantas líneas más de código. Resuelve un problema más práctico: cuando una tarea tiene condiciones claras de finalización, ¿puede el Agent seguir avanzando hasta cumplirlas, en lugar de detenerse después de cada turno y esperar a que el usuario escriba “continúa”?

Codex CLI ya añadió un /goal experimental en su documentación oficial. Claude Code también publicó su propia documentación de /goal, y lo describe como una capacidad de automatización que puede seguir trabajando durante varios turnos. El nombre es el mismo, pero la orientación del producto no es exactamente igual.

Qué problema resuelve `/goal`

Una conversación normal de programación con IA suele funcionar turno por turno:

El usuario plantea una tarea.
El Agent analiza, modifica código y ejecuta pruebas.
El Agent informa el resultado.
El usuario decide el siguiente paso.

Ese flujo funciona bien para tareas cortas. Pero cuando se trata de migraciones, refactors, correcciones de pruebas o limpieza de un issue backlog, se vuelve fragmentado. El Agent puede avanzar solo un poco y luego detenerse hasta que escribas “continúa”.

La idea de /goal es cambiar la pregunta de “qué hago ahora” a “qué estado final cuenta como terminado”. Por ejemplo:

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

Este tipo de objetivo encaja de forma natural con tareas largas, porque tiene un punto final claro: las pruebas pasan, la compilación funciona, los archivos se han dividido, una cola queda vacía o se cumplen los criterios de aceptación.

`/goal` en Codex: experimental y ligado al hilo actual

La documentación de Codex CLI de OpenAI marca /goal como experimental. No es una capacidad estable activada por defecto; primero hay que habilitar features.goals.

Hay dos formas de hacerlo:

`1`	`/experimental`

O añadir esto a config.toml:

1
2

[features]
goals = true

Una vez habilitado, se puede usar así:

`1`	`/goal Finish the migration and keep tests green`

Los comandos habituales incluyen:

/goal
/goal pause
/goal resume
/goal clear

Según la documentación de OpenAI, Codex adjunta el goal al active thread actual y sigue ese objetivo mientras avanza una tarea más grande.

Aquí hay un detalle importante: el lenguaje oficial sobre Codex /goal es prudente. Enfatiza configurar un objetivo experimental para trabajo de larga duración y adjuntar ese objetivo al hilo actual, pero no describe con el mismo detalle que la documentación de Claude Code un evaluator independiente que revise cada turno y arranque automáticamente el siguiente. Por eso, de momento conviene tratar Codex /goal como un mecanismo experimental para objetivos de tareas largas, no como un modo de ejecución desatendida plenamente estable.

`/goal` en Claude Code: ejecución por varias rondas guiada por condiciones de finalización

La documentación de /goal en Claude Code es más explícita: después de que el usuario define una completion condition, Claude sigue trabajando entre turnos hasta cumplirla.

Ejemplo:

`1`	`/goal all tests in test/auth pass and the lint step is clean`

El mecanismo de Claude Code, a grandes rasgos, es este:

Cuando termina el turno actual, el control no vuelve inmediatamente al usuario.
Un modelo pequeño y rápido revisa si la condición del objetivo ya se cumplió.
Si no se cumplió, Claude empieza automáticamente el siguiente turno.
Si se cumplió, el goal se borra automáticamente y el estado de finalización queda registrado en el transcript.

Esto hace que /goal en Claude Code se parezca más a “continuar automáticamente hasta satisfacer la condición de finalización”. No solo fija un objetivo en la conversación; delega en un paso de evaluación independiente la decisión de si debe continuar.

Claude Code también permite ver el estado directamente:

/goal

El estado muestra la condición del objetivo, el tiempo transcurrido, la cantidad de turnos evaluados, el consumo de tokens y la razón más reciente del evaluator.

Para detenerlo antes de tiempo, se puede usar:

`1`	`/goal clear`

stop, off, reset, none y cancel también funcionan como alias de limpieza. Después de activar un objetivo, si la sesión se interrumpe y más tarde se reanuda con --resume o --continue, un goal activo puede recuperarse. Sin embargo, el tiempo, el número de turnos y la línea base de tokens se recalculan.

La diferencia principal

Codex y Claude Code están empujando la programación con IA desde respuestas de un solo turno hacia la ejecución de tareas largas, pero la posición de /goal no es la misma.

Comparación	Codex CLI `/goal`	Claude Code `/goal`
Estado	experimental	documentado en una página oficial dedicada
Activación	requiere `features.goals`	usable directamente en un workspace confiable
Alcance del objetivo	active thread actual	session actual
Operaciones habituales	set / view / pause / resume / clear	set / view / clear
Evaluación automática	la documentación enfatiza adjuntar y seguir el objetivo	la documentación describe checks del evaluator después de cada turno
Continuación automática	el lenguaje oficial es prudente	empieza el siguiente turno automáticamente si las condiciones no se cumplen
Mejor caso de uso	mantener un objetivo de largo plazo en una tarea de Codex	dejar que Claude Code avance según condiciones de finalización

En resumen, /goal en Codex se parece más a “adjuntar un objetivo experimental de largo plazo al hilo actual”. /goal en Claude Code se parece más a “definir una condición verificable de parada para la sesión actual y dejar que siga trabajando hasta satisfacerla”.

Cómo escribir un buen `/goal`

Uses la herramienta que uses, /goal no es un buen lugar para deseos vagos.

Un mal ejemplo:

`1`	`/goal 把项目优化一下`

Un mejor ejemplo:

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

Un buen objetivo suele incluir tres cosas:

Un estado final claro.
Un método de validación ejecutable.
Límites que deben respetarse.

Si el objetivo es grande, conviene añadir una condición de parada:

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

Esto importa. Cuanto más potente sea /goal, más necesita límites. Si no, el Agent puede modificar demasiados archivos, ejecutarse durante demasiado tiempo, consumir demasiados tokens o seguir adelante con una cuestión que debería haberse detenido para pedir criterio humano.

Cuándo conviene usar `/goal`

Encaja bien con:

Corrección de pruebas: hasta que pasen pruebas específicas.
Migraciones de código: hasta que todos los puntos de llamada estén actualizados y la compilación funcione.
Limpieza por lotes: hasta eliminar una clase de errores de lint o tipos.
Documentación: hasta que todos los módulos especificados tengan explicación.
Gestión de issues: hasta que todos los issues bajo una etiqueta estén tratados o clasificados con claridad.

No encaja bien con:

Requisitos que todavía no están claros.
Tareas que requieren juicio de producto frecuente.
Eliminaciones de alto riesgo, migraciones de datos o cambios de permisos.
Criterios de aceptación puramente subjetivos.
Tareas que cruzan muchos módulos no relacionados.

Una regla práctica: si puedes escribir “qué comando ejecutar, qué resultado esperar y qué archivos no se deben tocar”, es buen candidato para /goal. Si solo puedes escribir “hazlo mejor”, sigue siendo más seguro usar conversación normal, plan mode o revisión humana.

Qué significa esto para las herramientas de programación con IA

/goal apunta a una dirección clara: las herramientas de programación con IA están pasando de asistentes interactivos a unidades de trabajo que pueden ejecutarse de forma continua.

Antes, usar un Agent solía implicar quedarse cerca. Si se atascaba, lo guiabas. Si terminaba las pruebas, le decías que continuara. Si aparecía un error, dabas otra orden. /goal comprime esa interacción en una condición de finalización y deja que el Agent decida qué debe hacer el siguiente turno.

Pero esto también sube el listón para los usuarios. Escribir prompts ya no consiste solo en describir una tarea; también implica definir criterios de aceptación, comandos de validación, límites de modificación y reglas de parada. Dicho de otro modo, el trabajo del usuario pasa de “pedirle que continúe” a “definir qué significa terminado”.

Que Codex y Claude Code hayan llegado a /goal muestra que los Agents de tareas largas ya no pertenecen solo a tareas en segundo plano o colas en la nube. Las herramientas locales de programación en terminal también empiezan a necesitar una capacidad más fuerte de avance autónomo.

Resumen

Codex CLI y Claude Code tienen /goal, pero por ahora no conviene tratarlos como la misma función.

El /goal de Codex sigue siendo experimental, requiere features.goals y encaja mejor como una forma de mantener un objetivo de largo plazo en el hilo actual de Codex. El /goal de Claude Code conecta de forma más explícita las condiciones de finalización con la continuación automática, usando un evaluator independiente para decidir si debe seguir.

Para el desarrollo diario, este tipo de comando funciona mejor en tareas de ingeniería con criterios de aceptación claros. No reemplaza el juicio de producto ni la revisión de código, pero puede reducir mucho el ciclo repetitivo de “continúa”, “ejecútalo otra vez” y “corrige hasta que pasen las pruebas”.

La habilidad importante no es memorizar el comando, sino aprender a escribir tareas como objetivos claros, verificables y detenibles.

Referencias

OpenAI Codex CLI Slash Commands: https://developers.openai.com/codex/cli/slash-commands
Documentación de Claude Code Goal: https://code.claude.com/docs/en/goal

Por qué DeepSeek se volvió la clave para ahorrar en esta ola de herramientas de AI Coding

Mon, 11 May 2026 04:59:00 +0800

En esta ola de herramientas de AI Coding, la competencia parece girar en torno a capacidad del modelo, ecosistema de plugins y automatización con agentes. Pero cuando se usan de verdad, el primer muro que aparece es el coste.

Claude Code, Codex, OpenClaw y Superpowers son herramientas muy útiles, pero comparten una característica: cuando una tarea se vuelve compleja, consumen muchísimos tokens. Tienen que leer el proyecto, crear planes, llamar herramientas, resumir contexto, revisar resultados una y otra vez, e incluso lanzar subtareas. Cuanto más inteligente es el modelo y más automatizado es el workflow, más fácil es que la factura crezca en silencio.

Por eso DeepSeek se volvió importante en esta ronda. No solo porque pueda escribir código, sino porque su contexto largo y su coste de caché atacan justo la parte más cara de las herramientas de AI Coding.

Por qué las herramientas agent consumen tantos tokens

Los asistentes de programación tradicionales en modo chat suelen funcionar con preguntas y respuestas. Preguntas cómo escribir una función y el modelo responde con un fragmento de código. Ese modo también consume tokens, pero sigue siendo relativamente controlable.

Las herramientas agent son distintas. No solo responden preguntas, sino que entran al proyecto como un ingeniero temporal:

escanean directorios y archivos clave;
entienden el requisito y la arquitectura existente;
crean un plan;
modifican archivos;
ejecutan comandos o tests;
siguen corrigiendo según los errores;
resumen al final qué cambió.

Durante este proceso, el modelo lee repetidamente el mismo contexto. Descripciones del proyecto, fragmentos de código, resultados de herramientas, historial de conversación, planes y logs de error vuelven una y otra vez al contexto. Cuando la tarea es un poco compleja, cientos de miles de tokens desaparecen rápido.

Si además instalas plugins más agresivos, el coste se nota todavía más. Algunas extensiones de OpenCode o Claude Code pueden organizar por defecto todo un equipo de agentes. Tú solo querías cambiar una pequeña función, pero la herramienta puede iniciar planificación, revisión, ejecución y retrospectiva. La tarea parece más “inteligente”, pero los tokens suben sin parar.

La ventaja de Superpowers es activarse bajo demanda

Una ventaja de herramientas como Superpowers es que no fuerzan un flujo agent completo en todas las tareas.

Normalmente puedes seguir usando Claude Code, OpenCode o Codex de la forma habitual. Solo cuando llamas explícitamente a una skill, como brainstorming, planificación, ejecución de plan o retrospectiva, entra en un flujo de automatización más pesado.

Esto importa mucho para el coste.

AI Coding no debería usar artillería pesada para todo. Cambiar una línea de configuración, revisar un error o escribir un script pequeño se puede resolver con una conversación normal. Solo refactors complejos, cambios en varios archivos, procesamiento de documentos largos y validación por varias rondas justifican un flujo agent completo.

Cuanto más poderosa es la herramienta, más importante es controlar cuándo se activa. Si no, más automatización solo significa más desperdicio.

La ventaja clave de DeepSeek es una caché barata

Una razón importante por la que DeepSeek encaja con estas herramientas agent es su bajo coste cuando hay cache hit.

Las tareas de AI Coding tienen muchos prefijos repetidos: contexto del proyecto, prompts de sistema, instrucciones de herramientas, contenido de archivos y turnos anteriores aparecen muchas veces en solicitudes posteriores. Si el servicio del modelo soporta prompt cache, esas partes repetidas cuestan mucho menos después de un acierto de caché.

En muchos modelos, un cache hit solo es algo más barato que un miss, quizá alrededor de un tercio del precio original. La ventaja de DeepSeek es que la diferencia después de un hit puede ser mucho mayor. En workflows agent con contexto largo, muchas rondas y lectura repetida del proyecto, esa diferencia se ve directamente en la factura.

Es decir, DeepSeek no tiene por qué dar la mejor respuesta en cada turno. Pero en escenarios con tareas largas, muchas rondas y lectura repetida de contexto, su estructura de costes encaja especialmente bien con AI Coding.

El contexto largo hace más útil a Claude Code

Al conectar Claude Code o herramientas similares a DeepSeek V4, otra ventaja clara es el contexto largo.

Lo que más temen las herramientas de AI Coding es quedarse sin contexto. Cuando el contexto no alcanza, hay que comprimir con frecuencia. Cuando se comprime mucho, se pueden perder detalles ya leídos. El modelo empieza a olvidar la estructura del proyecto, las restricciones o por qué se modificó cierto archivo, y la calidad baja después.

La capacidad de contexto largo de DeepSeek V4 lo hace más adecuado para repositorios de código, procesamiento por lotes de documentos, traducción de subtítulos y limpieza de artículos de sitio. Especialmente al conectarlo a Claude Code u OpenClaw, una buena configuración puede retrasar la compresión de contexto y conservar más detalles del proyecto.

Por eso algunas tareas se sienten “resistentes” con DeepSeek: no necesariamente impresiona en cada paso, pero aguanta llamadas largas, baratas y repetidas.

Cómo repartir trabajo entre V4 Pro y V4 Flash

DeepSeek V4 Pro y V4 Flash no deberían usarse sin distinción.

Para tareas simples, DeepSeek V4 Flash suele ser mejor. Es rápido, barato y normalmente suficiente para:

traducir subtítulos;
ordenar documentos;
generar scripts comunes;
modificar pequeñas zonas de código;
ejecutar tareas ligeras en OpenClaw;
procesar contenido simple de un sitio.

Para tareas complejas, conviene considerar DeepSeek V4 Pro:

refactors de gran escala;
comprensión de código con varios módulos;
razonamiento complejo;
tareas agent de cadena larga;
cambios de código de alto riesgo;
tareas de ingeniería que requieren planificación más fuerte.

Mucha gente quiere conectar siempre el modelo más fuerte, pero eso suele ser poco rentable. La forma práctica de usar herramientas de AI Coding es dividir las tareas por capas: que el modelo barato procese mucho trabajo rutinario, y reservar el modelo caro para los puntos críticos.

MiniMax, Doubao y DeepSeek ocupan posiciones distintas

Entre modelos y planes chinos, MiniMax, Doubao, Kimi y DeepSeek tienen posiciones diferentes.

MiniMax destaca por dar mucho volumen, bajo precio y funciones amplias. Quizá no sea el modelo de programación más inteligente, pero sirve muy bien para traducción, limpieza ligera y procesamiento por lotes. Procesar subtítulos, cambiar formatos o hacer revisión simple son buenos casos para planes tipo MiniMax.

Doubao destaca por un ecosistema de herramientas más completo: imagen, video, búsqueda, TTS, posible STT y embedding pueden conectarse dentro de la misma caja. Se parece más a una caja de herramientas general.

DeepSeek tiene una posición más clara: texto, código, contexto largo y caché barata. No tiene un ecosistema completo de generación de imagen, voz y video, y sus debilidades son evidentes. Pero en AI Coding y workflows agent de texto largo, sus fortalezas son suficientemente fuertes.

No se trata de que uno sustituya a otro. Se trata de dividir la tarea y usar cada herramienta donde encaja.

Ahorrar no es solo elegir un modelo barato

Ahorrar en AI Coding no significa cambiar todas las solicitudes al modelo más barato.

Las formas realmente efectivas son:

No iniciar un agent pesado para tareas simples.
No usar Pro cuando Flash basta.
Aprovechar la caché en tareas largas.
Mantener estable el contexto repetido para no romper cache hits con cambios inútiles.
Dejar que un modelo barato haga borradores y batch processing, y usar un modelo fuerte para revisiones clave.
Decirle claramente al agent que no repita hechos ni resuma el mismo punto una y otra vez.

El último punto es especialmente importante. Las herramientas de AI tienden a ser verbosas, y la verbosidad no es solo un problema de lectura; también es un problema de coste. Incluir en el prompt “describe cada hecho una sola vez y expresa cada opinión una sola vez” puede mejorar tanto la calidad del texto como el consumo de tokens.

Para qué workflows de AI Coding encaja DeepSeek

DeepSeek encaja mejor en:

lectura de repositorios largos;
cambios ligeros en varios archivos;
limpieza de documentos por lotes;
traducción masiva de subtítulos;
limpieza de artículos Hugo;
ejecución de planes agent;
automatización barata con mucho contexto repetido.

No sirve para todo. Si necesitas gusto frontend especialmente fuerte, juicio de producto complejo o creación multimodal, quizá necesites combinarlo con Claude, GPT, Gemini, Doubao u otras herramientas.

Pero cuando la tarea es de texto largo, contexto largo, llamadas repetidas y sensibilidad al coste, DeepSeek se vuelve fácilmente la primera opción.

Resumen

En esta ola de herramientas de AI Coding, el valor de DeepSeek no es solo que un modelo chino pueda escribir código. Su valor real es resolver el dolor más práctico de las herramientas agent: las tareas largas cuestan demasiado.

Herramientas como Claude Code, OpenClaw y Superpowers automatizan cada vez más el proceso de desarrollo, pero detrás de esa automatización hay lecturas masivas de contexto y llamadas en múltiples rondas. Quien consiga bajar ese coste puede convertir AI Coding de algo “agradable de vez en cuando” en algo “usable todos los días”.

El contexto largo de DeepSeek, su bajo coste de caché y el uso por capas de V4 Flash / V4 Pro lo colocan justo en esa posición.

La verdadera clave de ahorro en esta ronda no es dejar de usar buenos modelos. Es combinar bien modelos buenos, modelos baratos, caché y workflows agent. Cuando entiendes esa factura, las herramientas de AI Coding se convierten en productividad real, no en un juguete bonito pero caro.

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

Qué ocurrió en el incidente de facturación HERMES.md de Claude Code

Sat, 02 May 2026 11:19:23 +0800

Claude Code tuvo recientemente un incidente de facturación bastante típico: un usuario solo inició el CLI y no había hecho una petición explícita, pero un archivo local grande HERMES.md fue leído y generó un cargo considerable.

Vale la pena mirarlo porque expone un nuevo riesgo en herramientas de programación con IA. En cuanto una herramienta lee contexto automáticamente, los archivos locales pueden convertirse en coste real de tokens.

Qué ocurrió

El issue público muestra que el usuario tenía un archivo HERMES.md grande en el directorio de trabajo. Cuando Claude Code arrancó, el CLI escaneó y cargó contexto del proyecto. El problema fue que ese archivo se incluyó automáticamente en el contexto y contó como uso de API.

El usuario no pidió explícitamente al modelo procesar ese archivo, pero la facturación ya había ocurrido. La parte más delicada es que esto puede pasar durante inicialización o preparación de contexto, así que los usuarios pueden no darse cuenta de inmediato de que se está generando coste.

Anthropic respondió después en el issue que reembolsaría el cargo anómalo y daría créditos adicionales. Eso confirma que el problema fue reconocido y gestionado, pero también recuerda a los usuarios que el “contexto automático” en un CLI de IA no es gratis.

Por qué HERMES.md lo disparó

HERMES.md en sí no es el punto. Podría ser cualquier archivo grande: logs, documentos exportados, datos de prueba, volcados de base de datos o informes generados.

El problema real es la combinación de tres cosas:

Claude Code lee automáticamente el contexto del proyecto.
El archivo leído puede ser grande.
Los tokens de contexto entran en la ruta de facturación.

Si un archivo es lo bastante grande, incluso ser incluido “de pasada” puede crear un coste notable. Para modelos basados en tokens, una automatización más fuerte necesita límites más claros.

No es un bug ordinario

Un bug normal de CLI puede significar un comando fallido, una salida incorrecta o una función rota. Un bug de facturación es más sensible porque afecta directamente a la factura del usuario.

En herramientas de programación con IA, el límite de facturación puede ser borroso:

Los system prompts consumen tokens.
Las reglas de proyecto consumen tokens.
Los archivos leídos automáticamente consumen tokens.
Los resultados de llamadas de herramientas consumen tokens.
Reintentos, compresión y resúmenes pueden seguir consumiendo tokens.

El usuario puede ver solo “arrancar la herramienta” o “un chat”, mientras en segundo plano ya se enviaron varias solicitudes con mucho contexto.

Cómo pueden reducir el riesgo los usuarios

Si usas Claude Code, Codex, Cline o herramientas similares de programación con IA, empieza con algunos hábitos:

No pongas archivos grandes directamente en la raíz del proyecto.
Añade logs, datos exportados, salidas de build y archivos temporales a reglas de ignore.
Comprueba si la herramienta admite .ignore, exclusión de contexto o allowlists de archivos.
Activa alertas de presupuesto o límites de uso.
Prueba en un directorio pequeño antes de ejecutarla en un repositorio grande.

Si un repositorio debe conservar archivos grandes, dile explícitamente a la herramienta que no los lea. Las reglas de proyecto también pueden decir: no leer proactivamente logs, dumps, datasets, archivos comprimidos ni Markdown grandes.

Qué deberían mejorar los proveedores

Esto no puede depender solo de la cautela del usuario. Las herramientas deberían ofrecer límites duros.

Mejores diseños incluirían:

La inicialización no debería facturar silenciosamente por archivos grandes.
Leer automáticamente archivos muy grandes debería requerir confirmación.
El CLI debería mostrar tokens estimados y rango de coste para la solicitud.
Archivos grandes comunes y directorios generados deberían ignorarse por defecto.
Los picos anómalos de tokens deberían tener umbrales de protección.

Cuanto más se comporten las herramientas de programación con IA como agentes autónomos, más transparentes deben ser sus costes. De lo contrario, los usuarios no pueden juzgar cuánto costará una operación concreta.

Resumen

El incidente de facturación HERMES.md de Claude Code es, en esencia, un conflicto entre contexto automático y facturación por uso.

Para usuarios, la clave es controlar el contexto del proyecto: no exponer archivos grandes a herramientas de IA por defecto, y configurar límites de presupuesto y uso. Para proveedores, la lectura automática de archivos necesita avisos visibles de coste y mecanismos de protección.

Referencias:

Cómo las rebajas de DeepSeek V4 reescriben el modelo de costes de los AI Agents

Fri, 01 May 2026 19:47:47 +0800

DeepSeek V4 no llegó con un lanzamiento especialmente ruidoso. No hubo gran evento ni una historia de benchmarks que aplastara al instante a todos los competidores. Pero unos días después apareció la parte que realmente afecta a la industria: rebajas repetidas de precio.

El punto de este cambio no es que “el modelo se volvió un poco más fuerte”, sino que “el coste de uso fue empujado a otro nivel”. Cuando los precios por token bajan lo suficiente para que una tarea ordinaria de Agent termine por unos pocos centavos o un par de yuanes, la lógica de negocio detrás de muchos Coding Plans y Token Plans necesita reconsiderarse.

El día de lanzamiento no fue explosivo

La primera ola de comentarios sobre DeepSeek V4 no fue especialmente intensa. Mucha gente esperaba un impacto como el de R1: liderazgo general en benchmarks, validación del cómputo doméstico y avances simultáneos en multimodalidad y capacidades de Agent. Tras el lanzamiento real, sin embargo, se pareció más a una actualización sólida.

V4 Pro es sin duda un modelo fuerte, especialmente en programación, matemáticas, contexto largo y agentic coding. Pero no es el tipo de producto que hace que todos los modelos pares parezcan obsoletos de inmediato. Por eso, el día de lanzamiento la discusión se sintió algo incómoda: la gente quería elogiarlo, pero era difícil encontrar un ángulo lo bastante explosivo.

El verdadero punto de inflexión no fue el lanzamiento, sino los ajustes de precio que llegaron después.

Las rebajas sucesivas son la clave

Después de publicarse DeepSeek V4, los precios empezaron a moverse hacia abajo. Según la página oficial de precios de DeepSeek y la información resumida en el artículo fuente, los precios aproximados de aquel momento eran:

DeepSeek V4 Flash: alrededor de 1 yuan por 1 millón de tokens de entrada; alrededor de 0,02 yuan por 1 millón de tokens tras un cache hit;
DeepSeek V4 Pro: alrededor de 3 yuanes por 1 millón de tokens de entrada; alrededor de 0,025 yuan por 1 millón de tokens tras un cache hit;
el precio de entrada con cache hit en toda la familia de modelos cayó a una décima parte del precio de lanzamiento;
V4 Pro estuvo en un periodo de descuento del 75%, extendido hasta el 31 de mayo de 2026 a las 23:59.

Los precios de API en dólares estadounidenses muestran la diferencia con más claridad:

Modelo	Entrada cacheada	Entrada no cacheada	Salida	Contexto
`deepseek-v4-flash`	$0.0028 / 1M tokens	$0.14 / 1M tokens	$0.28 / 1M tokens	1M
`deepseek-v4-pro` precio promocional	$0.003625 / 1M tokens	$0.435 / 1M tokens	$0.87 / 1M tokens	1M
`deepseek-v4-pro` precio regular	$0.0145 / 1M tokens	$1.74 / 1M tokens	$3.48 / 1M tokens	1M

Aquí importan dos detalles.

Primero, los $0.435 / $0.87 de V4 Pro son precio promocional, no el precio regular a largo plazo. En las notas oficiales de DeepSeek, este descuento del 75% fue extendido hasta el 31 de mayo de 2026 a las 15:59 UTC.

Segundo, el precio con cache hit es la variable clave del modelo de costes de Agent. La entrada cacheada de Flash baja hasta $0.0028 / 1M tokens, mientras el precio promocional cacheado de Pro es $0.003625 / 1M tokens. Eso significa que contexto de proyecto repetido, definiciones de herramientas, system prompts y resúmenes históricos ya no necesitan cobrarse al precio completo de entrada.

Lo más importante de esta política de precios es que vuelve “insensible” el coste en tokens de muchas tareas. Antes, los desarrolladores temían que una tarea de Agent consumiera mucho contexto, leyera y escribiera código repetidamente y llamara herramientas con frecuencia. Ahora, mientras la tasa de cache hit sea lo bastante alta, el coste puede empujarse muy abajo.

Comparación de precios con GPT y Claude

Los precios de DeepSeek por sí solos no transmiten toda la brecha. El contraste se vuelve mucho más claro al ponerlos junto a modelos cerrados comunes del mismo periodo.

Modelo	Entrada	Entrada cacheada	Salida	Mejor para
`deepseek-v4-flash`	$0.14 / M	$0.0028 / M	$0.28 / M	Agents de alta frecuencia, programación rutinaria, tareas por lotes
`deepseek-v4-pro` precio promocional	$0.435 / M	$0.003625 / M	$0.87 / M	Programación compleja, planificación, verificación de hechos
`deepseek-v4-pro` precio regular	$1.74 / M	$0.0145 / M	$3.48 / M	Línea base de coste Pro tras la promoción
GPT-5.5	$5 / M	$0.50 / M	$30 / M	Tareas complejas de alta calidad, razonamiento general
GPT-5.4	$2.50 / M	$0.25 / M	$15 / M	Opción intermedia para programación y trabajo profesional
GPT-5.4 mini	$0.75 / M	$0.075 / M	$4.50 / M	Modelo general y de subtareas de menor coste
Claude Opus 4.7	$5 / M	$0.50 / M	$25 / M	Escritura de alta calidad, razonamiento complejo, tareas largas
Claude Sonnet 4.6	$3 / M	$0.30 / M	$15 / M	Programación, Agents, trabajo general
Claude Haiku 4.5	$1 / M	$0.10 / M	$5 / M	Tareas ligeras, resumen, clasificación

El número más llamativo de esta tabla es el precio de salida. Los Agents no solo leen contexto; también generan planes, parches, explicaciones, logs y siguientes acciones. Si hay mucha salida, los $0.87 / M promocionales de DeepSeek V4 Pro son drásticamente más baratos que los $30 / M de GPT-5.5 o los $15 / M de Claude Sonnet 4.6.

Incluso al precio regular de salida de V4 Pro, $3.48 / M, sigue claramente por debajo de GPT-5.4, GPT-5.5 y Claude Sonnet / Opus. Si la tarea puede manejarse con Flash, el precio de salida baja aún más hasta $0.28 / M.

La brecha de entrada cacheada es todavía más extrema. DeepSeek V4 Flash cuesta $0.0028 / M en entrada cacheada, mientras GPT-5.5 y Claude Opus 4.7 cuestan ambos $0.50 / M. No están en el mismo orden de magnitud. Para Agents que leen repetidamente el mismo repositorio de código, esta brecha importa más que en un chat normal.

Por qué las tareas de Agent se ven especialmente afectadas

Los AI Agents son distintos del chat ordinario. El chat normal suele ser un flujo de pregunta y respuesta con contexto de entrada relativamente limitado. Las tareas de Agent leen archivos de proyecto repetidamente, generan planes, llaman herramientas, inspeccionan resultados y vuelven a modificar código.

Estas tareas tienen dos rasgos:

gran consumo de tokens;
mucho contexto repetido.

El segundo punto es crucial. En un proyecto de código, el modelo lee una y otra vez los mismos archivos, estructura de directorios, logs de error y resultados de modificación. Si la plataforma admite cache hits, el coste de entrada repetida cae de forma pronunciada.

El artículo fuente mencionaba una experiencia real: conectar DeepSeek V4 Pro y Flash a una herramienta parecida a Claude Code, pedirle que descargara un repositorio de prompts y lo convirtiera en un sitio local de búsqueda. La tarea se completó con un coste total de poco más de 0,8 yuanes, y Pro alcanzó una tasa de cache hit del 98,7%.

Este ejemplo ilustra un punto práctico: cuanto más se parece una tarea de Agent a “trabajo repetido alrededor del mismo proyecto”, más valiosos se vuelven los cache hits. Si generar un sitio, arreglar un bug o cambiar un frontend cuesta solo unos centavos o unos pocos yuanes, los planes de suscripción pierden atractivo.

Podemos estimar la brecha con una tarea simplificada. Supongamos que una tarea de coding agent incluye:

500.000 tokens de entrada, de los cuales 80% pueden cachearse;
50.000 tokens de salida;
sin llamadas de herramientas, costes de búsqueda ni markup de plataforma, solo coste de tokens del modelo.

Los costes aproximados son:

Modelo	Coste estimado
DeepSeek V4 Flash	alrededor de $0.03
DeepSeek V4 Pro precio promocional	alrededor de $0.09
DeepSeek V4 Pro precio regular	alrededor de $0.36
GPT-5.4 mini	alrededor de $0.30
GPT-5.4	alrededor de $1.01
GPT-5.5	alrededor de $1.75
Claude Sonnet 4.6	alrededor de $1.11
Claude Opus 4.7	alrededor de $1.65

Esta estimación no significa que DeepSeek sea mejor para todas las tareas. Calidad del modelo, estabilidad de tool calls, capacidad de recuperación en contexto largo, estilo de código y fiabilidad factual necesitan evaluación separada. Pero desde el coste, DeepSeek V4 empuja muy abajo el coste marginal de “dejar correr al Agent unas rondas más”. Eso animará a diseñar flujos más largos, autochecks más frecuentes y más soluciones candidatas sin preocuparse por la factura de tokens cada vez.

La diferencia entre Coding Plans y Token Plans

Muchos productos de IA ofrecen ahora dos tipos de planes: Coding Plans y Token Plans.

La diferencia aproximada es:

los Coding Plans suelen estar orientados principalmente a programación;
los Token Plans suelen cubrir más capacidades, como STT, TTS, generación de imágenes, búsqueda, embeddings y RAG;
STT significa speech to text;
TTS significa text to speech;
los Coding Plans a menudo restringen al usuario a escenarios de programación, mientras otras capacidades requieren compras separadas.

Desde el negocio, un Coding Plan se parece más a un buffet. Los usuarios pagan una tarifa fija por adelantado, mientras el proveedor apuesta a que la mayoría no agotará la cuota. Algunos usuarios consumen más, otros menos, y la plataforma todavía puede ganar dinero en promedio.

Pero si los precios pay-as-you-go por token bajan lo suficiente, los usuarios empiezan a calcular: ¿por qué tengo que comprar un plan? Si el coste mensual real es solo unos pocos yuanes o una decena, un plan de 40 o 200 yuanes puede dejar de valer la pena.

Por qué las rebajas desafían el modelo de suscripción

Los planes de suscripción dependen de una premisa: los usuarios sienten que cada uso individual es caro, o no quieren calcular el coste de cada llamada. Cuando los tokens son caros, un plan da tranquilidad. Cuando los tokens son casi insignificantes, pay-as-you-go se vuelve más natural.

La rebaja de DeepSeek V4 revela de hecho el coste subyacente:

las tareas de Agent pueden ser muy baratas;
el contexto largo no es necesariamente demasiado caro de usar;
los cache hits pueden reducir mucho el coste;
los desarrolladores comunes no necesitan necesariamente una suscripción fija;
el punto de entrada del modelo puede desplazarse de una “plataforma de planes” a una “API de bajo coste”.

Esto incomodará a plataformas construidas alrededor de Coding Plans. Si los usuarios ven que las llamadas pay-as-you-go son más baratas y libres, tienen menos razones para quedar atados a la suscripción de una plataforma.

Cómo elegir entre Flash y Pro

Una forma práctica de usar DeepSeek V4 es dividir el trabajo entre Flash y Pro.

Flash es adecuado para tareas frecuentes, ligeras y repetibles:

corregir bugs;
escribir código frontend;
escribir scripts;
comprensión rutinaria de código;
procesar información ordinaria en contexto largo;
ejecutar gran cantidad de subtareas.

Flash es barato, rápido y también admite contexto muy largo. Para agents de programación cotidianos, muchas tareas no necesitan Pro desde el inicio.

Pro es mejor para juicio complejo y trabajo de respaldo:

planificación multi-ronda;
flujos complejos de Agent;
múltiples llamadas de función;
verificación de hechos;
investigación financiera;
producción de contenido que requiere conocimiento y juicio más fuertes;
cambios de código de alto riesgo.

Una configuración razonable es: Flash maneja volumen, Pro maneja fallback. Empieza tareas ordinarias con Flash y cambia a Pro para planificación de largo alcance, juicio complejo, verificación de hechos o colaboración multi-herramienta. Así se controla el coste sin renunciar a calidad de modelo.

Por qué DeepSeek puede poner estos precios

DeepSeek tiene una estructura de negocio distinta a muchas grandes plataformas. No tiene e-commerce, redes sociales, video corto, cloud computing, teléfonos, coches, suites de oficina, sistemas operativos, navegadores ni un gran ecosistema SaaS empresarial.

Eso significa que no necesita encerrar a los usuarios en una plataforma completa. Puede simplemente vender capacidad de modelo de texto: usa modelos de texto baratos aquí y llama cualquier otra capacidad en otro lugar.

Las grandes plataformas suelen pensar distinto. Si compras su Coding Plan o Token Plan, entras en su ecosistema de cloud, búsqueda, generación de imágenes, voz, base de datos y herramientas de desarrollo. El plan no solo vende el modelo; compite por el punto de entrada del usuario.

El enfoque de DeepSeek es más directo: bajar el precio de los modelos de texto e intentar convertirse en el punto de entrada por defecto para Agents. Una vez ocupado ese punto de entrada, muchos desarrolladores y toolchains se adaptarán naturalmente alrededor.

Modelos abiertos y el punto de entrada por defecto

Si DeepSeek V4 mantiene una ruta de modelo abierto, proveedores cloud y plataformas de terceros pueden desplegarlo por su cuenta y ofrecer servicios. Para DeepSeek, eso es distribución y posible desviación a la vez.

Aquí es donde importa una API oficial de bajo precio. Si el precio oficial ya es lo bastante bajo, otras plataformas tendrán difícil ofrecer una ventaja clara aunque puedan desplegar el modelo. Los usuarios tenderán a usar directamente el punto de entrada por defecto, barato y estable.

Esto es especialmente cierto para herramientas de Agent. Las tareas de Agent dependen de contexto largo, caching, llamadas de herramientas y throughput estable. Una vez que un modelo es lo bastante barato en estos escenarios, tiene opción de convertirse en la opción por defecto.

Los Coding Plans aún no son inútiles

Esto no significa que los Coding Plans desaparezcan inmediatamente. Todavía encajan con algunos usuarios.

Si algunos usuarios son realmente intensivos y agotan su cuota todos los días, una suscripción fija puede seguir siendo económica. Igual que un buffet: si nadie pudiera comer suficiente para amortizarlo, nadie lo compraría.

El problema es que la mayoría de usuarios no son tan extremadamente frecuentes. Usuarios de baja frecuencia, desarrolladores ligeros y personas que ocasionalmente escriben scripts o modifican proyectos encajan mejor con pay-as-you-go. Después de que DeepSeek reduzca los costes por uso, el atractivo de los planes se debilita.

El futuro probablemente será una elección por capas:

usuarios intensivos de alta frecuencia seguirán comprando Coding Plans;
usuarios ordinarios se moverán a APIs de bajo coste;
las herramientas de Agent elegirán automáticamente Flash / Pro según la tarea;
los planes de plataforma tendrán que ofrecer más valor no relacionado con el modelo, como workflows, integración IDE, despliegue, gestión de equipos y auditoría de seguridad.

Resumen

DeepSeek V4 no creó su mayor impacto mediante benchmarks. Lo que realmente cambió las expectativas de la industria fue la reducción de precios posterior.

Cuando los tokens de entrada y el precio con cache hit bajan mucho, cambia el coste de usar AI Agents. Contexto largo, análisis de proyectos de código y llamadas multi-ronda de herramientas que antes parecían caras pueden convertirse en costes cotidianos de unos centavos o unos pocos yuanes.

Esto desafía directamente la lógica de negocio de Coding Plans y Token Plans. Si los usuarios pueden pagar por uso, combinar libremente modelos y herramientas, y mantener costes lo bastante bajos, quizá no quieran quedar atados a un plan de plataforma específico.

Lo que DeepSeek V4 toca realmente esta vez no es solo el ranking de capacidades del modelo, sino la estructura de costes de los AI Agents y la batalla por el punto de entrada por defecto.

Referencias:

mattpocock/skills: una colecci贸n pr谩ctica de habilidades para agentes de codificaci贸n con IA

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills es una colección pública de habilidades de agentes de codificación IA de Matt Pocock.

No es una aplicación completa ni un nuevo cliente de chat. Es un conjunto de habilidades funcionales que pueden ser utilizadas por asistentes de codificación IA. La idea es práctica: desglosar problemas comunes de codificación de IA en pequeñas habilidades que un Agent puede llamar en la tarea adecuada, en lugar de depender de un solo prompt enorme cada vez.

Si a menudo utilizas Claude Code, Codex, Cursor o herramientas de codificación IA similares, vale la pena observar este tipo de colección de habilidades. Lo que realmente afecta la experiencia de codificación con IA a menudo no es si el modelo puede escribir código, sino si puede avanzar en la tarea según tu estilo de trabajo preferido.

false

Qué Problema Resuelve

Los asistentes de codificación de IA son potentes, pero pueden cometer errores fácilmente.

Las situaciones comunes incluyen:

Comenzar cambios de código sin entender el requisito
Modificar demasiados archivos a la vez
Producir mucha explicación pero poca acción útil
Intentar cosas a ciegas después de errores
No ejecutar pruebas o verificaciones a tiempo
Ignorar patrones de proyecto existentes
Introducir abstracciones innecesarias para terminar una tarea
Escribir código sin revisar realmente los riesgos después

Estos problemas no siempre son causados por una débil capacidad del modelo. A menudo, el flujo de trabajo no está lo suficientemente restringido.

El valor de mattpocock/skills es que transforma estos modos de fallo comunes en métodos operativos reutilizables, haciendo que el Agent se comporte más como un colaborador de ingeniería experimentado en diferentes escenarios.

false

¿Qué son los Skills

En el contexto de AI Agent, un skill se puede entender como una instrucción de tarea reutilizable, un método de trabajo o un flujo de trabajo profesional.

No tiene por qué ser un código plugin, y no siempre necesita llamar a un servicio externo. En muchos casos, un skill es simplemente un conjunto claro de reglas:

Cuándo usarlo
Qué hacer primero
Qué no hacer
Qué salida se requiere
Cómo juzgar la finalización de la tarea

Esto es algo parecido a una normal prompt template, pero la granularidad está más cerca de una capacidad de tarea.

Las normal prompt templates suelen copiarse y pegarse manualmente por el usuario. Los skills son mejores como parte de una toolbox de agente, lo que permite al Agent elegir el flujo de trabajo correcto para la tarea.

false

Por qué es importante la pequeñez y la componibilidad

El README enfatiza que estas habilidades son pequeñas y componibles.

Esta dirección es importante.

Si una habilidad intenta manejarlo todo, rápidamente se convierte en un nuevo prompt gigante: largo, vago y difícil de mantener. La ventaja de las habilidades pequeñas son los límites claros.

Por ejemplo, una habilidad puede centrarse en:

Planificar primero
Arreglar errores de TypeScript
Ejecutar pruebas y corregir basándose en los resultados
Realizar revisión de código (code review)
Resumir convenciones del proyecto
Mejorar prompts
Eliminar abstracciones innecesarias

Estas habilidades se pueden combinar según la tarea. Una tarea simple puede necesitar solo una habilidad, mientras que una tarea compleja puede encadenar varias.

Esto se acerca más al trabajo de ingeniería real. No utilizas el mismo flujo de trabajo (workflow) para cada problema; eliges las herramientas según la situación.

false

Manteniendo al Ingeniero en Control

Una dirección importante de este repositorio es mantener al ingeniero en control.

La codificación con IA puede derivarse fácilmente en dos extremos.

El primero es completamente manual. La IA solo ayuda a escribir unas pocas líneas de código, mientras que todo el contexto, la planificación y la verificación todavía dependen de ti.

El segundo es completamente automatizado (hands-off). Tú envías una tarea a un Agent, lo dejas cambiar muchas cosas, y luego te enfrentas a un diff que es difícil de revisar.

Las habilidades ayudan a encontrar una posición intermedia más estable.

Permiten que la IA asuma más flujo de trabajo repetitivo, mientras la sigue limitando con reglas:

Entender la tarea antes de actuar
Leer los archivos relevantes antes de editar
Mantener el alcance de la modificación controlado
Informar sobre la incertidumbre
Verificar después de los cambios
No refactorizar código no relacionado solo para demostrar

Esto no debilita a la IA. Hace que las acciones de la IA sean más fáciles de revisar y asumir para los humanos.

false

Problemas de Alineación

El primer tipo de fallo de codificación de IA suele ser un fallo de alineación.

El usuario quiere un cambio muy específico, pero el Agent puede entenderlo como una refactorización más amplia. El usuario solo quiere que se arregle un bug, pero cambia estilos en el proceso. El usuario quiere que se siga la arquitectura existente, pero introduce un patrón nuevo.

Las habilidades pueden ayudar al Agent a hacer varias cosas al comienzo de una tarea:

Restatear el objetivo
Identificar el alcance del impacto
Reconocer los patrones de implementación existentes
Proporcionar un plan
Aclarar lo que no se hará

Este paso es como una autocomprobación del ingeniero antes de comenzar el trabajo.

Si el Agent no puede declarar claramente los límites de la tarea y comienza a escribir código directamente, es fácil que la tarea se desvíe.

false

Problemas del Bucle de Retroalimentación

La IA no debe escribir código únicamente mediante la generación one-shot.

En el desarrollo real, los bucles de retroalimentación son importantes:

Cambiar una pequeña parte
Ejecutar pruebas o type checks
Leer los errores
Corregirlos
Verificar de nuevo

Muchos Agents fallan porque omiten la retroalimentación intermedia. Cambian muchas cosas a la vez y luego resumen por intuición que “it should work”.

Las Skills pueden hacer explícito el bucle de retroalimentación. Por ejemplo, pueden exigir al Agent que:

Ejecute comprobaciones relevantes después de la modificación
Lea los mensajes de error primero si las comprobaciones fallan
Evite cambiar ciegamente archivos no relacionados
Verifique de nuevo después de cada ronda de correcciones
Informe los resultados finales de la verificación

Esto hace que la codificación con IA se parezca más al depurado (debugging) real y menos a la escritura one-shot.

false

Problemas de Control de Arquitectura

AI es bueno generando abstracciones, y también bueno sobregenerando abstracciones.

Para completar un requisito pequeño, puede crear una capa de servicio (service layer), funciones auxiliares (helper functions), objetos de configuración, type wrappers y adaptadores, haciendo que el código sea mucho más complejo que el requisito en sí.

Esto es especialmente peligroso en proyectos grandes. Las abstracciones generadas por AI a menudo parecen profesionales, pero pueden no coincidir con el estilo del proyecto existente y pueden aumentar el costo de mantenimiento.

Las buenas habilidades recuerdan al Agent que:

Preferir patrones existentes
Evitar nuevas abstracciones innecesarias
Evitar la refactorización de áreas no relacionadas
Ajustar el cambio al tamaño de la tarea
Comprender el código antes de diseñar la estructura

Esto reduce la producción que parece ingenierizada pero que en realidad es más difícil de mantener.

false

Por qué son importantes las habilidades de revisión

Escribir código y revisar código son estados diferentes.

Cuando un Agent escribe código, generalmente tiende a demostrar que su implementación funciona. Puede explicar por qué el cambio debería funcionar, pero no siempre busca activamente riesgos.

El propósito de una habilidad de revisión es cambiar el rol del Agent:

Encontrar posibles errores (bugs)
Encontrar regresiones de comportamiento
Encontrar pruebas faltantes
Encontrar casos límite (edge cases)
Encontrar mayor complejidad
Encontrar inconsistencias con las convenciones existentes

Esto es importante para la programación con IA porque la IA genera código rápidamente. Sin revisión, los usuarios pueden sentirse fácilmente abrumados por grandes diffs.

Una buena salida de revisión debe listar los problemas primero, no alabar la implementación primero. Debe ayudar al ingeniero a decidir si el cambio se puede fusionar (merged).

false

Diferencia con los archivos de reglas normales

Muchas herramientas de codificación de IA admiten reglas, instrucciones o memoria.

Estos archivos generalmente registran reglas a largo plazo, como:

Stack tecnológico del proyecto
Convenciones de nomenclatura
Comandos de prueba
Directorios que no deben modificarse
Preferencias de estilo de respuesta

Las habilidades (Skills) se centran más en el flujo de trabajo de la tarea.

Las reglas le dicen al Agent “cómo comportarse a largo plazo”, mientras que las habilidades le dicen al Agent “cómo ejecutar este tipo de tarea”.

Ambos funcionan mejor juntos.

Por ejemplo, las reglas pueden indicar que el proyecto usa pnpm test, mientras que una habilidad de revisión requiere verificar la cobertura de pruebas después de los cambios. Entonces el Agent sabe no solo el comando, sino también cuándo usarlo.

false

Escenarios Adecuados

Los repositorios como mattpocock/skills son adecuados para:

Uso frecuente de AI coding tools
Agents que trabajan en codebases reales
Reducir ediciones de AI fuera de alcance
Hacer que el Agent verifique los resultados de forma más activa
Convertir tus hábitos de ingeniería en skills
Aprender cómo otros diseñan workflows de agentes
Convertir prompts temporales en una colección de skills mantenible

Si solo pides ocasionalmente a AI que escriba una función pequeña, quizás no necesites mantener skills.

Pero si ya tratas a AI como un socio de desarrollo a largo plazo, las skills se vuelven cada vez más importantes. Son como un método de trabajo reutilizable para el Agent.

false

Cómo aprender de este repositorio

Incluso si no utilizas cada habilidad directamente, puedes aprender varias cosas de este repositorio.

Primero, anota los modos de fallo.

No solo te quejes cuando la AI comete un error. Convierte los patrones que a menudo se equivoca en reglas, para que una habilidad pueda evitarlos la próxima vez.

Segundo, mantén las habilidades cortas.

Una habilidad debe resolver un problema claro. Cuanto más corta sea, más fácil será llamarla correctamente y mantenerla.

Tercero, haz que el formato de salida sea claro.

Si quieres que el Agent enumere un plan primero, ejecute después y resuma los resultados de verificación al final, escribe esa estructura claramente. Los requisitos vagos suelen producir resultados vagos.

Cuarto, conserva puntos de traspaso humano.

Una buena habilidad no debe permitir que la AI funcione sola durante demasiado tiempo. Cuando haya incertidumbre, un alcance de impacto expandido, pruebas fallidas o una decisión de producto, debe detenerse y explicar la situación.

false

Notas de uso

Primero, no conviertas todo en habilidades (skills).

Demasiadas habilidades hacen que el sistema sea complejo, y el Agent podría no saber cuál elegir. Empieza con los escenarios más frecuentes y más problemáticos.

Segundo, las habilidades necesitan iteración.

La primera versión de una habilidad puede no ser buena. Observa cómo la IA la ejecuta realmente, luego elimina, añade y reescribe gradualmente.

Tercero, no permitas que las habilidades reemplacen el juicio de la ingeniería.

Las habilidades pueden mejorar el flujo de trabajo, pero no pueden garantizar una implementación correcta. Las pruebas (tests), la revisión, las comprobaciones de compilación (build checks) y el juicio humano siguen siendo importantes.

Cuarto, presta atención a las diferencias entre los Agents.

Claude Code, Codex, Cursor y Copilot soportan las instrucciones, las habilidades y las reglas de manera diferente. La misma idea se puede reutilizar, pero el formato específico debe ajustarse para cada herramienta.

false

Referencia

mattpocock/skills

false

Pensamiento Final

Lo que hace que mattpocock/skills merezca la pena es no un único prompt mágico dentro de él, sino la idea práctica de codificación con IA que demuestra: dividir la experiencia de ingeniería en pequeñas habilidades y luego permitir que el Agent las combine según el escenario.

A medida que la codificación con IA pasa de ser una asistencia ocasional a formar parte del flujo de trabajo diario, las habilidades se convierten en herramientas importantes para limitar a los Agents, mantener a los ingenieros en control y mejorar la calidad de la retroalimentación. false

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

La configuración de entorno en cuatro partes de Claude Code: CLAUDE.md, Rules, Memory y Hooks

Thu, 23 Apr 2026 10:43:40 +0800

Si usas Claude Code durante un tiempo, pronto notas algo: el modelo importa, pero el entorno que le das, los límites que defines y las reglas que configuras importan igual.

Al principio, mucha gente se centra en “cómo escribo este prompt”. Pero cuando empiezas a usar Claude Code en serio, te importa más otra cosa:

¿Sabe quién eres?
¿Sabe cómo trabajas?
¿Sabe qué reglas no puede romper?
¿Sabe qué acciones requieren confirmación primero?
¿Puede recordar esos límites con el tiempo?

Lo que vuelve maduro a Claude Code no es solo la capacidad del modelo. Es que hay un sistema completo para convertir tu estilo de trabajo en estructura persistente. A alto nivel, ese sistema puede dividirse en cuatro capas:

CLAUDE.md
Rules
Memory
Hooks

Este artículo explica las cuatro.

Por qué la configuración de entorno importa más que prompts únicos

Puedes pensar en Claude Code como un asistente que contrataste.

El primer día no le dirías solo “ayúdame a hacer cosas”. Le darías un manual y explicarías:

quién eres
qué estilo de comunicación prefieres
qué acciones siempre requieren confirmación
qué errores ya ocurrieron y no deben repetirse
dónde están los documentos importantes del proyecto

Por eso, a largo plazo, la configuración de entorno suele importar más que un prompt aislado.

Un prompt resuelve “qué hacemos esta vez”. La configuración de entorno resuelve “cómo trabajamos cada vez desde ahora”.

Capa 1: `CLAUDE.md`

Empieza por la pieza básica. CLAUDE.md es esencialmente un archivo de texto.

Puedes escribir instrucciones para Claude, como:

quién eres
en qué trabajas
tus preferencias de comunicación
reglas obligatorias
contexto especial del proyecto actual
dónde están documentos o directorios importantes

Cada vez que Claude Code arranca, este documento se inyecta automáticamente en el contexto, así que el modelo lo leerá.

Suelo pensarlo como un “archivo de entendimiento compartido”, porque eso es: el acuerdo permanente entre tú y el modelo.

Qué poner en `CLAUDE.md`

Lo mejor para CLAUDE.md suele ser:

identidad y contexto de trabajo
preferencias de tono y salida
reglas globales de comportamiento
contexto de proyecto que aparece a menudo
errores comunes y cómo evitarlos

Por ejemplo:

tu zona horaria
si permites que el modelo envíe emails o mensajes directamente
qué acciones son irreversibles
tus hábitos con documentos y archivos
prácticas de seguridad y límites sobre información sensible

Un principio muy importante: mantenerlo conciso

Un principio clave para CLAUDE.md: mantenlo lo más conciso posible.

La razón es simple: se inyecta en contexto cada vez.

Si crece demasiado, ocupa demasiado espacio de contexto y diluye la información importante. El modelo no lo ignora, pero su atención se dispersa, así que es más probable que pase por alto reglas críticas.

La recomendación oficial suele ser mantenerlo por debajo de 400 líneas.

Mi hábito es aún más conservador: intento mantenerlo por debajo de 200 líneas.

Alcances comunes de `CLAUDE.md`

En la práctica, CLAUDE.md puede existir en distintos niveles, y esos niveles determinan su alcance.

1. Nivel de usuario

Es el nivel global.

Vive en tu entorno de máquina y aplica a todos los proyectos locales.

Es buen lugar para:

información de identidad
preferencias generales de comunicación
hábitos que aplican a todos los proyectos
reglas globales de seguridad

2. Nivel de proyecto

Es el nivel del proyecto.

Está dentro de un directorio de proyecto concreto y solo aplica a ese proyecto.

Es buen lugar para:

contexto específico del proyecto
reglas que solo tienen sentido ahí
explicación de la estructura de directorios
entradas a documentos clave del proyecto

Cómo decidir qué nivel usar

La regla es simple:

Si lo escrito seguiría siendo verdad en otro proyecto, ponlo en el user level.

Si deja de ser verdad al cambiar de proyecto, ponlo en el project level.

Cómo escribir la primera versión

Hay dos formas comunes de empezar:

1. Usar `/init`

Puedes ejecutar /init directamente en la terminal y dejar que Claude escanee el proyecto para generar un CLAUDE.md básico.

2. Dejar que Claude te ayude a organizarlo

También puedes pedirle que busque cómo otras personas estructuran CLAUDE.md, que te haga preguntas según tu situación y organice una versión que encaje contigo.

Un hábito práctico

Al colaborar con Claude, cuando notes algo que debe recordarse o que no debe fallar otra vez, puedes pedirle que lo escriba en CLAUDE.md.

Antes de hacerlo, decide:

¿es una regla global?
¿o solo del proyecto actual?

No lo metas todo en un único archivo.

Capa 2: `Rules`

La siguiente capa es Rules.

La diferencia principal con CLAUDE.md no es el formato, sino cómo se carga.

CLAUDE.md se lee sin importar qué haces.

La ventaja de Rules es que pueden cargarse condicionalmente.

Una regla puede cargarse solo para ciertas rutas, archivos, herramientas o escenarios.

Por qué importa la carga condicional

Porque el espacio de contexto siempre es escaso.

Si todas las reglas entran al contexto todo el tiempo:

el modelo carga más overhead
las reglas realmente importantes se entierran

El valor de cargar reglas bajo demanda es que el modelo ve la información correcta en el momento correcto.

Cuándo mover reglas desde `CLAUDE.md` a `Rules`

Suelen darse dos situaciones:

1. `CLAUDE.md` se volvió demasiado largo

Si empieza a pasar de 200 líneas, sigue creciendo y lo importante se diluye, toca separar reglas.

2. Algunas reglas solo aplican a rutas concretas

Si sabes que ciertas reglas solo tienen sentido para ciertos archivos, por ejemplo:

reglas solo para scripts Python
reglas solo para un directorio de hooks
reglas solo para un subproyecto

entonces pertenecen más naturalmente a Rules.

Dónde encajan mejor `Rules`

El caso típico es “situación específica, ruta específica, tipo de archivo específico”.

Por ejemplo:

convenciones al manejar hooks
reglas de código para cierto tipo de scripts
formas de trabajo que solo aplican bajo un directorio

Mantener ese contenido en CLAUDE.md suele no ser rentable.

Capa 3: `Memory`

La tercera capa es Memory.

Como CLAUDE.md y Rules, también entra al contexto del modelo, pero su diferencia central es:

CLAUDE.md es algo que defines deliberadamente.

Memory se parece más a notas que Claude escribe para sí mismo durante la colaboración.

Qué entra en `Memory`

Cuando Claude juzga que algo vale la pena recordar o conservar por un tiempo, escribe esa información en Memory.

Ejemplos comunes:

una forma de trabajar que corregiste
una preferencia nueva
estado temporal del proyecto actual
algo que no terminaste hoy y debes continuar mañana
con quién colaboraste recientemente
contexto personal aparecido hace poco

Es conocimiento dinámico más que política de largo plazo.

Diferencia con las dos primeras capas

Una distinción simple:

CLAUDE.md / Rules: reglas explícitas, de largo plazo y tipo política
Memory: contexto temporal, dinámico y recién aprendido

Si algo solo importa unos días o cambia con frecuencia, suele pertenecer a Memory, no a una regla permanente.

`Memory` también puede escribirse manualmente

Aunque Memory puede mantenerse automáticamente, también puedes decirle explícitamente:

recuerda lo que debo hacer mañana
recuerda a quién debo hacer seguimiento
recuerda el hito clave de este proyecto este mes

También puedes usar /memory para ver, editar o borrar memorias.

Capa 4: `Hooks`

La última y más avanzada capa es Hooks.

Todo lo anterior, incluido CLAUDE.md, Rules y Memory, sigue siendo guía en lenguaje natural.

Escribes reglas y el modelo normalmente las sigue, pero primero debe interpretarlas.

Mientras la regla viva en lenguaje natural, quedan problemas:

el modelo puede pasarla por alto
demasiadas reglas diluyen atención
puede decidir que no es suficientemente importante

Qué son realmente `Hooks`

Hooks ya no son instrucciones en lenguaje natural. Son scripts.

Son lógica de enforcement a nivel programa, disparada por eventos.

Cuando ocurre cierto evento, esa lógica corre. No se salta porque el modelo la ignore.

Ese es su valor:

convierten “debería seguir esto” en “debe ejecutarse esto”.

Cuándo subir algo a `Hooks`

Si una regla ya está escrita en CLAUDE.md o Rules, pero Claude todavía falla ocasionalmente, y el coste de fallar es real, probablemente debería ser un Hook.

En simple:

comportamiento de bajo riesgo: reglas
comportamiento de alto riesgo: Hooks

Escenarios típicos

Ejemplos obvios:

exigir confirmación antes de enviar un email
exigir confirmación antes de enviar mensajes Slack, Outlook o Gmail
interceptar borrados peligrosos de archivos
bloquear fugas de contraseñas o API keys

Si solo están escritas como reglas, el modelo puede equivocarse algún día. Si son Hooks, el evento se intercepta cada vez.

Puntos de disparo comunes

Hooks pueden engancharse en distintas etapas:

inyectar recordatorios al inicio de una conversación
revisar condiciones antes de ejecutar una herramienta
validar resultados después de ejecutar una herramienta

No necesitas conocer toda la terminología formal. A menudo basta con describir claramente el requisito y preguntar a Claude si debería convertirse en hook.

También puedes usar /hook para inspeccionar hooks configurados.

Una forma práctica de empezar

Recomiendo este orden:

Paso 1: usa `/init` para generar un `CLAUDE.md` básico

No intentes escribir un enorme documento completo desde el inicio.

Deja que Claude escanee el proyecto y genere un punto de partida, luego itera.

Paso 2: añade cosas mientras trabajas

Cuando notes:

esto debe recordarse
este error no debe repetirse
esta preferencia aplicará siempre

pide a Claude que lo añada a CLAUDE.md.

Paso 3: mueve cosas a `Rules` cuando `CLAUDE.md` crezca

Cuando CLAUDE.md se alarga y el modelo no sigue todo con fiabilidad:

¿qué reglas son globales?
¿cuáles solo aplican a ciertas rutas?

Mueve las segundas a Rules para carga condicional.

Paso 4: convierte reglas de alto riesgo en `Hooks`

Si una regla sigue fallando y el coste de fallar es alto, no te quedes en lenguaje natural. Conviértela en Hooks.

Ahí el “recordatorio” se vuelve “enforcement”.

Paso 5: deja que `Memory` maneje estado temporal

Para cosas que expiran, cambian a menudo o no son política permanente, no lo metas todo en CLAUDE.md.

Es más limpio dejar que Memory guarde:

progreso actual del proyecto
colaboradores recientes
preferencias recién añadidas
planes y to-dos de corto plazo

Qué debería guardar cada capa

Modelo mental rápido:

CLAUDE.md: entendimiento compartido de largo plazo, instrucciones globales, contexto base del proyecto
Rules: reglas especializadas cargadas por ruta o escenario
Memory: conocimiento dinámico, estado temporal, cosas aprendidas recientemente
Hooks: enforcement programático para acciones de alto riesgo

Cierre

Mucha gente trata Claude Code como “una interfaz de chat que escribe código”. Pero al usarlo a fondo, se siente más como una estación de trabajo inteligente de largo plazo.

La clave no es solo cómo formulas cada instrucción. Es si le diste un entorno estable, claro y acumulativo.

Cuando construyes estas cuatro capas:

CLAUDE.md
Rules
Memory
Hooks

la calidad de colaboración suele mejorar mucho.

Porque ya no reexplicas desde cero quién eres, cómo trabajas y qué no debe pasar en cada sesión. Convertiste esas cosas en parte del entorno.

Ese es el paso clave para convertir un modelo fuerte en una herramienta madura.

Colaboración multi-agente en Claude Code: cómo elegir entre Subagents y Agent Teams

Wed, 22 Apr 2026 21:35:52 +0800

Cuando se habla de colaboración multi-agente en Claude Code, los dos conceptos más fáciles de mezclar son Subagents y Agent Teams. Ambos suenan como “levantar varios agentes para trabajar juntos”, pero están pensados para tipos de trabajo distintos. En corto: los primeros son mejores para separar tareas independientes, mientras los segundos encajan mejor cuando varios agentes necesitan colaborar alrededor del mismo problema y revisar sus conclusiones con el tiempo.

Si ya has usado Skills, este marco también ayuda:

Una Skill define el flujo y las reglas
Un Subagent o compañero de Agent Team ejecuta el trabajo real

Así que la pregunta real no es cuál es más avanzado, sino qué problema de colaboración estás resolviendo.

Subagents: separar tareas laterales

Subagents se parecen más a copias temporales de trabajador lanzadas desde la sesión actual. Cada uno tiene su propia ventana de contexto y, al terminar, devuelve solo un resumen del resultado. La conversación principal se mantiene más limpia porque no absorbe todos los logs y salidas intermedias.

Eso da a Subagents varias fortalezas prácticas:

El hilo principal se mantiene limpio en lugar de llenarse de logs de tests, resultados de búsqueda o salida larga
Tareas independientes de investigación o ejecución pueden correr en paralelo
Funcionan bien cuando basta con “tráeme el resultado”

El artículo original señala que Claude Code trae tres tipos integrados de Subagents:

Explore: solo lectura, útil para buscar rápidamente en una codebase
Plan: solo lectura, útil para reunir información en segundo plano durante plan mode
General-purpose: puede leer y escribir, adecuado para tareas que mezclan exploración y edición

Subagents personalizados

Si las opciones integradas no bastan, puedes definir tu propio Subagent. El mecanismo es simple: escribir un archivo Markdown en una de estas ubicaciones:

.claude/agents/: activo solo en el proyecto actual
~/.claude/agents/: activo en todos tus proyectos

El formato se ve así:

---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---
You are a senior code reviewer ensuring high standards of code quality and security.

When invoked:

1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately

Review checklist:

- Code is clear and readable
- Functions and variables are well-named
- No duplicated code
- Proper error handling
- No exposed secrets or API keys
- Input validation implemented
- Good test coverage
- Performance considerations addressed
Provide feedback organized by priority:

- Critical issues (must fix)
- Warnings (should fix)
- Suggestions (consider improving)

Include specific examples of how to fix issues.

El campo clave es description. Claude lo usa para decidir cuándo debe llamarse ese Subagent, así que cuanto más precisa sea la descripción, más fiable suele ser el disparo.

También conviene conocer algunos campos comunes:

tools: limita qué herramientas puede usar el Subagent
model: elige entre sonnet, opus, haiku o inherit
permissionMode: controla permisos de edición y prompts de autorización
memory: da al Subagent un directorio de memoria entre conversaciones

Si solo necesitas un Subagent temporal, también puedes definirlo mediante CLI:

claude --agents '{
  "code-reviewer": {
    "description": "Expert code reviewer. Use proactively after code changes.",
    "prompt": "You are a senior code reviewer. Focus on code quality, security, and best practices.",
    "tools": ["Read", "Grep", "Glob", "Bash"],
    "model": "sonnet"
  }
}'

Cuándo encajan mejor los Subagents

Subagents suelen encajar mejor en tareas como:

Ejecutar tests y devolver solo el resumen de fallos en lugar de llenar el hilo principal con miles de líneas de logs
Investigar varios módulos no relacionados en paralelo
Dividir “encontrar el problema” y “corregir el problema” en una pipeline simple

Por ejemplo:

`1`	`Research the authentication, database, and API modules in parallel using separate subagents`

`1`	`Use the code-reviewer subagent to find performance issues, then use the optimizer subagent to fix them`

Pero si una tarea necesita ajustes constantes de ida y vuelta, comparte mucho contexto entre etapas o concentra cambios en uno o dos archivos, manejarla directamente en la conversación principal suele ser más simple que levantar un Subagent.

Agent Teams: múltiples sesiones independientes trabajando juntas

Agent Teams operan en otro nivel. En vez de lanzar copias de trabajadores dentro de una sesión, inician varias instancias independientes de Claude Code que colaboran alrededor de una lista de tareas compartida y también pueden enviarse mensajes directamente.

Eso hace que un Agent Team se sienta más como un pequeño equipo real que como un simple sistema de tareas laterales.

El artículo señala que actualmente es una función experimental y debe activarse primero:

{
    "env": {
        "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
    }
}

Una vez añadido a settings.json, puedes pedir a Claude que organice un equipo alrededor de un objetivo. Por ejemplo:

1
2
3

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

De qué se compone un Agent Team

Un Agent Team incluye principalmente tres partes:

Team lead: la sesión principal que usas, responsable de organizar, asignar y resumir
Teammates: varias instancias independientes de Claude Code
Task list y Mailbox: lista compartida de tareas y canal de comunicación

La mayor diferencia con Subagents es que los teammates pueden comunicarse directamente entre sí en lugar de pasar todo por el lead. Las tareas suelen moverse por estados como pending, in progress y completed; cuando un teammate termina una tarea, puede tomar la siguiente.

Cuándo encajan mejor los Agent Teams

Cuando una tarea necesita varias perspectivas, discusión activa, hipótesis en conflicto o trabajo paralelo en módulos, Agent Teams encajan mejor.

El artículo da varios ejemplos representativos:

Varios revisores inspeccionan el mismo PR en paralelo, cada uno centrado en una dimensión
Varios agentes investigan el mismo bug con explicaciones competidoras y desafían las conclusiones de los otros
Frontend, backend y testing avanzan en paralelo en distintas partes del proyecto

Por ejemplo, revisión de código en paralelo:

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

Y depuración estilo debate:

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

El patrón común es que no quieres una sola respuesta. Quieres varios agentes intercambiando juicios, desafiando supuestos y convergiendo gradualmente en una conclusión más sólida.

Cómo elegir entre ellos

Si quieres una regla rápida:

Si solo necesitas el resultado, usa Subagents
Si el trabajo requiere discusión y validación cruzada, usa Agent Teams

Ampliando un poco:

Estilo de comunicación: Subagents principalmente reportan resultados a la sesión principal; miembros de Agent Teams pueden hablar directamente entre sí
Modelo de coordinación: Subagents dependen más de la conversación principal para orquestación; Agent Teams trabajan desde una lista de tareas compartida que los miembros pueden reclamar
Coste de tokens: Subagents son más baratos; Agent Teams cuestan más porque cada teammate es una instancia independiente
Mejor ajuste: Subagents para trabajo independiente y orientado a resultados; Agent Teams para trabajo con mucha discusión y revisión cruzada

Precauciones prácticas

Agent Teams son más potentes, pero eso no significa que cada tarea merezca un equipo completo. El artículo destaca varias preocupaciones prácticas:

el uso de tokens sube de forma notable
si varios teammates editan el mismo archivo a la vez, los conflictos de sobrescritura son muy probables
añadir demasiados teammates aumenta el coste de coordinación sin garantizar mejores resultados

Un valor predeterminado más seguro suele ser:

empezar con 3 a 5 teammates
dividir tareas por módulo o archivo para evitar conflictos de edición
si el lead empieza a hacer el trabajo de los teammates demasiado pronto, pedirle explícitamente que espere primero a los demás

La versión experimental actual también tiene limitaciones:

sin soporte de /resume y /rewind para teammates en proceso
el estado de tareas puede retrasarse y a veces necesita corrección manual
un lead solo puede gestionar un equipo a la vez
los teammates no pueden crear child teams propios

Conclusión breve

Estas dos funciones no se sustituyen entre sí. Resuelven dos problemas de colaboración distintos.

Si tu objetivo es paralelizar tareas laterales y mantener limpio el contexto principal, empieza con Subagents. Si tu objetivo es dejar que varios agentes trabajen como un pequeño equipo, discutan y se revisen entre sí, Agent Teams son la mejor herramienta.

Probar ambas en una tarea real suele aclarar la diferencia rápidamente: una está optimizada para aislamiento de contexto y recolección de resultados; la otra para colaboración multiperspectiva e interacción continua.

Enlaces relacionados

Artículo original: https://cloud.tencent.com/developer/article/2652960

nuwa-skill: convertir "destilar a una persona" de idea en workflow ejecutable

Wed, 22 Apr 2026 16:20:00 +0800

[alchaincyf/nuwa-skill](https://github.com/alchaincyf/nuwa-skill) puede hacer pensar primero en una cosa: usar AI para responder con la voz de una persona famosa. Pero lo realmente interesante no es si suena convincente. La clave es que intenta convertir “destilar cómo piensa una persona” en un workflow repetible.

Si eso funciona, el valor va mucho más allá de unos prompts entretenidos de personaje. Significa tomar el marco de juicio de alguien, sus prioridades, heurísticas comunes y hábitos de comunicación, y convertirlos en una skill que puede invocarse una y otra vez. Lo que quieres no es una frase que suene como algo que esa persona diría, sino algo más cercano a una interfaz operativa para “si esta persona analizara el problema, qué miraría primero, cómo haría tradeoffs y qué cuestionaría”.

Resuelve modelado, no imitación

Muchos llamados persona prompts son básicamente capas de estilo.

Suelen pedir al modelo:

hablar en el tono de alguien
citar más sus frases características
imitar la formulación que usa en público

Eso luce bien en demos, pero suele caerse en trabajo real. La razón es simple: el tono es superficie, mientras la estructura de juicio es el núcleo. Una persona es memorable no porque le gusten ciertas palabras, sino porque aborda problemas de formas reconocibles y consistentes.

La dirección de nuwa-skill se acerca más a extraer esos métodos estables. Le importa menos “cómo sonar como ellos” y más “cómo pensar como ellos”.

Un workflow más completo

Según la descripción del repositorio, nuwa-skill busca construir un flujo end-to-end: introducir el nombre de una persona, hacer automáticamente la investigación, extracción y validación, y finalmente organizar el resultado como una skill usable dentro de Claude Code.

Detrás de esa idea hay varios cambios importantes.

Primero, asume que la persona destilada no tiene que ser tu compañero de trabajo. Mucha gente encuentra esta idea como “capturar cómo trabaja un compañero fuerte”. Eso es valioso, pero limitado: el pool de muestras es pequeño y normalmente cubre solo experiencia interna del equipo. nuwa-skill amplía el objetivo a un rango mucho mayor de personas, como fundadores, inversores, científicos, product managers y escritores.

Segundo, enfatiza automatización en lugar de pedir al usuario que fabrique prompts a mano. Lo que vuelve práctica esta capacidad no es una redacción bonita, sino poder hacer de forma consistente recolección de fuentes, síntesis de puntos de vista, extracción de patrones y validación de resultados. En cuanto un paso depende totalmente del trabajo manual, el coste de reutilización sube rápido.

Tercero, intenta que la salida sea una skill y no una conversación única. La primera puede reutilizarse, combinarse e iterarse. La segunda normalmente solo funciona en el contexto actual y se deshace después de unos turnos.

Por qué importa esta dirección

Si tratas la AI como máquina de preguntas y respuestas, el caso natural es “dame una respuesta”. Pero si la tratas como un banco de trabajo, la pregunta pasa a ser “dame una forma de mirar este problema”.

Ahí se inclina el valor de nuwa-skill.

Por ejemplo, ante una decisión de producto quizá no quieras una respuesta estándar. Quizá quieras varios marcos analíticos muy distintos:

una persona empieza por compounding a largo plazo
otra por restricciones de recursos
otra por consistencia de experiencia de usuario
otra por timing de entrada al mercado

Si esos marcos pueden empaquetarse de forma fiable, la AI deja de ser “algo que escribe un párrafo” y se vuelve “algo que ayuda a cambiar de perspectiva rápido”. Eso es mucho más útil que imitar citas famosas, porque afecta directamente la calidad de decisión.

Lo más convincente: convertir conocimiento tácito en activos invocables

Muchas capacidades de alto valor son difíciles de escribir como SOP.

Que alguien juzgue consistentemente mejor que otros no suele deberse a que conozca más reglas explícitas, sino a que ha construido un sistema tácito de filtrado durante años:

qué señales merecen atención primero
qué ruido debe ignorarse de inmediato
qué preguntas deben descomponerse
qué preguntas deben invertirse
qué conclusiones deben esperar más evidencia

Esta capacidad es difícil de preservar porque las personas no siempre pueden explicarla claramente. Justo por eso la extracción estructurada es valiosa. Lo atractivo de nuwa-skill es que no intenta mover conocimiento superficial, sino reorganizar hábitos cognitivos.

Dónde encaja mejor

Creo que este tipo de skill es especialmente útil en varios escenarios.

1. Revisión multiperspectiva antes de una decisión

Si ya tienes un plan pero temes estar pensando solo por el camino que conoces, cambiar a distintas “perspectivas persona” para revisar el mismo asunto es más valioso que pedir al modelo que siga expandiendo tu redacción original.

2. Aprender el marco de juicio de cierto tipo de experto

Mucha gente aprende de expertos coleccionando citas, viendo entrevistas y copiando resúmenes. Al final, a menudo solo recuerda algunas frases bonitas. Cuando un patrón de pensamiento se vuelve una skill, aprender se parece más a “invocarlo repetidamente con preguntas reales” que a “apilar notas estáticas”.

3. Compartir un estilo analítico en un equipo

Lo que muchos equipos carecen no es solo documentación, sino una respuesta compartida a “cómo solemos pensar cuando encontramos un problema”. Si este workflow madura más, también podría usarse a la inversa para preservar métodos de operadores internos fuertes. Está claro que el proyecto no quiere limitar la idea a casos internos.

La parte difícil de proyectos así

Por supuesto, una dirección atractiva no significa que los problemas difíciles ya estén resueltos.

El desafío real no es instalar una skill. Es:

si las fuentes son suficientemente fiables
si los patrones extraídos son estables y no ilusiones de textos dispersos
si el modelo realmente usa el marco de una persona o solo repite impresiones comunes
si las fronteras entre distintas personas se difuminan dentro del modelo

La pregunta clave no es “¿puede generar algo plausible?”, sino “¿puede el marco cognitivo producido por esta skill sobrevivir reutilización en muchas tareas?” Si el proyecto profundiza en validación, su credibilidad mejorará mucho.

Por qué va más allá de una librería de templates de prompt

En el pasado, muchos proyectos manejaban esta capacidad como una librería de prompts: una persona, un prompt, y el usuario lo copia al chat. El problema es que una librería de templates sigue siendo un activo estático. Se actualiza despacio, la validación es débil y cuesta convertirla en un workflow de producción.

Lo que nuwa-skill empuja más lejos es convertir “destilación de persona” de un problema de template en un problema de workflow.

Cuando el centro de gravedad cambia de “escribir un prompt” a “generar, validar e iterar sistemáticamente una skill persona”, todo empieza a parecer más ingeniería que inspiración. Para cualquiera que quiera usarlo a largo plazo, ese es el cambio más importante.

Cierre

nuwa-skill es interesante no porque convierta la AI en un show de imitación de celebridades, sino porque acerca “cómo aprender cómo piensa alguien” a algo ejecutable, reutilizable e iterable.

Si muchos persona prompts resuelven “cómo hablar como alguien”, este proyecto quiere resolver “cómo mirar problemas como alguien”. Lo primero es genial para demos. Lo segundo está mucho más cerca de una herramienta real de productividad.

Referencias

Repositorio GitHub: https://github.com/alchaincyf/nuwa-skill
README del proyecto: https://github.com/alchaincyf/nuwa-skill/blob/main/README.md
Definición de Skill: https://github.com/alchaincyf/nuwa-skill/blob/main/SKILL.md

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