La capa de decisión obtiene su lista de precios: cuatro SKUs en una semana, desde $0.10 por millón de tokens
Conclusiones clave
- Cuatro SKUs de modelos de decisión se lanzaron en una sola semana (11–13 de noviembre de 2026) de Google, Perplexity, HeyGen y Hark — una categoría que diez días antes consistía en 21 modelos de 13 fabricantes listados atrás de la Decisions API de OpenRouter sin un solo ancla de precio de primera parte.
- Gemini Decision 1 fija el precio de las elecciones acotadas a $0.10 por 1M de tokens de entrada con $0 facturado en salida, puntuando hasta 1,000 preguntas de sí/no, de opción múltiple y de rúbrica en una sola pasada, con 150–250 ms end-to-end — casi 5 veces más barato según la propia batería de benchmarks compartida de Google que Gemini 3.5 Flash-Lite con la Interactions API.
- Perplexity Decider v1.3 (26B, sobre la base Qwen3.8-27B) y Flash v1.3 (5B) son los primeros pesos publicados de la categoría, liberados bajo Apache-2.0 en Hugging Face — la vía de autoalojamiento ya existe para la capa que enruta, vigila y califica dentro del bucle de un agente.
- Los marcadores de honestidad proceden de los propios proveedores: la documentación de HeyGen describe
confidencecomo «una propiedad de la distribución devuelta, no una probabilidad calibrada», y Perplexity indica a los usuarios ajustar los umbrales de decisión sobre su propio tráfico etiquetado en lugar de fiarse de la temperatura de fábrica. - La política no figura en la lista de precios: qué decisiones pueden deferirse a un clasificador y qué ocurre cuando el vigilante barato se equivoca siguen siendo decisiones de arquitectura — la segunda y la tercera fila del marco de cinco decisiones, no del proveedor.
Este artículo construye sobre Five Decisions That Determine Whether Your AI Agent Ships, que ordenó las decisiones arquitectónicas detrás de los agentes de producción. Su tercera decisión — qué modelo hace qué — ganó un catálogo el 16 de octubre, cuando OpenRouter listó 21 modelos de decisión de 13 fabricantes detrás de una única Decisions API. En la semana del 11–13 de noviembre, el catálogo cruzó el umbral que la presencia en un catálogo no cruza: tres proveedores lanzaron SKUs de primera parte con precio y un cuarto industrializó el handoff junto a ellos. La capa de decidir-antes-de-actuar ya no es un patrón que se ensambla con piezas. Es una compra.
Qué es un modelo de decisión, en un párrafo
La definición de Perplexity es la más limpia: un modelo de decisión es un clasificador de propósito general. Se le entrega una entrada — un estado, más imágenes opcionales — y un conjunto de preguntas con nombre, cada una con sus respuestas posibles, y devuelve una distribución de probabilidad para cada pregunta en una única pasada directa. Sin generación de respuestas token a token, sin texto libre, sin una cadena de razonamiento de 30 segundos para decidir si un ticket de soporte va a facturación o a integración. Los tipos de pregunta son los mismos entre proveedores: sí/no (una probabilidad de verdadero), opción múltiple (2–255 opciones con una probabilidad normalizada para cada una) y puntuación de rúbrica ordenada. Perplexity acredita el linaje directamente: Decider está inspirado en Jev de TypeSafe AI, el modelo System One no-LLM que analizamos en TypeSafe Jev and the Third Layer of the Agent Model Stack. Cuando el segundo entrante de la categoría nombra el patrón del primer observador, la categoría comparte una idea, no solo una palabra de marketing.
Los cuatro SKUs
La oferta de la semana, comparada según las dimensiones que un comprador cotiza:
| SKU | Fabricante, fecha | Acceso | Escala | Velocidad y costo | Marcador de honestidad |
|---|---|---|---|---|---|
| Gemini Decision 1 + Decisions API | Google, 11 nov | API (integraciones OpenRouter, LangChain, LiteLLM, Vercel) | Hasta 1,000 preguntas por llamada sobre texto, imágenes, audio, video, PDF (entrada de 256K tokens) | 150–250 ms end-to-end; tarifa plana de 1→100 preguntas; $0.10/1M de entrada, $0 de salida | Afirma un ~5x más barato contra la propia batería de benchmarks compartida de Google |
| Decider v1.3 / Flash v1.3 | Perplexity, 12 nov | Pesos Apache-2.0, API MaaS, OpenRouter | 26B (sobre la base Qwen3.8-27B) y una destilación de 5B; 1–255 opciones por pregunta | Vía rápida 1.7–1.9x más rápida (modo separate), 9–18x (modo isolated) | Honestidad de umbrales: ajústelos sobre su propio tráfico; el repositorio de pesos está cerrado por acceso pese a la licencia Apache |
| HeyGen Decision 1 (+ vista previa Turbo) | HeyGen, 13 nov | API síncrona | 1–400 preguntas con nombre; hasta 4 imágenes + 1 video (Turbo: 100 imágenes, 10 videos) | Respuesta síncrona, output_tokens: 0 siempre; sin precio publicado en la página de docs |
Docs: la confianza es «una propiedad de la distribución devuelta, no una probabilidad calibrada» |
| Hark Handoff² | Hark, 12 nov | Hark Pro (agente computer-use) | 82% en un benchmark interno de navegación de 478 tareas y 238 sitios, frente al 73% anterior | Modelo 46% más rápido, ~2x end-to-end | Benchmark interno reportado por el propio proveedor, no una evaluación abierta |
La profundidad de la categoría se ve en lo que cada proveedor apostó. Google apostó por la amplitud y el lote: una entrada multimodal, hasta 1,000 preguntas, con una latencia casi plana de 1 a 100 preguntas por solicitud, con la entrada facturada una sola vez sin importar el número de preguntas. Perplexity apostó por la propiedad: pesos publicados significan que la capa de enrutamiento, moderación y calificación puede vivir en hardware controlado por el comprador, con un nuevo tipo locate que extrae fragmentos textuales con desplazamientos de caracteres — clasificación y extracción en una misma solicitud. HeyGen apostó por la vía multimedia: texto, JSON, cuatro imágenes y un video de fotogramas muestreados en una sola llamada síncrona, con una vista previa Turbo que empuja a 100 imágenes y 10 videos. Hark apostó por la primitiva adyacente: el handoff — el instante en que el trabajo de un agente de navegador se convierte en trabajo humano — industrializado y medido 2x más rápido contra su propia v1. Los despliegues internos de Google insinúan dónde cae esto en producción: Gemini Notebook usa la Decisions API como enrutador de modelos en tiempo real, reportando hasta un 40% menos de latencia en consultas cotidianas, y Google Search la usa como capa de seguridad para detectar comportamiento adversarial contra herramientas MCP.
Cuatro SKUs de modelos de decisión comparados por acceso, escala, velocidad y el marcador de honestidad que cada proveedor publica contra sí mismo. El patrón que un comprador debe retener: cada fila de velocidad y precio es la medición del propio proveedor.
Por qué la elección acotada se preciosifica así
La economía es estructural, no promocional. Una llamada generativa paga tokens de salida, y una decisión de enrutamiento o de moderación paga token a token para producir el artefacto menos útil de la tubería: prosa libre que termina en una de tres palabras. Un modelo de decisión lo reemplaza con una lectura de clasificación — una cabeza lineal entrenada sobre los tokens de opción predefinidos — por eso la Decisions API factura $0 por salida, factura la entrada compartida una sola vez por solicitud sin importar cuántas preguntas viajen en ella, y se salta por completo los cargos variables por tokens de pensamiento. Las notas de arquitectura de Perplexity explican la segunda razón: los modelos 1.3 leen bidireccionalmente y responden cada pregunta desde un estado compartido en una pasada, y la tarjeta de HF documenta una vía rápida que empaqueta muchas secuencias por pasada directa, 1.7–1.9x más rápida en modo separate y 9–18x más rápida en modo isolated. Para el comprador autoalojado, la aritmética es concreta: 49 GiB de pesos BF16 caben en el sobre de memoria de una GPU de 80 GB, y el Ornn Compute Price Index fijó una H100 SXM a $3.29 por hora de GPU el 13 de noviembre — una capa de enrutamiento, calificación y moderación a una tarifa horaria que una sola llamada generativa de modelo frontera ya superaba a diario. Ese es el colapso de precio del que realmente trata esta semana: los cinco vectores de gestión de costos de inferencia extendidos a las decisiones alrededor de las llamadas generativas.
Lo que la lista de precios no incluye
Cuatro cosas que los SKUs no venden, cada una visible en la propia documentación de los proveedores.
La confianza no es calibración. La documentación de HeyGen es la más explícita del sector al respecto: la confianza es «una propiedad de la distribución devuelta, no una probabilidad calibrada». Google exporta una puntuación de confianza de 0–1 en cada respuesta; eso indica dónde termina el distribuidor, no dónde se sitúa su umbral de corrección. Los umbrales son problema de sus datos. La sección Getting Started de Perplexity lo dice sin rodeos — las frecuencias de etiquetas y los costos de falsos positivos frente a falsos negativos varían entre aplicaciones, de modo que ajuste los umbrales sobre un conjunto pequeño y representativo de desarrollo etiquetado. La misma honestidad aparece en la tarjeta de HF: «una única temperatura no puede ser correcta para cada tarea, y los umbrales por tarea suelen ser mejores». Las preguntas no pueden depender entre sí. La documentación de la API de HeyGen señala que la respuesta de una pregunta no se convierte en entrada de otra dentro de la misma solicitud — las decisiones dependientes necesitan llamadas secuenciales, y ahí la latencia deja de parecer gratuita. Perplexity documenta el mismo límite desde el otro lado: en el modo separate por defecto las preguntas jamás se ven entre sí, y el modo isolated de estado compartido cambia esa independencia por costo, desplazando entre un 1.5–2.2% de las respuestas principales. Las afirmaciones de latencia y de contexto tienen alcances. Los 150–250 ms de Google se mantienen en contextos de hasta 16K tokens — la entrada multimodal de 256K tokens es un sobre distinto — y el 2x de Hark es una cifra reportada por el propio proveedor contra su v1. Ninguna de estas cautelas argumenta en contra de la categoría. Argumentan pilotar con su propio tráfico etiquetado y tratar los valores de confianza como promesas sin calibrar hasta que sus umbrales digan otra cosa — la misma disciplina de honestidad que aplicamos a los precios de impresión de GPU, donde el índice mismo se reprecificó entre lecturas.
Lo que sigue siendo suyo: la capa de política
Un modelo de decisión puede absorber sus llamadas de clasificación, enrutamiento, vigilancia y calificación. No puede absorber las dos decisiones que las vuelven seguras. Primera: qué decisiones pueden deferirse en absoluto a un clasificador — una elección de cola de tickets de soporte puede enrutarse sola; una escritura de precio de proveedor en NetSuite no. Segunda: qué ocurre cuando el vigilante barato se equivoca — la propia respuesta de diseño de Google es enrutar los casos ambiguos por confianza hacia un revisión de respaldo o humana, pero qué casos son ambiguos y con qué frecuencia revisa el humano es su política de escalamiento. En el marco de cinco decisiones esto es la Decisión 3 extendida hacia abajo: enrutamiento, vigilancia y evaluación del kill-switch se vuelven componentes comprables en lugar de código a medida, mientras la capa de bucle que hace cumplir el criterio en el runtime conserva las aprobaciones que siempre poseyó. Lo que la lista de precios cambia es el costo de la capa de vigilancia. Lo que no cambia es quién la firma.
Un despliegue representativo
Un distribuidor industrial mediano que opera NetSuite, BigCommerce y tres catálogos de proveedores quería que su agente de cotización trabajara las 24 horas sin que un humano leyera cada borrador. La capa de decisión estructuró la división: un modelo frontera planifica la respuesta del RFQ y redacta la cotización; un nivel de modelo de decisión vigila todo lo demás. Cada RFQ entrante se califica por completitud y riesgo en una sola solicitud antes de gastar una llamada generativa; las respuestas de proveedores se clasifican contra los renglones de la cotización; cada cotización redactada recibe una verificación de política puntuada por confianza, con todo lo que queda bajo el umbral enrutado a un escritorio humano en lugar de a NetSuite. La capa de vigilancia cuesta $0.10 por millón de tokens en el SKU con precio de Google — la clase de factura de elección acotada que reemplaza unas cinco llamadas generativas de Flash-Lite por decisión según la comparación de benchmark del propio Google — y corre a una latencia que el revisor humano nunca espera. El tiempo de ciclo de cotización bajó de tres días a menos de cuatro horas con un humano aprobando cada escritura; el resultado es la capacidad del escritorio, no su plantilla.
Ese es el patrón: compre las elecciones acotadas, ponga precio a la confianza con honestidad, conserve la política.
Lecturas relacionadas
- Five Decisions That Determine Whether Your AI Agent Ships — el marco padre que este artículo extiende: su actualización del 16 de octubre catalogó la capa de decidir-y-actuar, y su Decisión 3 es el renglón que estos SKUs ponen precio
- TypeSafe Jev and the Third Layer of the Agent Model Stack — el patrón System One que Perplexity nombra como inspiración de Decider, leído el mes anterior a la preciosificación de la categoría
- Inference Economics: Why Always-On Production Agents Are Now Affordable — los vectores de costo que la lista de precios de esta semana extiende a las decisiones alrededor de las llamadas generativas
- Inference Procurement: Six Cost Vectors — los rieles de GPU bajo una capa de decisión autoalojada, y la regla de cotizar rangos que también aplica a estos precios de SKU
Descubrimiento de una semana. Usted recibe un inventario de sistemas, un mapa de flujos y un alcance fijo — lo construya con nosotros o no.
¿Quieres esto construido para tus sistemas?
Cada documento aquí viene de trabajo real de producción. Si tienes un sistema objetivo y un flujo en mente, podemos definir un proyecto en una semana.
Solicitar un proyectoDescubrimiento de una semana. Obtienes un inventario de sistemas, mapa de flujos y alcance fijo — decidas o no construir con nosotros.