WaveSpeedAI API Pricing: Comment fonctionnent les crédits + Un simple calculateur de coûts

Bonjour, vous vous souvenez de moi ? Je m’appelle Dora.

Je n’ai pas commencé à réfléchir à la tarification. Je voulais juste un après-midi tranquille de test. Mais à mi-chemin du câblage d’un petit prototype (janvier 2026), mes notes ont commencé à dériver de « ça fonctionne-t-il ? » à « combien cela coûtera-t-il si ça sort réellement ? » C’est généralement le moment où je fais une pause. La tarification de l’API WaveSpeed n’est pas spectaculaire. C’est le genre qui se cache dans les détails, la taille du contexte, les tentatives, la taille des données. Rien n’est dramatique, mais ça s’accumule. Voici comment je l’ai estimé, avec des chiffres réels où je peux et des estimations simples où je ne peux pas. Si vous travaillez comme moi, en expédiant de petites expériences qui pourraient se développer, cela peut vous aider à planifier sans deviner.

Comment la tarification est mesurée

Je n’ai pas trouvé un seul nombre qui capturerait clairement la tarification de l’API WaveSpeed. Je la traite donc comme trois catégories :

Appel de base : les frais pour frapper un endpoint une fois. Pensez-y comme la « cotisation d’entrée ».
Charge de travail variable : la partie qui augmente avec ce que vous envoyez et demandez, les tokens, la taille du fichier, le niveau du modèle, les outils utilisés, la longueur du contexte.
Extras : stockage, sortie de données, et tout ce qui persiste ou déplace les données.

Pour la planification, j’utilise une formule simple :

Coût estimé = (exécutions × base_par_appel) + (volume_entrée × taux_entrée) + (volume_sortie × taux_sortie) + (données_stockées × taux_stockage × mois) + (sortie_GB × taux_sortie)

C’est ennuyeux, c’est pour ça que ça marche. Je garde les tarifs dans une petite feuille et je les ajuste à mesure que la documentation change. Si vous faites la même chose, ajoutez aux favoris les pages officielles de tarification et de limites : elles changent souvent, et les petits changements là-bas ont des répercussions sur tout le reste.

Facteurs qui multiplient les coûts

Quelques éléments augmentent discrètement les totaux. Aucun d’eux n’est une « surprise » en soi. Ensemble, c’est la raison pour laquelle les budgets dérivent.

Prompts longs et sorties généreuses : chaque 1k tokens supplémentaires apparaît sur la facture. Je limite les tokens de sortie maximum à moins qu’il n’y ait une raison de ne pas le faire.
Tentatives et solutions de secours : solides pour la fiabilité, difficiles pour le coût s’ils sont laissés largement ouverts. J’utilise une stratégie de backoff exponentiel avec un plafond ferme.
Gros fichiers : la transcription, la vision ou l’analyse PDF devient coûteuse quand vous leur jetez de gros actifs. Je réduis l’échantillonnage ou je divise en chunks.
Chaînes d’outils : une action utilisateur peut se ramifier en plusieurs appels API. C’est facile d’oublier que chaque étape d’outil est une autre exécution facturable.
Concurrence : le parallélisme est excellent pour la latence, mais il multiplie les coûts lors des tests de charge. Je l’augmente tard, pas tôt.
Journalisation et captures : utiles pour le débogage. Cher si vous stockez tout pour toujours. Je garde les journaux structurés minces et je les fais pivoter agressivement.

Si vous ne mesurez rien d’autre, mesurez les tokens, les tailles de fichiers et les comptages de tentatives. Ces trois éléments expliquent la plupart de mes surprises.

3 scénarios réels (10 / 50 / 100 exécutions)

Ce ne sont pas des chiffres officiels. Ce sont mes estimations de planification à partir d’un prototype de janvier 2026. Échangez vos propres tarifs : la forme devrait tenir.

Tarifs d’espace réservé supposés (pour les calculs uniquement) :

Base par appel : 0,002 $
Tokens d’entrée : 0,50 $ par 1M de tokens (0,0005 $ par 1k)
Tokens de sortie : 1,00 $ par 1M de tokens (0,001 $ par 1k)
Stockage : 0,02 $ par GB-mois
Sortie : 0,09 $ par GB

Scénario A : prompt court → réponse courte

Entrée moyenne : 600 tokens : sortie : 200 tokens : pas de fichiers.
Par exécution : base 0,002 $ + entrée (0,6k × 0,0005 $ = 0,0003 $) + sortie (0,2k × 0,001 $ = 0,0002 $) = 0,0025 $
10 exécutions ≈ 0,025 $ : 50 exécutions ≈ 0,125 $ : 100 exécutions ≈ 0,25 $

Comment ça s’est ressenti : pratiquement gratuit jusqu’à ce que les tentatives commencent. Quand j’ai autorisé 3 tentatives, les coûts ont presque doublé pendant une heure instable. J’ai limité à 1 tentative et j’ai mis le reste en file d’attente.

Scénario B : résumé d’un PDF moyen

Entrée moyenne : 6 000 tokens à partir de texte divisé en chunks : sortie : 1 000 tokens.
Par exécution : base 0,002 $ + entrée (6k × 0,0005 $ = 0,003 $) + sortie (1k × 0,001 $ = 0,001 $) = 0,006 $
10 exécutions ≈ 0,06 $ : 50 exécutions ≈ 0,30 $ : 100 exécutions ≈ 0,60 $

Remarque : le coût caché ici était l’extraction. Quand j’ai envoyé des PDF complets au lieu de chunks de texte propres, l’étape de préparation a ajouté du temps et parfois un deuxième appel. Le texte d’abord était moins cher et plus prévisible.

Scénario C : vision légère + résumé + exportation

Image : 1,5 MB moyenne : entrée 2 000 tokens : sortie 500 tokens : stockage du résultat pendant 1 mois : exportation 0,5 GB au total sur les exécutions.
Par exécution (API) : base 0,002 $ + entrée (2k × 0,0005 $ = 0,001 $) + sortie (0,5k × 0,001 $ = 0,0005 $) = 0,0035 $
Stockage : si chaque résultat ajoute environ 200 KB d’artefacts, 100 exécutions ≈ 20 MB = 0,02 GB × 0,02 $ ≈ 0,0004 $/mois (négligeable)
Sortie : 0,5 GB × 0,09 $ = 0,045 $ au total sur le lot
10 exécutions ≈ 0,035 $ + stockage minuscule : 50 exécutions ≈ 0,175 $ + sortie si vous exportez : 100 exécutions ≈ 0,35 $ + ~0,045 $ sortie

Ce qui m’a surpris : la sortie était le seul élément de ligne que j’ai ressenti. Pas énorme, mais perceptible quand j’exportais des médias pour les clients.

À un moment donné, j’ai arrêté de vouloir estimer et je voulais juste que les choses restent prévisibles.
C’est pourquoi nous avons construit WaveSpeed — pour exécuter des expériences comme celles-ci sans surveiller constamment les comptages de tokens, les tentatives ou les lignes de sortie surprises.

Si vous testez des idées qui pourraient se mettre à l’échelle, essayez.

Tableau du calculateur de coûts

Je garde une petite feuille de calcul. Ce n’est pas fancy, juste des calculs honnêtes. Si vous voulez un croquis rapide, versez vos chiffres dans ce modèle.

Exécutions	Base/appel ($)	Tokens entrée/exécution	Tokens sortie/exécution	Taux entrée ($/1k)	Taux sortie ($/1k)	Sortie (GB)	Sortie $/GB	Total estimé ($)
10	0,002	600	200	0,0005	0,001	0	0,09	(10×0,002) + (10×0,6×0,0005) + (10×0,2×0,001) + (0×0,09)
50	0,002	6000	1000	0,0005	0,001	0	0,09	(50×0,002) + (50×6×0,0005) + (50×1×0,001)
100	0,002	2000	500	0,0005	0,001	0,5	0,09	(100×0,002) + (100×2×0,0005) + (100×0,5×0,001) + (0,5×0,09)

Remarque : remplacez les tarifs d’espace réservé par les chiffres actuels de la page de tarification de WaveSpeed. Je garde les versions dans la feuille, juste une colonne de date, pour me souvenir de ce qui a changé et quand.

Comment réduire le gaspillage

Ce qui m’a aidé le plus n’était pas la magie, juste des garde-fous qui ont tenu bon :

Définissez les tokens de sortie maximum. Les longues réponses sont agréables : les factures prévisibles sont encore meilleures.
Élaguer les prompts. Réutilisez les prompts système et les ID de référence au lieu de coller des murs de texte.
Mettez en cache les résultats intermédiaires. Ne ré-embeddez pas ou ne ré-résumez pas le contenu inchangé.
Regroupez où c’est sûr. Dix petits appels peuvent être moins chers qu’un seul gros, ou l’inverse. Testez les deux.
Dimensionnez correctement les fichiers. Réduisez l’échelle des images, extrayez le texte des PDF avant l’envoi.
Limitez les tentatives et les délais d’attente. La fiabilité est bonne : les boucles infinies ne le sont pas.
Journalisez légèrement. Conservez les hashes et les ID : supprimez les charges brutes à moins que vous n’en ayez vraiment besoin.

Conseils de facturation d’équipe

Je me suis trompé sur les coûts de l’équipe plus d’une fois. Quelques habitudes m’ont sauvé :

Clés séparées par environnement et par projet. Rend l’attribution évidente.
Étiquetez les demandes avec l’utilisateur ou les ID de fonctionnalité. Le coût post-hoc par fonctionnalité est de l’or pendant la planification.
Tableau de bord partagé avec des instantanés hebdomadaires. Personne ne lit le bruit quotidien.
Budgets souples au niveau du projet. Quand 80 % est atteint, les fonctionnalités ralentissent ou passent à un chemin moins cher.
Une personne possède les mises à jour de tarification. Pas pour garder la confidentialité, juste pour réduire la dérive.
Gardez un runbook : ce qu’il faut d’abord limiter quand les coûts montent en flèche (tokens de sortie, concurrence ou outils optionnels).

Garde-fous budgétaires

Voici ce que j’ai mis en place avant que quelque chose ne soit exposé aux utilisateurs réels :

Estimateur de préflight : une petite fonction qui calcule le coût estimé par action et l’ajoute aux journaux.
Plafonds par action : si une seule exécution projette au-dessus de X $, elle refuse poliment.
Plafonds quotidiens et mensuels avec alertes. Les alertes vont à un canal discret que quelqu’un surveille réellement.
Mode lent : un drapeau qui réduit de moitié la concurrence sous pression budgétaire.
Indicateurs de fonctionnalités pour les chemins lourds : désactivez la vision ou les fonctionnalités de long contexte sans redéploiement.
Cadence d’examen : 15 minutes tous les deux vendredis pour mettre à jour les tarifs à partir de la page de tarification officielle. Honnêtement, rien de tout cela n’est glamour. Mais la tarification de l’API WaveSpeed se comporte bien quand vous le faites. Le drôle, c’est qu’une fois les garde-fous en place, l’outil s’efface à nouveau en arrière-plan, exactement où je l’aime.

Je me surprends encore à vérifier les comptages de tokens par habitude, puis à fermer l’onglet quand les chiffres semblent raisonnables. De vieilles habitudes. De petits soulagements. Je vais prendre ça.