Cloudflare Unificó Workers AI y AI Gateway Qué Cambia en Tu Código Hoy

¡Hola Devs! Vamos a ver qué cambió

Si ya andas metido en el stack de IA de Cloudflare, ya sabes del roce: Workers AI te da inferencia como servicio en GPUs administradas, AI Gateway te da observabilidad, cache y control de acceso entre proveedores. Dos productos, dos entrypoints, dos modelos mentales — pero el mismo objetivo final: mandar el request al modelo y ver qué pasó.

Pues eso se está colapsando. Cloudflare anunció que Workers AI y AI Gateway convergen en un solo camino: te conectas a cualquier proveedor (incluyendo Workers AI mismo) y administras observabilidad, billing, seguridad y logs desde un solo plano de control. Para quien corre inferencia en producción, esto no es feature nueva — es cambio estructural en cómo arquitectas las llamadas.

La lógica es simple: desde el punto de vista del usuario, los dos productos ya hacían lo mismo. La arquitectura era distinta, la intención no. La convergencia solo hace que la abstracción coincida con la realidad. El anuncio completo está en el post original de ingeniería de Cloudflare.

Fíjate en lo que esto significa en la práctica 👇

Qué cambió de verdad bajo el capó

Un binding, un endpoint REST

El binding env.AI ya no distingue entre "Workers AI" y "AI Gateway" — es un solo camino. Lo mismo en la API REST: el endpoint /ai/run/ ahora acepta el header cf-aig-gateway-id para enrutar por un gateway.

Mira cómo queda la llamada vía binding, enrutando un modelo de Workers AI por el gateway default:

// worker.js — enruta Workers AI por el AI Gateway default
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', // 'default' crea el gateway automáticamente en el primer uso
        },
      }
    );
    return new Response(JSON.stringify(response), {
      headers: { 'Content-Type': 'application/json' },
    });
  },
};

Y el equivalente vía 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?"}]
  }'

Gateway default = observabilidad sin setup

La victoria más inmediata: ya no necesitas crear un gateway antes. Pasas id: 'default' y AI Gateway provisiona uno en el primer request autenticado. Cada llamada queda logueada con payload completo de request/response, conteo de tokens por modelo y atribución de costo — sin configurar dashboard.

La diferencia es literalmente un argumento:

// Antes — llamada directa a Workers AI, sin visibilidad del gateway
const response = await env.AI.run('@cf/zai-org/glm-5.2', {
  messages: [{ role: 'user', content: '¡Hola!' }],
});

// Después — misma llamada, observabilidad total vía AI Gateway
const response = await env.AI.run(
  '@cf/zai-org/glm-5.2',
  { messages: [{ role: 'user', content: '¡Hola!' }] },
  { gateway: { id: 'default' } } // crea el gateway automáticamente en el primer uso
);

Si el default se te queda chico — reglas de cache customizadas, split de tráfico por aplicación — creas un gateway con nombre y cambias un parámetro. Sin refactorizar código.

Roadmap: model-first y smart routing

Billing unificado entre todos los proveedores

El uso de Workers AI ahora se puede pagar con créditos de la cartera de AI Gateway. Antes, los créditos de AI Gateway solo aplicaban a proveedores externos (OpenAI, Anthropic y compañía). Ahora la misma cartera cubre Workers AI, y Cloudflare está ofreciendo rate limits elevados para quien usa billing unificado — un empujoncito para consolidar el gasto en el gateway.

Enrutamiento model-first (próximamente)

Esta es la parte arquitectónicamente interesante. Hoy, llamar a un modelo significa saber qué proveedor lo hospeda. Si el proveedor se cae o te da rate-limit, tu app se rompe y escribes lógica de fallback a mano.

Model-first invierte la dependencia:

Pides kimi-k2.7-code; el gateway decide si eso viene de Workers AI, de la API de Moonshot o de otro host verificado sirviendo los mismos pesos. Si Workers AI tiene capacidad, usas infra administrada. Si no, el tráfico balancea de forma transparente. Todavía puedes fijar un proveedor si quieres — pero ya no estás obligado.

# Request model-first — sin proveedor especificado, el gateway enruta
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"}]
  }'

Smart routing (más adelante)

Más allá del failover, Cloudflare está construyendo un clasificador en Workers AI que lee tu prompt, predice el tipo de tarea (coding, research, summarization, Q&A general), la complejidad y cuánto importa el contexto, y luego mapea heurísticamente al mejor modelo de un pool curado. Zero-config para quien no quiere mantener lógica de enrutamiento; selección explícita sigue disponible para quien sí. Hoy está en piloto interno.

Puntos de atención que vale la pena marcar

• El lock-in crece. Cuando billing, enrutamiento y observabilidad viven en un solo plano de control, migrar hacia afuera se vuelve proyecto grande, no cambio de SDK.
• Model-first routing no está en el aire. Se anunció, está en piloto interno y es "próximos meses". Diseña pensando en eso, pero no dependas todavía.
• Gateway default es conveniente, no gratis. Loguear payload completo significa que el prompt vive en la capa de observabilidad de Cloudflare — valida esto contra tu política de retención y compliance antes de prenderlo en producción.
• Rate limit elevado es incentivo de billing. Es real, pero también es un empujón al prepaid. Haz la cuenta contra tu mix actual de proveedores.

Próximos pasos

Si ya estás en Workers AI: enruta un endpoint no-crítico vía gateway: { id: 'default' } y observa el dashboard por una semana. Te llevas datos de tokens y costo que no tenías, con una línea de cambio.

Si estás en AI Gateway: intenta agregar una llamada de modelo Workers AI al mix y confirma si el billing unificado se comporta como está documentado.

Para quien escala carga de inferencia, el problema vecino — distribuir cómputo en un cluster — vale la pena combinarlo con esto. Échale un ojo a nuestro tutorial práctico de Ray + AWS para escalar Python en un cluster en la nube para el lado de orquestación. Y si andas siguiendo hacia dónde va la inferencia en el borde, nuestro breakdown de NVIDIA TensorRT Edge-LLM para vehículos autónomos y robótica cubre la frontera del hardware.

Resumiendo

La unificación de Workers AI + AI Gateway de Cloudflare es simplificación arquitectónica de verdad, no rebranding de marketing. Las victorias inmediatas — gateway default, billing unificado, un solo binding — ya se pueden usar hoy y cuestan un parámetro. Las victorias estratégicas — model-first routing, smart routing — son la razón para importarte la dirección, pero todavía no están en tu mano.

Trata el gateway default como tu nuevo baseline de observabilidad. Trata model-first routing como premisa de diseño para el próximo trimestre, no como dependencia de este. Y mantén el ojo en la cuenta del lock-in conforme el plano de control absorbe más de tu stack. 🚀