Buenas prácticas contra los tokens cada vez más caros

Se acabó el happy hour. Durante dos años hemos estado disparando tokens a caño gordo convencidos de que esa era la nueva normalidad, y resulta que alguien, en algún sótano de alguna gran tech, estaba apuntando en un papel lo que nos íbamos a terminar debiendo. En este episodio, José Manuel Gómez y yo hablamos de lo que significa realmente el fin de la tarifa plana en GitHub Copilot y Claude Code, de las alternativas que ya estamos probando y, sobre todo, de las buenas prácticas que ahora dejan de ser recomendaciones para convertirse en estrategias de supervivencia. Todos los recursos que mencionamos en la conversación están desplegados en la newsletter de esta semana para que puedas meterte en faena sin buscar nada.

Lo que vas a encontrar aquí:

• Por qué GitHub Copilot ha pasado de multiplicador x3 a x27 y qué significa eso para tu bolsillo
• Alternativas reales con modelos chinos y Ollama por unos 20 $/mes
• Cómo elegir el modelo justo para cada tarea (spoiler: casi nunca necesitas Opus)
• El concepto de desarrollo por olas y el principio de única responsabilidad aplicado a los prompts
• Qué son las redes deterministas y por qué los linters y los tests vuelven a ser protagonistas

¿Por qué se acabó la tarifa plana de la IA? ¶

La explicación honesta es que nunca fue sostenible. Hemos pasado de pedirle cosas a un chat a tener agentes que ejecutan, fallan, refactorizan y validan en bucle. Cada iteración de ese agente consume tokens. Muchos. Y si encima el agente está trabajando sin que tú lo mires, se pueden acumular llamadas durante horas sin que te enteres.

El caso más llamativo ha sido GitHub Copilot. Tenía un sistema de peticiones con multiplicadores por modelo: hasta hace poco, Opus costaba un multiplicador de 3. Con los modelos más recientes eso ha subido de forma escandalosa: estamos hablando de un multiplicador x27 para los modelos top. Y por si eso fuera poco, han cerrado el plan Pro de 20 dólares al mes a nuevos usuarios y eliminado el plan anual. Si ya lo tenías, de momento lo conservas. Si no, preparas la tarjeta o buscas alternativas.

Anthropic tampoco está exento de movimientos en ese sentido. Las cuentas de Claude Code también tienen sus límites por ventana de horas y semanales, y aunque recientemente duplicaron el límite de la ventana de 5 horas, el semanal sigue siendo el mismo. José Manuel lo ha vivido en carne propia: llegó al límite del periodo de 5 horas y tuvo que bajar de Opus a Sonnet.

¿Y qué pasó? Que la tarea se completó igual de bien.

🔑 Lo que llevamos meses sospechando queda confirmado: la mayoría de las tareas del día a día no necesitan el modelo más caro. El coste extra de Opus solo se justifica cuando la complejidad del problema lo exige de verdad.

¿Tiene sentido pasarse a modelos chinos y Ollama? ¶

La respuesta corta: sí, como alternativa y para experimentar. La larga tiene matices.

José Manuel lleva semanas trabajando con Ollama Cloud (la “o” delante, no es Llama de Meta) pagando unos 17-20 dólares al mes. Eso te da acceso a modelos como Qwen 2.6, DeepSeek V4 Pro o GLM 5.1 desde OpenCode o incluso desde Claude Code con la configuración que ellos mismos documentan.

La experiencia ha sido… interesante. El Qwen 2.6 le ha dado buenos resultados: rápido, con límites más generosos de lo esperado, y suficientemente capaz para tareas habituales. DeepSeek, en cambio, se tomó 45 minutos “pensando” en un proyecto con Remotion para generar un resultado que no convenció a nadie.

⚠️ No esperes los resultados que obtienes con Sonnet o con GPT-4o. La diferencia existe. Pero es mucho menor de lo que era hace un año, y eso ya es suficiente razón para tenerlos en el radar.

Lo que sí queda claro es que no puedes estar atado a un único proveedor. Los que solo conocen Claude Code o solo conocen ChatGPT están dejando encima de la mesa un abanico de opciones que, con los precios actuales, cada vez tiene más sentido explorar. Aprender a trabajar con OpenCode, por ejemplo, te abstrae del modelo concreto y te da libertad para cambiar cuando los precios suban o la calidad de alguna alternativa mejore. Justo sobre eso hablamos en detalle en este artículo sobre cómo migrar de Claude Code a Codex o a OpenCode.

¿Cómo elegir el modelo adecuado para cada tarea? ¶

Aquí hay una cita del episodio que me parece especialmente útil. José Manuel la formuló parafraseando a Richard Feynman: “Lo que no puedo crear, tampoco puedo entender del todo.” Aplicado a los modelos: si un modelo no puede generar algo con calidad, probablemente tampoco comprende bien el problema.

Eso nos lleva a una práctica concreta: delegar las fases del razonamiento a los modelos más caros y la implementación a los más económicos. Una estrategia que ya usábamos hace unos meses (Opus para el plan, Sonnet para la implementación) y que cobra más sentido ahora que los multiplicadores se han disparado.

La tabla mental que propongo para distribuir el trabajo:

• Tareas de exploración y búsqueda en ficheros: modelo gratuito o el más barato disponible. En OpenCode existe el modelo Big Pickle (así, con ese nombre), que viene incluido en la cuenta base y funciona para cosas concretas.
• Implementación estándar, refactorizaciones, generación de tests: Sonnet. En la mayoría de contextos es más que suficiente.
• Razonamiento complejo, arquitectura, decisiones con muchas dependencias: ahí sí tiene sentido poner Opus o equivalente. Pero como excepción, no como norma.

💡 Si tienes una tarea que podrías hacer tú mismo en un par de iteraciones, no necesitas el modelo de 27x multiplicador. Usa el más barato, supervisa el resultado, y reserva la potencia para cuando de verdad lo pidas.

Además, la mayoría de los entornos ya permiten configurar el modelo por contexto. En Copilot, por ejemplo, podías especificar el modelo en el frontmatter de configuración. Es un pequeño ajuste que, a final de mes, puede suponer una diferencia notable en el consumo de créditos.

¿Qué es el desarrollo por olas y por qué reduce el coste de los tokens? ¶

El principio de única responsabilidad (el famoso SRP de SOLID) lleva décadas aplicándose al código. Lo que estamos descubriendo ahora es que funciona igual de bien aplicado a cómo le pedimos las cosas a la IA.

El concepto de “desarrollo por olas” que plantea José Manuel es sencillo: en vez de lanzar una tarea enorme con múltiples dependencias, la divides en secuencias de responsabilidad única. Cada ola tiene una función completa y acotada. Cuando el modelo termina esa función, evalúas el resultado y decides si pasar a la siguiente.

¿Por qué reduce el consumo de tokens? Por dos razones:

1. El contexto no se satura. Los modelos empiezan a perder el hilo cuando el contexto crece demasiado. Con tareas más pequeñas, eso no ocurre.
2. Detectas errores antes. Si algo falla en la ola 2, no has malgastado tokens en la ola 3, 4 y 5 basándose en un supuesto incorrecto.

La misma lógica se puede llevar a la arquitectura. Si trabajas con microfrontends o con módulos bien delimitados, la IA trabaja sobre un dominio acotado y los resultados son más predecibles.

🎯 El Elephant Carpaccio aplicado a la IA: cortar la tarea en lonchas tan finas que cada una sea verificable por sí sola. No porque la IA no pueda con más, sino porque tú puedes validar más rápido y gastar menos en el proceso.

Esto conecta directamente con lo que desarrollamos en el framework Superpowers para aplicar buenos métodos con agentes de IA, donde el principio de tareas de única responsabilidad es una de las 14 prácticas que más impacto tienen en la calidad del output y en el control del consumo.

¿Qué son las redes deterministas y cómo ayudan a validar lo que genera la IA? ¶

Esta es, para mí, la parte más importante del episodio. Y la que menos titulares genera porque no hay ningún modelo nuevo ni ninguna herramienta flamante. Solo sentido común.

Las redes deterministas son el conjunto de herramientas que rodean a la IA y que nos dicen, de forma objetiva y sin ambigüedad, si el código generado cumple los estándares del proyecto. Frente a la “ruleta rusa generativa” (que si el resultado está bien o mal, nunca sabes muy bien), esta capa añade certeza.

¿De qué herramientas hablamos?

Linters estrictos. ESLint en JavaScript, con reglas bien configuradas, puede bloquear patterns que sabes que la IA tiende a generar mal. Por ejemplo: limitar el número de useEffect sin dependencias claras, forzar convenciones de naming del equipo, o prohibir ciertos imports. La IA genera código con el sesgo de los millones de ejemplos de YouTube y Stack Overflow que tiene en su entrenamiento. Un linter bien afinado contrarresta ese sesgo.

Análisis estático del código. Herramientas como SonarQube o sus alternativas open source para JavaScript detectan lógica duplicada, código no usado, violaciones de Clean Architecture o complejidad ciclomática excesiva. Todo lo que la IA tiende a generar cuando se le deja correr sin supervisión.

Tests como quality gate. José Manuel lo plantea con mucha honestidad: el TDD puro gasta más tokens y los resultados son dispares. Pero combinar tests pequeños, acotados a cada ola de desarrollo, con el linter, ya te da una red de seguridad razonable. La clave es que el test sea lo suficiente pequeño como para ejecutarse rápido y fallar con precisión.

CI automatizado. Todo lo anterior pierde valor si solo vive en tu máquina local. El pipeline tiene que ejecutar el linter, el análisis estático y los tests antes de que cualquier PR llegue a revisión. Si algo falla, el despliegue no pasa. Eso es lo que convierte las buenas prácticas individuales en garantías de equipo.

🔑 La IA no es el problema. El problema es que la estamos usando sin red. Los linters, los tests y el CI son esa red. No son burocracia; son la diferencia entre un resultado validado y una ruleta.

Para profundizar en cómo monitorizar el consumo real de tokens en tu flujo de trabajo con Claude Code, el post Cómo ahorrar tokens en Claude Code va directamente al grano: prompts precisos, una tarea por conversación, grep antes de preguntar, y cómo elegir el modelo adecuado según la complejidad de lo que pides.

¿Cómo compartir skills y prompts en el equipo sin que se pierdan? ¶

Esta parte del episodio me parece especialmente relevante para quienes trabajáis en consultoras o en equipos con más de dos personas.

El problema es conocido: tienes una skill que reduce el consumo de tokens a la mitad en tus conversaciones, un prompt que le dice al modelo que no te haga la pelota y que vaya directo al código. Pero tus compañeros no lo tienen. Porque tú lo creaste, lo guardaste en algún rincón de tu máquina, y nadie más sabe que existe.

Eso no es un problema de herramientas. Es un problema de cultura.

José Manuel describe lo que están haciendo en su empresa: en esta fase inicial, todo el mundo sube sus prompts y skills a un repositorio compartido, hacen un destilado periódico, y trabajan para que esa base común esté disponible para todos. No hay todavía una figura dedicada exclusivamente a gestionar esto en la mayoría de los equipos. Pero la tendencia apunta en esa dirección.

La observabilidad también entra aquí. Dejar trazas de qué instrucciones funcionaron, en qué se equivocó el modelo, qué tipo de tareas generan más hallucinations… todo eso es información que puede mejorar el siguiente ciclo de trabajo. No hace falta un sistema sofisticado para empezar. Una carpeta en el repositorio con las reglas del proyecto, las skills de equipo y un pequeño registro de lo que funciona y lo que no ya es un comienzo.

💡 La skill que te ahorra tokens en cada conversación no es tuya: es del equipo. Si no está compartida, no existe.

¿Los modelos open source son una salida real? ¶

Sí y no, dependiendo de lo que esperas de ellos.

Lo que sí es cierto: los modelos open source están ahí, van a seguir estando, y la distancia de calidad con los privativos se ha reducido de forma notable en el último año. Si hace dos años la diferencia era de un año luz, ahora es comparable a trabajar con algo similar a Sonnet 4.5. No es lo mismo, pero es funcional para muchas cosas.

Lo que no cambia: para ejecutarlos en local necesitas hardware serio. La alternativa es usar Ollama Cloud (con suscripción de pago) o APIs con proveedores alternativos. El coste sigue siendo real, aunque sea menor.

Y hay un punto que José Manuel toca al final del episodio que me parece importante: la competencia está viva. Si los grandes suben precios sin parar, habrá otros que compitan por precio. Siempre ha funcionado así. Que hoy el panorama sea complicado no significa que en seis meses no haya alternativas razonables a precios menores.

La apuesta segura es no depender de un único proveedor. Aprender a cambiar de modelo según la tarea, experimentar con herramientas open source cuando puedas, y no dejar que la comodidad de una sola plataforma te cierre las opciones.

¿Cómo aplicar todo esto en tu semana? ¶

Algunas cosas concretas que puedes hacer ahora mismo:

• Revisa qué modelo tienes configurado por defecto en tu entorno de trabajo. Si es siempre el más caro, empieza a experimentar con Sonnet para tareas de implementación estándar y reserva el más potente para planificación y decisiones de arquitectura.

• Audita tus linters. Abre la configuración de ESLint (o lo que uses) y añade tres reglas relacionadas con los patterns que más problemas te generan. Haz que el linter falle antes de que llegue a PR.

• Divide la próxima tarea grande en olas. Escribe primero qué función única va a resolver cada ola. Antes de empezar la siguiente, verifica que la anterior funciona como esperas.

• Si tienes un prompt o una skill que te funciona, compártela con tu equipo esta semana. No esperes a tener el sistema perfecto. Una carpeta /ai en el repositorio con las instrucciones del proyecto ya vale más que nada.

• Prueba Ollama Cloud si tienes curiosidad por los modelos chinos. Son 17-20 dólares al mes y te dan acceso a Qwen, DeepSeek y GLM desde OpenCode. No te van a reemplazar a Sonnet, pero te van a enseñar cosas sobre cómo funcionan los modelos cuando no tienes el caño gordo disponible.

El fin de la tarifa plana no es una catástrofe. Es una corrección. Nos devuelve a un lugar donde pensar antes de lanzar tokens tiene valor. Donde las buenas prácticas de ingeniería vuelven a importar no solo como filosofía, sino como ahorro real.

¿Qué cambias tú esta semana en tu flujo de trabajo?

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter