No quiero que mi negocio dependa de si Anthropic tiene un buen día
El lunes por la mañana abrí una tarea que el viernes había salido perfecta. La misma tarea, el mismo prompt, el mismo modelo. Y de repente la cosa no daba pie con bola. Lo que el viernes hacía bien a la primera, el lunes no lo sacaba ni al segundo ni al tercer intento. No había cambiado nada por mi parte. Había cambiado algo por la suya, y yo no me había enterado.
Esto me ha pasado ya unas cuantas veces y cada vez me deja el mismo regusto. No es que el modelo sea malo. Es que no controlo cuándo deja de ser bueno. Y cuando montas un negocio encima de una herramienta que puede volverse tonta de un día para otro sin avisarte, tienes un problema que no es técnico. Es estructural.
El problema no es el modelo, es depender de él
Vamos a separar dos cosas que la gente mezcla. Una es qué modelo es mejor, si Opus o GPT o el que sea. Esa discusión me interesa poco. La otra es de quién dependes para tener ese modelo funcionando, y esa sí me quita el sueño.
Ahora mismo el mercado serio de IA está en dos o tres manos. OpenAI con GPT, Anthropic con Claude y sus Opus, Sonnet y compañía. Si tu flujo de trabajo vive dentro de una de esas empresas, tu negocio también. Suben el precio y lo pagas. Retiran un modelo de la suscripción y te toca pasar por API con un sobrecoste bestial. Deciden que tu caso de uso ya no les cuadra y te quedas fuera.
Y encima está la capa de encima, que es el gobierno. Todo esto son empresas estadounidenses sujetas a las decisiones de un solo país. Estados Unidos puede bloquear el acceso a esos modelos cuando le venga en gana, para ciertos países, para ciertos sectores, por el motivo que sea ese mes. No hace falta ser paranoico para ver el riesgo. Basta con haber vivido un par de cambios de política comerciales para saber que eso pasa y que a ti nadie te va a preguntar.
Yo trabajo como freelance de Drupal, subcontratado para agencias y con clientes directos. Si mañana no puedo servir el trabajo porque mi proveedor de IA está caído, ha subido precios o directamente me han cortado el acceso, el problema es mío, no de Anthropic. La factura la doy yo. Así que la pregunta no es cuál es el mejor modelo. La pregunta es cómo dejo de estar en una posición donde una decisión ajena me deja tirado.
La lobotomía silenciosa
Esto merece capítulo aparte porque es de lo más frustrante que hay. Un día el modelo funciona de maravilla y al día siguiente parece que le han quitado medio cerebro. Mismo nombre, misma etiqueta, y sin embargo las respuestas son notablemente peores.
Lo que suele pasar por debajo es que el proveedor ha cambiado la versión del modelo que sirve, muchas veces a una versión cuantizada. Cuantizar es reducir la precisión de los pesos del modelo para que ocupe menos y corra más barato. El proveedor se ahorra un dinero en infraestructura y tú te comes unas respuestas más flojas sin que nadie te lo diga. El modelo se llama igual pero no es el mismo.
Con los modelos cerrados no tienes ninguna defensa contra esto. No sabes qué versión te están sirviendo hoy ni si es la misma de ayer. No puedes fijarla. Solo notas que algo se ha atontado y te toca reescribir prompts que llevaban meses funcionando, como si el problema fuera tuyo.
El coste que no ves
El precio por token baja y todo el mundo aplaude. Pero el coste real no es el precio por token, es cuántos tokens gastas para terminar una tarea. Y ahí es donde está la trampa.
Los modelos nuevos suelen razonar más, dar respuestas más largas, generar conversaciones más largas. Te bajan el precio por token en el escaparate y por debajo el consumo total se dispara. Al final del mes la factura no ha bajado, o ha subido, aunque cada token individual sea más barato. Es un coste oculto que no aparece en ningún anuncio de lanzamiento.
Y luego está lo otro, que es más directo. Suben precios sin más. Retiran un modelo de la suscripción y te empujan a la API, que cuesta varias veces más. Limitan un plan que antes te daba de sobra. Cada uno de esos movimientos es legítimo desde su punto de vista, son un negocio. El problema es cuando tu negocio no tiene alternativa y te toca tragar con todos ellos.
Mi antídoto: un gateway con fallback
La idea de fondo es sencilla. No quiero una API, quiero un sitio donde estén todas mis APIs y que mis agentes hablen solo con ese sitio. En mi caso uso LiteLLM. Lo probé en su día, me gustó y me quedé con él, pero hay otros proxies de IA que hacen lo mismo, así que quédate con el concepto más que con la marca.
Lo que hace es exponer una única API hacia tus agentes. Por debajo tienes configurados todos tus proveedores externos y también la conexión con tus propios servidores. Tus agentes no saben ni les importa qué hay detrás. Piden un modelo y LiteLLM se encarga de servírselo desde donde toque.
La parte buena de verdad es el fallback. A cada modelo le puedes decir cuál es su plan B. Si falla la conexión con un proveedor, coge el relevo otro que tú hayas configurado, sin que el agente se entere. Puedes tener la API de Anthropic como principal y Amazon Bedrock como respaldo, sirviendo los mismos Opus y Sonnet pero desde otro proveedor. Si uno se cae, el otro responde. La IA que esperabas sigue contestando.
Con los modelos open source esto se vuelve todavía más potente. DeepSeek, Kimi, Qwen y compañía los sirven muchísimos proveedores distintos. Puedes poner por defecto el que más te guste, el más barato o el que gestione mejor la caché, y dejar un secundario para el mismo modelo a un precio parecido. Aunque tu proveedor principal tenga un mal día, la respuesta sigue llegando.
Y aquí viene lo importante de los modelos open source: no se atontan. Es el modelo, y siempre es el mismo. Si un proveedor te cuantiza el modelo y las respuestas empeoran, la solución es tonta de simple. Cambias de proveedor. Y si te lo puedes permitir, te lo alojas tú.
Eso último es lo que estoy haciendo con Qwen. Me he montado un servidor donde ejecuto las tareas de IA más simples, las más mecánicas. Un Qwen no le hace sombra a un Opus, seamos serios, pero para un porcentaje enorme del trabajo del día a día cumple de sobra. Y cuando corre en mi máquina, no hay proveedor que me lo pueda tocar, ni subir de precio, ni retirar, ni cuantizar a mis espaldas. Es mío.
La otra pata: skills que se auto-mejoran
El fallback me da resiliencia, pero solo la mitad de la historia. La otra mitad es conseguir que un modelo más barato haga el trabajo que hoy le pido a uno caro. Y ahí llevo unas semanas montando algo que me tiene bastante contento.
Es un orquestador de agentes con auto-mejora de skills. Cuando se genera una tarea, después hay una revisión con IA. Luego una revisión humana. Y después de la humana, hay una guía que repasa toda la conversación entera y detecta si algo es susceptible de convertirse en procedimiento, por ejemplo creando una skill nueva.
El truco está en el bucle. La próxima vez que llegue una tarea parecida, ya existe la skill que la documenta. Sabemos qué agentes son los idóneos, cómo abordarla y qué esperar. Eso reduce el coste en tokens de las tareas similares porque van mejor documentadas de entrada, y estandariza la salida, que para mí es casi tan importante como el ahorro.
Y aquí está la gracia de todo el asunto. Puedes usar un modelo listo, uno caro, solo para generar esa mejora. Una vez la skill está escrita, los modelos más tontos la aprovechan. Sonnet, Haiku, DeepSeek o el propio Qwen en local hacen tareas que antes necesitaban un modelo más caro, porque el conocimiento ya está capturado en la skill y no tienen que reinventarlo cada vez. Pagas la inteligencia una vez y la reutilizas muchas.
A esto le sumo mi módulo de Drupal audit, que mantengo en la comunidad. Expone unos comandos drush para que la IA, mientras trabaja en mi local, tenga acceso a las recomendaciones del módulo y a lo que detecta en el código y en las configuraciones que ella misma ha ido dejando en el proyecto. Es un lazo cerrado. La IA se autocorrige en bucle antes de que la revise otra IA y antes de que la revise un humano. Cada capa filtra un poco más y a mí me llega menos ruido que revisar.
Al final todo esto va de lo mismo. Reducir el tiempo que los humanos dedicamos a revisar, reducir el coste humano y reducir el coste en tokens. No es magia, es fontanería.
La herramienta idónea, no la perfecta
Si viviéramos en el mundo ideal, todos usaríamos el modelo más caro y más listo para todo, y a otra cosa. Pero en una empresa no se usan las herramientas perfectas, se usan las idóneas. La que saca el trabajo adelante, es rápida y está equilibrada de precio. No tiene sentido sacar el modelo más caro y perfecto para una tarea que un modelo simple, barato y rápido hace igual de bien.
Montar todo este tinglado tiene su coste. El fallback hay que configurarlo y mantenerlo. El servidor local hay que administrarlo, y no es gratis en tiempo aunque lo sea en factura mensual. El sistema de skills que se auto-mejoran todavía lo estoy afinando y no sé si el retorno compensará todas las horas que le estoy metiendo. Y por encima de todo, este campo se mueve tan rápido que igual la mitad de lo que he escrito aquí queda obsoleto en seis meses.
No quiero que mi capacidad de trabajar dependa de si una empresa a miles de kilómetros tiene hoy un buen día, de si su API está online, de si no han subido precios o de si un gobierno decide que este mes toca cortar el grifo. Prefiero repartir el riesgo, aunque me cueste más trabajo, aunque nunca esté del todo terminado.