Auto, TokenLab Verified ou Official : choisir un niveau de livraison

Lorsque nous avons constaté un itinéraire inattendu, le nom du modèle n'était pas l'indice utile ; c'était le niveau de livraison. L'itinéraire qui traite une requête peut modifier l'éligibilité au prix, même lorsque le modèle logique reste le même. C'est en raison de cette inadéquation que nous traitons le niveau de livraison comme une décision de routage, et non comme un badge de qualité. Cela est important lorsque l'éligibilité au prix et le routage doivent être explicites. Cela importe beaucoup moins lorsque votre politique par défaut correspond déjà à vos objectifs de risque et de coût.

Points clés à retenir

• Une requête peut être traitée via un itinéraire official ou un itinéraire verified. Le choix est enregistré par requête sous le nom resolvedDeliveryTier (verified ou official, null si l'enregistrement est antérieur à cette fonctionnalité).
• auto est la politique par défaut, et non un troisième type d'itinéraire. Elle conserve les chemins accessibles et estime le montant maximum que la requête peut coûter avant l'envoi.
• L'héritage de la politique au niveau de l'espace de travail (workspace) et de la clé API est la configuration normale. Lors de la lecture de production du 11/09/2026, 5 536 espaces de travail avaient une politique Auto explicite, 217 héritaient de la valeur par défaut du système, et les 4 134 clés API héritaient toutes de leur espace de travail. Une lecture ultérieure cette même semaine a montré 219 héritages. Le nombre explicite est resté stable car ces espaces de travail hérités étaient des comptes nouvellement créés qui n'avaient pas encore défini de politique. Ces chiffres proviennent de la lecture du lancement de TokenLab 2.0 enregistrée dans les notes de répétition de version interne, observée le 11/09/2026 ; traitez-les comme une lecture de production interne, et non comme un benchmark public.
• L'éligibilité aux prix Official nécessite une correspondance exacte avec un itinéraire Official. La livraison Verified reste disponible lorsqu'aucun itinéraire Official ne correspond.
• Vous pouvez remplacer le choix de livraison par requête avec l'en-tête X-TokenLab-Delivery-Policy. Une valeur par défaut au niveau de l'espace de travail couvre le cas général.

Ce que sont réellement les trois options de niveau de livraison

Les canaux déclarent les niveaux de livraison comme VERIFIED et OFFICIAL. Seuls les canaux disposant d'un niveau de livraison public actif peuvent être liés à une liaison de modèle d'organisation. Un espace de travail peut lier un modèle logique à un canal spécifique. Cette liaison est rejetée à moins que le canal ne soit actif, non supprimé et ne déclare un niveau de livraison public actif. Un itinéraire pour le modèle sur ce canal doit également être activé.

Official signifie que l'itinéraire est servi par le chemin du fournisseur officiel, tandis que Verified signifie un chemin vérifié par TokenLab. Auto est la politique qui permet au routeur de choisir parmi les itinéraires accessibles ; lorsque nous inspectons une requête après l'envoi, resolvedDeliveryTier nous indique si elle a été traitée par verified ou official. Ce champ est null lorsque l'enregistrement est antérieur à la fonctionnalité.

Ce qui change lorsque vous choisissez un niveau de livraison

Choisir un niveau modifie l'éligibilité au prix, les enregistrements par requête et l'estimation que vous voyez avant l'envoi. La tarification peut être ajustée par niveau de livraison via des règles d'ajustement de prix de livraison au niveau de l'organisation, et cet ajustement est normalisé et validé avant d'être appliqué. Après le lancement, les choix explicites Verified ou Official continuent de s'appliquer, tandis que les requêtes antérieures à la politique utilisent Auto par défaut.

Auto estime le montant maximum pour la requête plutôt qu'un prix unique. Plus d'un itinéraire peut être accessible, mais Auto conserve tous les itinéraires accessibles et ne supprime pas l'itinéraire le plus coûteux pour rendre l'estimation plus basse. Dans notre pipeline, nous vérifions l'estimation avant l'envoi et resolvedDeliveryTier après la finalisation.

Option	Ce qu'elle optimise	Quand la choisir	Ce que vous pouvez vérifier ensuite
Auto	Itinéraires accessibles et estimation du coût maximum	Vous voulez que la politique par défaut choisisse parmi les itinéraires accessibles	resolvedDeliveryTier indique l'itinéraire qui a servi la requête
TokenLab Verified	Accès aux chemins vérifiés par TokenLab lorsque Official n'est pas disponible ou requis	Vous avez besoin d'un itinéraire vérifié, ou aucun itinéraire Official ne correspond	resolvedDeliveryTier indique verified
Official	Correspondance exacte avec l'itinéraire Official pour l'éligibilité au prix officiel	Vous avez besoin de l'éligibilité au prix officiel	resolvedDeliveryTier indique official

Comment les équipes configurent généralement la politique de niveau de livraison

Les chiffres de lecture de cette section proviennent de la lecture du lancement de TokenLab 2.0 enregistrée dans les notes de répétition de version interne, observée le 11/09/2026 ; traitez-les comme une lecture de production interne, et non comme un benchmark public.

La configuration par défaut est l'héritage, et non une procédure par requête. Lors de la lecture de production du 11/09/2026, nous avons observé 5 536 espaces de travail avec une politique Auto explicite, tandis que 217 autres héritaient de la valeur par défaut du système. Les 4 134 clés API héritaient toutes de leur espace de travail, donc les anciens clients n'avaient pas besoin d'un nouvel en-tête. Ce modèle est logique car la politique de l'espace de travail couvre le cas courant, et le remplacement par requête reste l'exception.

Une lecture ultérieure la même semaine a montré 5 536 choix explicites et 219 héritages, le nombre explicite restant stable et le nombre hérité passant de 217 à 219. Ces espaces de travail hérités étaient des comptes nouvellement créés qui n'avaient pas encore défini de politique, donc ces chiffres évoluent à mesure que les comptes sont créés. La définition d'une politique n'a jamais été une migration, aucun remplissage en masse de la politique d'espace de travail ou de clé n'a été effectué au lancement, et les clés héritées n'ont nécessité aucun changement côté client.

Les règles de liaison s'appliquent toujours lorsqu'un espace de travail lie un modèle logique à un canal spécifique. La liaison est rejetée à moins que le canal ne soit actif, non supprimé et ne déclare un niveau de livraison public actif. Un itinéraire activé pour le modèle sur ce canal doit également exister. Un canal ne peut être lié à une liaison de modèle d'organisation que si sa déclaration de registre est ACTIVE et que son propre enregistrement est ACTIF sans horodatage de suppression ; un canal suspendu ou retiré ne peut donc pas être épinglé.

Épingler un modèle logique à un canal spécifique est la façon dont un espace de travail exprime "toujours Official" pour ce modèle sans toucher aux requêtes individuelles. Les requêtes antérieures à la politique de livraison utilisent Auto par défaut. Aucun changement côté client n'a été requis, et aucun remplissage en masse de la politique d'espace de travail ou de clé n'a été effectué au lancement. Pour le contexte au niveau du modèle, associez ceci au guide du centre de données des modèles.

Comment vérifier quel niveau de livraison a servi une requête

Lorsqu'une requête se termine, lisez resolvedDeliveryTier dans l'enregistrement de la requête ; la valeur est verified ou official, et une valeur nulle signifie que l'enregistrement est antérieur au champ. La requête transporte également requestedDeliveryPolicy, qui enregistre ce que l'appelant a demandé et est nullable lorsque la valeur par défaut de l'espace de travail a été appliquée.

Pour remplacer le niveau pour une requête, ajoutez l'en-tête X-TokenLab-Delivery-Policy ; les valeurs acceptées sont auto, verified et official. Voici l'en-tête seul :

# Ajoutez cet en-tête à la requête Claude Sonnet 5
X-TokenLab-Delivery-Policy: verified

Par exemple, cet appel cURL cible Claude Sonnet 5 et demande 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"}]}'

Après l'appel, l'enregistrement de la requête pour cet appel contient :

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

L'enregistrement de la requête inclut également des champs d'utilisation, et le guide de la console de requête montre où cet enregistrement se trouve et les noms des champs actuels pour l'utilisation.

Si le niveau demandé n'a aucun itinéraire activé, la passerelle répond avec delivery_tier_unavailable et ne bascule pas silencieusement vers un autre niveau. La console de requête montre où cet enregistrement se trouve, et le guide de la console de requête explique comment le trouver. Nous commençons par là lorsqu'un prix ou un itinéraire semble inattendu, car la console et les preuves de requête peuvent montrer quel niveau a servi le trafic.

Quand Auto choisit un niveau de livraison que vous n'attendiez pas

Lorsque Auto choisit un niveau que vous n'attendiez pas, lisez resolvedDeliveryTier sur la requête et comparez-le avec les canaux que votre organisation a liés. Ensuite, liez le modèle au canal souhaité ou remplacez le niveau pour cette requête. Cela permet de garder la politique par défaut simple tout en vous donnant un moyen concret de corriger un itinéraire surprenant.

Limitations

Les chiffres ici sont une lecture ponctuelle du 11/09/2026, et ils vont dériver. La disponibilité du niveau de livraison dépend des itinéraires actifs pour votre modèle et votre organisation. Une liaison d'espace de travail peut être rejetée si le canal est inactif, supprimé, manque d'un niveau de livraison public actif ou n'a aucun itinéraire activé pour le modèle. L'ajustement de prix par niveau de livraison dépend de vos propres règles d'organisation. Nous ne pouvons pas fournir de comparaison universelle car les données sources n'en fournissent pas. La décision de livraison est résolue après la sélection de l'itinéraire, donc le niveau que vous obtenez dépend des itinéraires activés pour votre organisation à ce moment-là.

FAQ

Que choisit réellement Auto ?

Auto est la politique par défaut, et non un troisième type d'itinéraire. Elle conserve les chemins accessibles et estime le montant maximum que la requête peut coûter avant l'envoi. Les requêtes antérieures à la politique utilisent Auto par défaut. Après l'envoi, resolvedDeliveryTier enregistre si la requête a été traitée via un itinéraire verified ou official.

Pourquoi un itinéraire Verified coûterait-il plus cher qu'un itinéraire Official ?

La tarification peut être ajustée par niveau de livraison via des règles d'ajustement de prix de livraison au niveau de l'organisation. L'ajustement est normalisé et validé avant d'être appliqué. La différence dépend donc de votre configuration, et vous devriez vérifier le prix affiché avant l'envoi.

Dois-je définir un niveau de livraison sur chaque requête ?

Non. L'héritage de la politique au niveau de l'espace de travail et de la clé API est la configuration normale. Lors de la lecture de production du 11/09/2026, 5 536 espaces de travail avaient une politique Auto explicite, 217 héritaient de la valeur par défaut du système, et les 4 134 clés API héritaient toutes de leur espace de travail. Le nombre hérité est passé à 219 plus tard cette semaine-là à mesure que de nouveaux comptes étaient créés. Ces chiffres proviennent de la lecture du lancement de TokenLab 2.0 enregistrée dans les notes de répétition de version interne, observée le 11/09/2026 ; traitez-les comme une lecture de production interne, et non comme un benchmark public. Vous pouvez remplacer le choix de livraison par requête, mais une valeur par défaut au niveau de l'espace de travail couvre le cas général.

Comment savoir quel niveau a servi une requête terminée ?

Lisez resolvedDeliveryTier dans l'enregistrement de la requête. La valeur est verified ou official, et elle est null lorsque l'enregistrement est antérieur au champ. requestedDeliveryPolicy montre ce que l'appelant a demandé, et est nullable lorsque la valeur par défaut de l'espace de travail a été appliquée. La console de requête et le guide de la console de requête montrent où cet enregistrement se trouve.

Que se passe-t-il si je demande un niveau sans itinéraire activé ?

La passerelle répond avec delivery_tier_unavailable. Elle ne bascule pas silencieusement vers un autre niveau. Lisez l'enregistrement de la requête, puis activez un itinéraire correspondant ou modifiez la politique demandée.

Créez une clé API et comparez le niveau que vous obtenez avec le niveau attendu ; le guide de la console de requête montre où cet enregistrement se trouve.