« Transparence » est un mot que tout le monde écrit sur sa page tarifs. Il ne veut rien dire tant qu'on n'a pas montré le mécanisme. Voici donc le nôtre, dans l'ordre où il s'exécute.

Une génération se déroule en trois temps

Quand vous lancez une génération, trois choses distinctes se produisent, et les confondre est la source de la plupart des mauvaises surprises sur les services concurrents.

On réserve. Avant d'appeler le fournisseur, Tukai estime ce que l'appel va coûter et gèle ce montant sur votre solde. Le gel n'est pas un prélèvement : c'est une ligne négative provisoire. Votre solde disponible baisse, votre solde réel n'a pas bougé.

On génère. L'appel part chez le fournisseur — OpenAI, Anthropic, Google, ou l'un des autres. Il répond, ou il échoue.

On règle. Si un résultat existe, la réservation est capturée : elle devient une dépense définitive, ajustée sur ce que l'appel a réellement consommé. S'il n'y a pas de résultat, la réservation est libérée et votre solde revient exactement où il était.

Capture et libération sont mutuellement exclusives, et chacune ne peut arriver qu'une seule fois par génération. Ce n'est pas une précaution de style : c'est ce qui rend impossible le cas où l'on vous débite deux fois, ou celui où l'on vous rembourse un montant qui n'a jamais été gelé.

Pourquoi un échec ne vous coûte rien

La conséquence directe du découpage ci-dessus : une génération qui échoue est remboursée sans que vous ayez à le demander, parce qu'il n'y a jamais eu de prélèvement à annuler. Il y avait un gel, et le gel tombe.

Ça paraît évident écrit comme ça. Ça ne l'est pas dans l'implémentation. Le cas difficile n'est pas l'échec propre — c'est celui où l'appel de règlement lui-même ne répond pas. La base de données a peut-être enregistré la capture et perdu sa réponse. Dans ce cas précis, libérer aveuglément reviendrait à rembourser une dépense bien réelle. Nous traitons donc ce cas comme incertain et non comme échoué : la réservation est conservée, l'opération est marquée en attente, et un balayage automatique tranche plus tard sur pièces. Ce qu'un humain ne peut pas prouver reste marqué pour un humain.

L'unité : 1 EDNT = 1 millime

Tukai compte en EDNT. La règle est fixe et n'a jamais bougé : 1 EDNT = 1 millime, donc 1000 EDNT = 1 TND. Ce n'est pas une monnaie de jeu dont le taux se négocie — c'est une unité de compte alignée sur le dinar, ce qui permet à un prix et à un crédit de partager la même échelle.

L'intérêt pratique : quand vous voyez qu'une opération a coûté 400 EDNT, vous savez immédiatement que c'est 0,400 TND. Aucune conversion à faire de tête, aucun taux à surveiller.

Le taux de change est figé à l'appel, pas à la facture

Les fournisseurs facturent en dollars. Il faut donc convertir, et c'est là que se cache le problème que la plupart des systèmes ne voient pas venir.

Si la conversion se faisait au moment de lire l'historique, alors tout l'historique changerait à chaque variation du dinar. Une génération de mars vous serait affichée à un prix en avril, à un autre en mai. Pire : la table des tarifs par modèle est modifiable — un administrateur qui corrige le prix d'un modèle réécrirait rétroactivement le coût de tous les appels passés sur ce modèle.

Nous figeons donc, à chaque appel, une photographie du barème et du taux de change utilisés. Cette photographie est stockée avec l'appel et n'est jamais recalculée. Un tarif corrigé demain n'a aucun effet sur ce qui a été facturé hier. C'est la seule façon d'avoir un historique qui veut encore dire quelque chose six mois plus tard.

On garde ce que le fournisseur a dit

Chaque appel conserve la réponse d'usage brute du fournisseur — le nombre de jetons d'entrée, de sortie, de cache, tel qu'il l'a déclaré, sans retraitement.

C'est du stockage qui ne sert à rien au quotidien, et nous le gardons quand même. La raison est simple : toute correction ultérieure de la formule de coût n'est rejouable qu'à partir de cette donnée-là. Le jour où l'on découvre qu'un calcul était faux sur une famille de modèles, la question n'est pas « comment corriger la formule » mais « sur quoi la recalculer ». Sans la déclaration d'origine, il n'y a rien à recalculer et l'erreur devient définitive.

Cette donnée sert aussi à un arbitrage moins agréable : quand deux sources se contredisent sur le même appel, nous ne choisissons pas et nous n'additionnons pas. La contradiction est enregistrée telle quelle, et c'est la facture du fournisseur qui tranche.

Les fournisseurs ne comptent pas de la même façon

Détail technique, mais il a des conséquences directes sur ce que vous payez.

Les fournisseurs ne s'accordent pas sur ce qu'est un « jeton d'entrée ». Certains incluent les lectures de cache dans le total d'entrée, d'autres les excluent. Certains comptent le raisonnement interne du modèle dans la sortie, un autre le déclare à côté. Prendre chaque convention au pied de la lettre reviendrait à facturer plus cher les clients d'un fournisseur pour la même quantité de travail.

Nous normalisons donc avant de calculer : après passage, l'entrée exclut toujours le cache et la sortie inclut toujours le raisonnement, quel que soit le fournisseur. C'est invisible pour vous, et c'est précisément le but.

Ce que ça ne résout pas

Deux limites, pour ne pas laisser croire que le système est parfait.

D'abord, l'estimation initiale n'est qu'une estimation. Elle est calculée avant l'appel, donc avant de savoir combien le modèle va écrire. Elle est volontairement un peu haute — sous-réserver reviendrait à ne pas réserver du tout — et l'écart vous est restitué au règlement. Vous voyez donc parfois un solde disponible plus bas que votre solde réel pendant quelques secondes.

Ensuite, une réponse coupée en cours de route pose un problème réel. Certains fournisseurs annoncent un compteur de sortie provisoire dès le premier fragment ; un flux interrompu au mauvais moment laisse donc une donnée d'usage qui paraît complète et annonce une réponse d'un seul jeton. Nous détectons ce cas et refusons de régler dessus : l'opération reste en attente avec les éléments partiels conservés, et attend la confirmation.

---

Rien de tout cela n'est un argument de vente. C'est le fonctionnement, et il est écrit ici parce qu'un mécanisme qu'on peut décrire est un mécanisme qu'on peut vous laisser vérifier. Les prix, eux, sont sur la page tarifs — lus directement dans le catalogue de facturation, pas recopiés à la main.