OpenRouter ha agregado una herramienta beta de ejecución de shell alojada y una API de archivos, lo que brinda a los desarrolladores una forma de permitir que los modelos de llamada de herramientas ejecuten comandos en contenedores Linux aislados a través de la capa de enrutamiento de OpenRouter. El lanzamiento es más que otra característica del agente. Cambia el modelo de contabilidad para la infraestructura de IA multimodelo: una solicitud ahora puede incluir tokens de modelo, tiempo de ejecución de herramientas, manejo de archivos y comportamiento de compatibilidad en más de un estilo de API.

La nueva herramienta de servidor, denominada openrouter:shell, permite que los modelos compatibles ejecuten comandos en contenedores alojados y devuelvan resultados de ejecución estándar, incluidos stdout, stderr y códigos de salida. OpenRouter dice que la herramienta funciona a través de su ruta API de Respuestas y su ruta de compatibilidad API de Mensajes Antrópicos, lo cual es importante porque los desarrolladores intentan cada vez más mantener las implementaciones de agentes portátiles entre proveedores de modelos en lugar de vincular cada flujo de trabajo a la interfaz de herramienta nativa de un proveedor.

OpenRouter valora el sandbox a $0,0001 por segundo, facturado como parte de la solicitud. El uso de la API de archivos está incluido durante la versión beta. Esto crea una dimensión de costo separada de los tokens de entrada y salida ordinarios, y brinda a los operadores de puerta de enlace un ejemplo concreto de por qué la facturación unificada de API de IA se está volviendo más difícil que sumar los cargos de los tokens modelo.

Qué cambió

Hasta hace poco, la ejecución de código alojado generalmente estaba vinculada a una pila de agentes específica del proveedor o requería que los desarrolladores operaran su propia flota de entornos aislados. La versión beta de OpenRouter inserta esa capacidad en una plataforma de enrutamiento que ya se utiliza para acceder a muchos modelos. En términos prácticos, un agente puede pedirle a un modelo que inspeccione datos, ejecute scripts, manipule archivos o pruebe pequeños fragmentos de código sin que el equipo de la aplicación aprovisione contenedores directamente para cada ejecución.

El detalle de compatibilidad es importante. OpenRouter está posicionando la herramienta shell no como una capacidad de una familia de modelos, sino como una superficie de herramienta a nivel de plataforma disponible a través de patrones API familiares. Para los equipos que se han basado en la semántica de Respuestas de estilo OpenAI o la semántica de Mensajes de estilo antrópico, la herramienta alojada puede ubicarse más cerca de la capa de puerta de enlace que de la capa de modelo.

Eso no hace que el comportamiento de la herramienta sea mágicamente uniforme. Los diferentes modelos varían en cómo llaman a las herramientas, se recuperan de fallas, razonan sobre la salida de comandos y administran archivos. Pero la decisión sobre infraestructura está cambiando. En lugar de preguntar sólo qué modelo puede escribir un comando de shell, los desarrolladores ahora tienen que preguntar qué puerta de enlace puede ejecutarlo de forma segura, medirlo y devolver los resultados en la forma API que su cliente ya entiende.

Por qué es importante la medición del tiempo de ejecución

El precio de los tokens ya no es suficiente para describir el costo de la solicitud de un agente. Una sola acción de usuario puede implicar un aviso, varios giros de modelo, carga de archivos, ejecución de shell, reintentos y resumen final. La parte costosa puede ser la salida del modelo, o puede ser un comando de larga duración que produce poco texto. El precio por segundo del sandbox de OpenRouter hace explícita esa distinción.

Para los desarrolladores, la consecuencia inmediata es el diseño del presupuesto. Los bucles de agentes necesitan límites en la duración de los comandos, el comportamiento de reintento y los supuestos de retención de archivos. Una solicitud aparentemente inofensiva que se expande a repetidas llamadas de shell puede acumular cargos de tiempo de ejecución incluso si el uso del token sigue siendo modesto. El registro debe mostrar no solo el número de modelos, proveedores y tokens, sino también el nombre de la herramienta, la duración de la ejecución, el estado de salida y si el modelo se reintentó después de un error.

Para las empresas que se basan en pasarelas modelo, el cambio afecta a los márgenes y a los informes de los clientes. Un producto asociado que revende automatización de IA no puede tratar cada solicitud como una finalización de texto con un marcado. Necesita un libro de registro de uso que pueda atribuir el costo del modelo y el costo de la herramienta alojada al espacio de trabajo, al cliente final o a la clave API adecuados. Esto es directamente relevante para la automatización de API de socios, donde es posible que el cliente intermedio nunca vea la factura sin procesar de OpenRouter pero aun así espera una factura coherente.

Quién se ve afectado

El primer grupo afectado son los desarrolladores de agentes que desean la ejecución de código sin comprometerse con la plataforma de agente completa de un proveedor de modelo. El enfoque de OpenRouter puede resultar atractivo para los equipos que ya dirigen el tráfico entre modelos y desean agregar acceso al shell manteniendo cierta flexibilidad en la elección del modelo.

El segundo grupo son los equipos de plataforma y puerta de enlace. Ahora tienen que decidir si las herramientas alojadas son elementos de catálogo de primera clase, si se pueden habilitar por espacio de trabajo y cómo aparecen sus costos en los paneles. Es posible que sea necesario combinar una fila del catálogo de modelos con la disponibilidad de herramientas, los límites de tiempo de ejecución y las notas de compatibilidad. Es posible que el control de acceso deba distinguir entre permitir una llamada de modelo y permitir que esa llamada inicie un contenedor.

El tercer grupo son los equipos de finanzas y operaciones que gestionan el gasto en IA. Los análisis de uso que se detienen en los tokens pasarán por alto una clase cada vez mayor de costos de infraestructura de agentes. Un útil panel de análisis de uso de API de IA debería mostrar si un pico se produjo por la elección del modelo, el volumen de tokens, el tiempo de ejecución de la zona de pruebas o un cambio en el diseño del flujo de trabajo que provocó llamadas de herramientas adicionales.

Lo que sigue siendo incierto

La versión beta deja abiertas varias preguntas prácticas. OpenRouter dice que el uso de Files API se incluye con la herramienta Shell durante la versión beta, pero el precio de los archivos a largo plazo, las reglas de retención y los límites operativos aún pueden ser importantes para las cargas de trabajo de producción. Los desarrolladores también deberán probar qué modelos funcionan de manera confiable con la herramienta Shell en todas las rutas de compatibilidad de API admitidas.

La seguridad es otra cuestión de implementación no resuelta para los compradores. OpenRouter describe que los comandos se ejecutan en contenedores Linux alojados aislados, pero las empresas seguirán preguntando sobre el acceso a la red, la instalación de paquetes, la persistencia de archivos, los registros de auditoría y el manejo de datos antes de enviar cargas de trabajo confidenciales a través de un entorno de ejecución alojado.

Sin embargo, la dirección más amplia es clara: las puertas de enlace están absorbiendo una mayor parte del tiempo de ejecución del agente. El enrutamiento modelo solía significar elegir dónde se enviaba un mensaje. Ahora incluye cada vez más semántica de herramientas, estado de archivos, política de ejecución y medición sin token. La versión beta del shell de OpenRouter es un marcador útil porque asigna un precio claro a una capacidad que muchos creadores de agentes han tratado como infraestructura en segundo plano. Una vez que el tiempo de ejecución aparece en la factura, pasa a formar parte de la arquitectura del producto.