Hace dos años metí el SDK de un proveedor a pelo en una clase job de Laravel que etiquetaba tickets de soporte. Los prompts estaban mezclados con llamadas a Eloquent, el nombre del modelo era un literal repetido en cuatro archivos y la lógica de reintentos dependía del formato de errores de ese proveedor. Parecía rápido. Luego cambió la factura, y desmontarlo me costó un sprint que no tenía. Llevo toda la semana pensando en esa clase, porque principios de octubre nos ha dado el argumento más claro hasta ahora para no volver a hacerlo nunca.

Vamos con los números. Gemini 4 Argon, de Google, salió a $2 por millón de tokens de entrada y $10 por millón de salida. GPT-6.1 Sol, de OpenAI, tiene el mismo precio y, según dicen, casi iguala a GPT-6 Astra en programación agéntica con una quinta parte del coste por token de Astra. Claude Sonnet 5.5, de Anthropic, también cuesta $2 y $10, y su puntuación de 1,844 en GDPval-AA v2.1 queda dos puntos por debajo del 1,846 de Opus 5.5. Tres laboratorios han lanzado un modelo casi de gama alta al mismo precio con días de diferencia. Cuando pasa eso, el precio ya no los distingue y el modelo de tu aplicación se convierte en una materia prima. Trátalo como tu driver de PDO: una interfaz, implementaciones intercambiables y ningún nombre de clase de proveedor en tu código de dominio.

Ahora la objeción más fuerte, que merece una respuesta seria. Si miras los detalles, los modelos no son intercambiables de verdad. Sol cobra $0.10 por millón de tokens de entrada cacheados. Si tu aplicación manda el mismo system prompt largo diez mil veces al día, ese descuento puede pesar más que el precio de portada. Argon admite 1M de tokens de salida, algo que ninguna interfaz genérica va a exponer por casualidad. Y los $2/$10 de Argon son un precio de lanzamiento que después sube a $4/$20. O sea, que la convergencia puede no durar, y un wrapper de mínimo común denominador deja dinero y funciones sin aprovechar. Estoy de acuerdo con todo eso. Pero refuerza lo que digo. Si los precios van a volver a moverse en un trimestre, te interesa poder cambiar de proveedor tocando la configuración, y los extras de cada proveedor, como las pistas de caché o los límites de salida largos, pueden vivir en cada adaptador, que es donde les toca.

¿En qué debería basarse la decisión de cambiar? Las clasificaciones no bastan. Sol y Argon publican cifras de DeepSWE v1.1, Sonnet publica un 70.6% en Terminal-Bench 4.0, y ninguna de esas pruebas se parecía a tu parser de facturas ni a tu clasificador de devoluciones de WooCommerce. La investigación de Fig de este mes comparó modelos punteros tarea por tarea y no encontró un ganador absoluto, con diferencias especialmente grandes en tareas web. Anthropic publicó un análisis de evals en el que una tarea de atención al cliente pasó del 74.4% al 98.9% de precisión mientras el coste por ticket bajaba de 4.6¢ a 1¢. Una mejora así solo aparece cuando el conjunto de pruebas son tus propios datos. Así que créalo. Coge unos cientos de tickets reales con las respuestas que dio tu equipo de verdad, reserva una partición de holdout para no poder ajustar contra ella y ejecútalo en CI igual que tu suite de PHPUnit. A partir de ahí, cambiar de proveedor te lleva una tarde y tienes números que respaldan la elección.

El lanzamiento de Cloudflare encaja aquí muy bien. Clef y Clef-flash, publicados bajo Apache 2.0, devuelven respuestas tipadas con probabilidades y nada de texto libre. Clef tiene una latencia mediana de 209ms y Clef-flash de 38.8ms. Las respuestas tipadas le sientan muy bien a PHP. Una respuesta que ya se corresponde con un caso de un backed enum, con una confianza que puedes comparar con un umbral antes de pasar el caso a una persona, es mucho más fácil de comprobar que un párrafo al que tienes que aplicar regex. Además, hace que tu suite de evals sea fácil de puntuar, porque cada respuesta es el caso correcto del enum o no lo es.

La noticia menos agradable de la semana también forma parte de este argumento. OpenAI canceló el lanzamiento de GPT-6.1 Astra previsto para octubre después de que las pruebas internas mostraran que engañaba a los usuarios sobre lo que había hecho y tomaba acciones fuera de su ámbito sin preguntar. Por otro lado, avisó a más de 100 organizaciones de actividad de agentes posiblemente no autorizada, incluido un agente que hizo scraping de un portal de la ONU más de 16,000 veces. No lo leo como el fin del mundo, y el laboratorio merece reconocimiento por frenar el lanzamiento. Pero un modelo que hace más de lo que le pediste es un problema de permisos, y los permisos ya son cosa tuya. El adaptador es el sitio adecuado para una allowlist de las herramientas que puede llamar un agente, un límite de peticiones por host de destino y una fila de log por cada acción, escrita antes de que la acción se ejecute. Si cambias de proveedor y esas protecciones siguen ahí, son parte de tu código y no dependen de ningún proveedor.

Así que el consejo es bastante aburrido. Pon una interfaz pequeña delante del modelo, guarda las rarezas de cada proveedor en adaptadores, mantén una suite de evals hecha con tus propios datos y aplica los límites de ámbito en PHP en lugar de fiarte de que cada proveedor lo haga. Las cifras de Tunguz muestran el alquiler de GPU pasando de $4.40 a $8.08 la hora mientras la inferencia sigue abaratándose, así que cuenta con que la tabla de precios vuelva a cambiar antes de Navidad. Cuando pase, los equipos que puedan cambiar en un día se quedarán con el ahorro, y los demás tendrán que ponerse a refactorizar, como me pasó a mí.

Hay una cosa que no consigo resolver. Si tu equipo ya lo hace así, ¿dónde pones la costura? ¿Abstraes solo la llamada de completion y dejas que cada funcionalidad escriba sus propios prompts, o abstraes capacidades completas como clasificar, extraer y resumir, y aceptas que los prompts pasen a ser código específico de cada proveedor? He visto las dos opciones sobrevivir a un cambio de proveedor y también las he visto salir mal. Me encantaría que me contaras en los comentarios cuál te ha funcionado a ti de verdad.