Auto, TokenLab Verified u Official: Cómo elegir un nivel de entrega

Cuando observamos una ruta inesperada, el nombre del modelo no fue la pista útil; el nivel de entrega sí lo fue. La ruta que atiende una solicitud puede cambiar la elegibilidad de precio incluso cuando el modelo lógico sigue siendo el mismo. Esa discrepancia es la razón por la que tratamos el nivel de entrega como una decisión de enrutamiento, no como una insignia de calidad. Es importante cuando la elegibilidad de precio y el enrutamiento deben ser explícitos. Es mucho menos importante cuando su política predeterminada ya coincide con sus objetivos de riesgo y costo.

Puntos clave

• Una solicitud puede ser atendida a través de una ruta official o una ruta verified. La elección se registra por solicitud como resolvedDeliveryTier (verified u official, nulo cuando el registro es anterior a esta función).
• auto es la política predeterminada, no un tercer tipo de ruta. Mantiene las rutas alcanzables y estima la cantidad máxima que puede costar la solicitud antes del envío.
• La herencia de políticas de Workspace y API-key es la configuración normal. En la lectura de producción del 11-09-2026, 5,536 workspaces tenían una política Auto explícita, 217 heredaron la predeterminada del sistema y las 4,134 API keys heredaron de su workspace. Una lectura posterior esa misma semana mostró 219 heredadas. El conteo explícito se mantuvo estable porque esos workspaces heredados eran cuentas recién creadas que aún no habían establecido una política. Estas cifras provienen de la lectura del lanzamiento de TokenLab 2.0 registrada en las notas internas de ensayo de lanzamiento, observada el 11-09-2026; trátelas como una lectura de producción interna, no como un benchmark público.
• La elegibilidad de precios Official requiere una coincidencia exacta con la ruta Official. La entrega Verified sigue estando disponible cuando no coincide ninguna ruta Official.
• Puede anular la elección de entrega por solicitud con el encabezado X-TokenLab-Delivery-Policy. Un valor predeterminado de workspace cubre el caso común.

Qué son realmente las tres opciones de nivel de entrega

Los canales declaran los niveles de entrega como VERIFIED y OFFICIAL. Solo los canales con un nivel de entrega público activo pueden vincularse a una vinculación de modelo de organización. Un workspace puede vincular un modelo lógico a un canal específico. Esa vinculación se rechaza a menos que el canal esté activo, no eliminado y declare un nivel de entrega público activo. También debe estar habilitada una ruta para el modelo en ese canal.

Official significa que la ruta es atendida por la ruta oficial del proveedor, mientras que Verified significa una ruta verificada por TokenLab. Auto es la política que permite al enrutador elegir entre las rutas alcanzables; cuando inspeccionamos una solicitud después del envío, resolvedDeliveryTier nos indica si fue atendida por verified u official. Ese campo es nulo cuando el registro es anterior a la función.

Qué cambia al elegir un nivel de entrega

Elegir un nivel cambia la elegibilidad de precio, los registros por solicitud y la estimación que ve antes del envío. Los precios pueden ajustarse por nivel de entrega a través de reglas de ajuste de precio de entrega a nivel de organización, y ese ajuste se normaliza y valida antes de aplicarse. Después del lanzamiento, las elecciones explícitas de Verified u Official siguen aplicándose, mientras que las solicitudes anteriores a la política utilizan Auto por defecto.

Auto estima la cantidad máxima para la solicitud en lugar de un precio único. Puede haber más de una ruta alcanzable, pero Auto mantiene todas las rutas alcanzables y no descarta la ruta más cara para que la estimación parezca más baja. En nuestro pipeline, verificamos la estimación antes del envío y resolvedDeliveryTier después de la finalización.

Opción	Qué optimiza	Cuándo elegirla	Qué puede verificar después
Auto	Rutas alcanzables y estimación de costo máximo	Desea que la política predeterminada elija entre las rutas alcanzables	resolvedDeliveryTier muestra la ruta que atendió la solicitud
TokenLab Verified	Acceso a rutas verificadas por TokenLab cuando Official no está disponible o no es necesario	Necesita una ruta verificada, o no coincide ninguna ruta Official	resolvedDeliveryTier muestra verified
Official	Coincidencia exacta de ruta Official para elegibilidad de precios oficiales	Necesita elegibilidad de precios oficiales	resolvedDeliveryTier muestra official

Cómo suelen configurar los equipos la política de nivel de entrega

Los números de lectura en esta sección provienen de la lectura del lanzamiento de TokenLab 2.0 registrada en las notas internas de ensayo de lanzamiento, observada el 11-09-2026; trátelas como una lectura de producción interna, no como un benchmark público.

La configuración predeterminada es la herencia, no el procedimiento por solicitud. En la lectura de producción del 11-09-2026, vimos 5,536 workspaces con una política Auto explícita, mientras que otros 217 heredaron la predeterminada del sistema. Todas las 4,134 API keys heredaron de su workspace, por lo que los clientes antiguos no necesitaron un nuevo encabezado. Ese patrón tiene sentido porque la política de workspace cubre el caso común, y la anulación por solicitud sigue siendo la excepción.

Una lectura posterior esa misma semana mostró 5,536 explícitas y 219 heredadas, mientras que el conteo explícito se mantuvo estable y el heredado pasó de 217 a 219. Esos workspaces heredados eran cuentas recién creadas que aún no habían establecido una política, por lo que estos conteos se mueven a medida que se crean cuentas. Establecer una política nunca fue una migración, no se ejecutó ningún relleno masivo de políticas de workspace o clave en el lanzamiento, y las claves heredadas no necesitaron cambios en el cliente.

Las reglas de vinculación siguen aplicándose cuando un workspace vincula un modelo lógico a un canal específico. La vinculación se rechaza a menos que el canal esté activo, no eliminado y declare un nivel de entrega público activo. También debe existir una ruta habilitada para el modelo en ese canal. Un canal solo puede vincularse a una vinculación de modelo de organización mientras su declaración de Registro sea ACTIVE y su propio registro sea ACTIVE sin marca de tiempo de eliminación, por lo que un canal pausado o retirado no puede ser fijado.

Fijar un modelo lógico a un canal específico es cómo un workspace expresa "siempre Official" para este modelo sin tocar solicitudes individuales. Las solicitudes anteriores a la política de entrega utilizan Auto por defecto. No se requirió ningún cambio en el cliente, y no se realizó ningún relleno masivo de políticas de workspace o clave en el lanzamiento. Para obtener contexto a nivel de modelo, combine esto con la guía del centro de datos de modelos.

Cómo comprobar qué nivel de entrega atendió una solicitud

Cuando finaliza una solicitud, lea resolvedDeliveryTier en el registro de la solicitud; el valor es verified u official, y un valor nulo significa que el registro es anterior al campo. La solicitud también lleva requestedDeliveryPolicy, que registra lo que pidió el llamador y es anulable cuando se aplicó el valor predeterminado del workspace.

Para anular el nivel para una solicitud, agregue el encabezado X-TokenLab-Delivery-Policy; los valores aceptados son auto, verified y official. Aquí está el encabezado por sí solo:

# Agregue este encabezado a la solicitud de Claude Sonnet 5
X-TokenLab-Delivery-Policy: verified

Por ejemplo, esta llamada cURL apunta a Claude Sonnet 5 y solicita official:

curl https://api.tokenlab.sh/v1/chat/completions -H "Authorization: Bearer $TOKENLAB_API_KEY" -H "Content-Type: application/json" -H "X-TokenLab-Delivery-Policy: official" -d '{"model":"Claude Sonnet 5","messages":[{"role":"user","content":"Hello"}]}'

Después de la llamada, el registro de la solicitud para esa llamada lleva:

{
  "requestedDeliveryPolicy": "official",
  "resolvedDeliveryTier": "official"
}

El registro de la solicitud también incluye campos de uso, y la guía de la Consola de Solicitudes muestra dónde vive ese registro y los nombres actuales de los campos para el uso.

Si el nivel solicitado no tiene ninguna ruta habilitada, la puerta de enlace responde con delivery_tier_unavailable y no recurre silenciosamente a otro nivel. La consola de solicitudes muestra dónde vive ese registro, y la guía de la Consola de Solicitudes explica cómo encontrarlo. Comenzamos por ahí cuando un precio o ruta parece inesperado, porque la consola y la evidencia de la solicitud pueden mostrar qué nivel atendió el tráfico.

Cuando Auto elige un nivel de entrega que no esperaba

Cuando Auto elige un nivel que no esperaba, lea resolvedDeliveryTier en la solicitud y compárelo con los canales que su organización ha vinculado. Luego, vincule el modelo al canal que desea o anule el nivel para esa solicitud. Esto mantiene la política predeterminada simple mientras le brinda una forma concreta de corregir una ruta sorprendente.

Limitaciones

Los números aquí son una lectura puntual del 11-09-2026, y cambiarán. La disponibilidad del nivel de entrega depende de qué rutas estén activas para su modelo y organización. Una vinculación de workspace puede ser rechazada si el canal está inactivo, eliminado, carece de un nivel de entrega público activo o no tiene ninguna ruta habilitada para el modelo. El ajuste de precio por nivel de entrega depende de las reglas de su propia organización. No podemos dar una comparación universal porque los datos de origen no proporcionan una. La decisión de entrega se resuelve después de la selección de ruta, por lo que el nivel que obtiene depende de qué rutas estén habilitadas para su organización en ese momento.

Preguntas frecuentes

¿Qué elige realmente Auto?

Auto es la política predeterminada, no un tercer tipo de ruta. Mantiene las rutas alcanzables y estima la cantidad máxima que puede costar la solicitud antes del envío. Las solicitudes anteriores a la política utilizan Auto por defecto. Después del envío, resolvedDeliveryTier registra si la solicitud fue atendida a través de una ruta verified u official.

¿Por qué una ruta Verified costaría más que una ruta Official?

Los precios pueden ajustarse por nivel de entrega a través de reglas de ajuste de precio de entrega a nivel de organización. El ajuste se normaliza y valida antes de aplicarse. Por lo tanto, la diferencia depende de su configuración, y debe verificar el precio que se muestra antes del envío.

¿Tengo que establecer un nivel de entrega en cada solicitud?

No. La herencia de políticas de Workspace y API-key es la configuración normal. En la lectura de producción del 11-09-2026, 5,536 workspaces tenían una política Auto explícita, 217 heredaron la predeterminada del sistema y las 4,134 API keys heredaron de su workspace. El conteo heredado pasó a 219 más tarde esa semana a medida que se creaban nuevas cuentas. Estas cifras provienen de la lectura del lanzamiento de TokenLab 2.0 registrada en las notas internas de ensayo de lanzamiento, observada el 11-09-2026; trátelas como una lectura de producción interna, no como un benchmark público. Puede anular la elección de entrega por solicitud, pero un valor predeterminado de workspace cubre el caso común.

¿Cómo sé qué nivel atendió una solicitud finalizada?

Lea resolvedDeliveryTier en el registro de la solicitud. El valor es verified u official, y es nulo cuando el registro es anterior al campo. requestedDeliveryPolicy muestra lo que pidió el llamador, y es anulable cuando se aplicó el valor predeterminado del workspace. La consola de solicitudes y la guía de la Consola de Solicitudes muestran dónde vive ese registro.

¿Qué sucede si solicito un nivel sin ruta habilitada?

La puerta de enlace responde con delivery_tier_unavailable. No recurre silenciosamente a otro nivel. Lea el registro de la solicitud, luego habilite una ruta coincidente o cambie la política solicitada.

Cree una API key y compare el nivel que obtiene con el nivel que esperaba; la guía de la Consola de Solicitudes muestra dónde vive ese registro.