¡Hola Devs! Esto cambió (y mucho)
Si has estado usando IA en Cloudflare, seguro te pasó: ¿uso AI Gateway o Workers AI? Eran dos productos separados que, en el fondo, resolvían lo mismo — conectarte a un modelo con una capa de control encima.
- AI Gateway era el proxy: apuntabas a OpenAI, Anthropic o cualquier provider y ganabas observabilidad, logging, control de acceso y cache.
- Workers AI era el hosting: Cloudflare corre las GPUs, tú solo pegas al endpoint.
Ahora Cloudflare está unificando todo en un solo control plane. Vamos a ver qué ya está disponible y qué viene.
Fuente: Cloudflare Blog — Unifying Workers AI and AI Gateway
Lo que ya está disponible
1. Un binding, un endpoint REST
El binding env.AI ahora enruta por AI Gateway por default. Si nunca configuraste un gateway, se crea uno automáticamente en la primera request autenticada.
// Antes: llamada directa a Workers AI, sin observabilidad
export default {
async fetch(request, env) {
const response = await env.AI.run('@cf/zai-org/glm-5.2', {
messages: [{ role: 'user', content: '¿Cuál es la capital de Francia?' }],
});
return new Response(JSON.stringify(response));
},
};
// Después: misma llamada, ahora con observabilidad completa
export default {
async fetch(request, env) {
const response = await env.AI.run(
'@cf/zai-org/glm-5.2',
{ messages: [{ role: 'user', content: '¿Cuál es la capital de Francia?' }] },
{ gateway: { id: 'default' } } // se crea automático la primera vez
);
return new Response(JSON.stringify(response), {
headers: { 'Content-Type': 'application/json' },
});
},
};
Misma idea por REST:
curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/@cf/zai-org/glm-5.2" \
-H "Authorization: Bearer {api_token}" \
-H "Content-Type: application/json" \
-H "cf-aig-gateway-id: default" \
-d '{"messages":[{"role":"user","content":"¿Cuál es la capital de Francia?"}]}'
2. La observabilidad ahora viene de fábrica
Cada request por el gateway default loguea payload completo de request/response, conteo de tokens por modelo y atribución de costo — sin configurar nada. Si el default se te queda chico, cambias id: 'default' por un gateway con nombre y listo. Una línea.
3. Billing unificado (esto está buenísimo 🔥)
Antes los créditos de AI Gateway solo servían para providers externos (OpenAI, Anthropic). Ahora tu wallet de AI Gateway también financia Workers AI. Cargas crédito una vez, lo gastas en cualquier provider soportado. Bonus: los rate limits de Workers AI suben si usas billing unificado.
4. Model-first routing (en camino)
Este es el cambio arquitectónico de verdad. En lugar de provider-first ("¿a qué provider le pego?"), pasas a model-first ("¿qué modelo necesito?").
| Aspecto | Provider-first (hoy) | Model-first (próximamente) |
|---|---|---|
| Tú especificas | Provider + modelo | Solo el modelo |
| Failover | Retry manual en tu app | Lo maneja el gateway |
| Load balancing | Lo haces tú | Transparente |
| Compliance ZDR | Config por provider | Lo aplica el gateway |
Ejemplo de request:
curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/v1/chat/completions" \
-H "Authorization: Bearer {api_token}" \
-H "cf-aig-gateway-id: my-gateway" \
-H "Content-Type: application/json" \
-d '{"model":"kimi-k2.7-code","messages":[{"role":"user","content":"Revisa esta función"}]}'
Pides kimi-k2.7-code. El gateway decide si viene de Workers AI, de Moonshot o de otro host validado — y hace failover transparente si uno está rate-limited.
5. Smart routing (más adelante)
Un clasificador en Workers AI lee tu prompt, identifica la tarea (código / research / resumen / QA), puntúa la complejidad y elige el mejor modelo de un pool curado. Cero config si no quieres; pin explícito de modelo si sí.
Ojo con esto (limitaciones reales)
Antes de migrar todo, unos puntos honestos:
- Model-first routing todavía no es GA. Cloudflare dice "pilot en los próximos meses". No diseñes tu arquitectura como hard dependency — trátalo como capa de optimización.
- Gateway default = logging default. El payload completo de request/response va al log. Si manejas PII o datos regulados, necesitas configurar retention, redaction o un gateway con nombre y política más estricta. Esto es compliance de verdad, no un detalle.
- Billing unificado es cómodo, pero sigue siendo prepago. Cargas wallet. Si el workload explota y la wallet se vacía, tus requests fallan — igual que cualquier modelo prepago. Configura alertas de budget.
- "Providers validados" es caja negra. Cloudflare dice que trabaja con providers validados para model-first routing, pero los criterios no son públicos. Si tienes requisitos de vendor (SOC2, residencia de datos), verifica antes de confiar en el failover automático.
- Rate limit elevado es zanahoria, no garantía. Los límites mayores para usuarios de billing unificado son reales, pero promocionales. No asumas que duran para siempre.
Próximos pasos
Si ya usas Workers AI: activa el gateway default. Es una línea de cambio y ya ganas logging, token tracking y atribución de costo. Cero downside.
Si usas AI Gateway con providers externos: agrega un modelo de Workers AI a tu ruteo. El billing unificado te deja consolidar gasto. Empieza con un modelo de embedding barato o un resumidor para probar.
Si estás construyendo resiliencia multi-provider: prototipa model-first routing ya, pero mantén fallback. El patrón (especificar modelo, no provider) es el mental model correcto, pero la implementación todavía no está estable.
El panorama completo
Cloudflare está construyendo en silencio la capa de control plane para todo el stack de IA — no solo inferencia, sino ruteo, billing, observabilidad y failover. Es una apuesta mucho más grande que "hosteamos GPUs". Es el mismo movimiento que hizo AWS con API Gateway, pero para llamadas a modelos.
Para el dev, el takeaway práctico es simple: deja de escribir retry logic y capas de abstracción de provider a mano. Eso ahora es infraestructura. Tu trabajo es elegir el modelo correcto para la tarea y dejar que el control plane haga el resto.