Formules d'économie et points de bascule pour le Vibe Coding

Établir un modèle de coût unifié avec des variables unifiées pour les trois types de tarification : par token, par appel d’API, par prompt. Fournir des formules de points de bascule et des recommandations sur les modes de travail.
Tags:
Categories:

Les modèles de tarification des outils de codage IA peuvent être classés en trois catégories :

  1. Par token : comprend diverses API, Claude Code (Claude Pro), Codex Cli (ChatGPT Plus), Zhipu Lite/Pro, la nouvelle version de Cursor, etc. Fondamentalement, tous sont basés sur le token, certains produits offrant des remises sur forfait.
  2. Par nombre d’appels d’API : comme OpenRouter (quota gratuit), ModelScope, Gemini Code Assistant (1000 appels gratuits par jour), Chutes, etc.
  3. Par nombre de prompts : comme l’ancienne version de Cursor (500 fois), Github Copilot (300 fois), etc.

Ces trois modèles consistent fondamentalement à payer pour l’inférence du modèle et le traitement du contexte, les différences résidant dans la granularité de tarification et la forme des limites.

Cet article établit un modèle de coût unifié, fournit des définitions de variables et des formules de calcul actionnables, et détermine les points de bascule pour le choix des outils sous différentes charges de travail et modes. La considération des coûts couvre les dépenses en espèces, la consommation de temps et le risque de refaire le travail.

Fonction de coût total unifiée

Pour tout outil i, le coût total sur une période de facturation peut s’écrire :

Totali=Cashi+Timei+RiskiTimei=R⋅HoursiRiski=R⋅ReworkHoursi\begin{aligned} \mathrm{Total}_i &= \mathrm{Cash}_i + \mathrm{Time}_i + \mathrm{Risk}_i \\ \mathrm{Time}_i &= R \cdot \mathrm{Hours}_i \\ \mathrm{Risk}_i &= R \cdot \mathrm{ReworkHours}_i \end{aligned}

Où R est votre taux horaire (en yuan/heure). Si vous ne souhaitez pas inclure le temps, vous pouvez définir R = 0, et la formule se réduit à une comparaison de coût en espèces pur.

Conventions de variables

Pour unifier les trois modèles de tarification, la charge de travail est divisée en deux niveaux : ‘session’ et ‘itération’. L’analyse et l’indexation lors de l’entrée dans un nouveau projet sont des opérations ponctuelles, tandis que les conversations continues et les modifications de code dans le même contexte sont des opérations répétables.

Définir les variables :

  • S_i : frais fixes de l’outil i (abonnement ou dépense mensuelle minimale)
  • N_s : nombre de nouvelles sessions sur la période (changement de projet, effacement du contexte, nouvelle session comptés)
  • N_{it} : nombre d’itérations effectives sur la période (clarification des besoins, modifications de code, correction d’erreurs, etc.)
  • R : taux horaire (yuan/heure)
  • h0_i : temps de démarrage à froid par nouvelle session (heures)
  • h1_i : temps moyen par itération (heures)
  • p_{\mathrm{fail},i} : probabilité qu’une itération échoue et nécessite un refaire (0 à 1)
  • h_{\mathrm{re},i} : temps moyen pour un seul refaire (heures)

Ainsi, les termes de temps et de risque peuvent s’écrire :

Hoursi=Ns⋅h0i+Nit⋅h1iReworkHoursi=Nit⋅pfail,i⋅hre,i\begin{aligned} \mathrm{Hours}_i &= N_s \cdot h0_i + N_{it} \cdot h1_i \\ \mathrm{ReworkHours}_i &= N_{it} \cdot p_{\mathrm{fail},i} \cdot h_{\mathrm{re},i} \end{aligned}

Il ne reste plus qu’à écrire Cash_i pour les trois modes de tarification.

Coût en espèces pour la tarification par token

Les outils de tarification par token sont généralement divisés en trois catégories : entrée, entrée avec cache d’entrée hit, sortie. Une erreur courante est de compter les mêmes tokens d’entrée à la fois dans l’entrée et le cache. Il est recommandé d’estimer d’abord le total des tokens d’entrée, puis de les répartir selon le taux de hit du cache.

Définir les variables :

  • Tin0_i : total des tokens d’entrée par nouvelle session
  • r0_i \in [0,1] : proportion de hit du cache d’entrée pour les nouvelles sessions
  • Tin1_i : total des tokens d’entrée par itération
  • r1_i \in [0,1] : proportion de hit du cache d’entrée pour les itérations
  • Tout0_i, Tout1_i : quantité de tokens de sortie
  • Pin_i, Pcache_i, Pout_i : paramètres de prix (yuan/million de tokens)

Pour les outils ne supportant pas la tarification par cache, on peut définir r0_i=r1_i=0 ou Pcache_i=Pin_i.

Alors :

Cashi(token)=Si+1106[Ns⋅(Pini⋅(1−r0i)⋅Tin0i+Pcachei⋅r0i⋅Tin0i+Pouti⋅Tout0i)+Nit⋅(Pini⋅(1−r1i)⋅Tin1i+Pcachei⋅r1i⋅Tin1i+Pouti⋅Tout1i)]\begin{aligned} \mathrm{Cash}^{(\mathrm{token})}_i &= S_i + \frac{1}{10^6}\Bigl[ N_s \cdot \bigl(Pin_i \cdot (1-r0_i)\cdot Tin0_i + Pcache_i \cdot r0_i\cdot Tin0_i + Pout_i \cdot Tout0_i\bigr) \\ &\qquad + N_{it} \cdot \bigl(Pin_i \cdot (1-r1_i)\cdot Tin1_i + Pcache_i \cdot r1_i\cdot Tin1_i + Pout_i \cdot Tout1_i\bigr) \Bigr] \end{aligned}

Cette formule explique directement une conclusion empirique : en travaillant de manière immersive et continue dans la même session, N_{it} augmente mais Tin0_i n’est payé qu’une fois, le coût moyen par itération diminue. Changer fréquemment de projet ou effacer fréquemment le contexte fait que Tin0_i est payé à plusieurs reprises.

Coût en espèces pour la tarification par nombre d’appels d’API

Le point clé de la tarification par nombre d’appels d’API est qu’un ‘appel’ couvre les opérations de dialogue, d’appel d’outil, de lecture de fichier, de recherche, d’exécution de commande, etc. Il faut estimer :

  • A0_i : nombre d’appels d’API par nouvelle session
  • A1_i : nombre d’appels d’API par itération
  • Ccall_i : prix unitaire par appel (yuan/appel)

Formule de coût en espèces :

Cashi(call)=Si+Ccalli⋅(Ns⋅A0i+Nit⋅A1i)\mathrm{Cash}^{(\mathrm{call})}_i = S_i + Ccall_i \cdot (N_s \cdot A0_i + N_{it} \cdot A1_i)

Si l’outil fournit un quota gratuit Q (appels/période) et qu’au-delà il faut attendre plutôt que payer, on peut inclure le temps d’attente dans le coût temporel, convertir les appels excédentaires en Hours_i, et toujours utiliser Total_i pour la comparaison.

Coût en espèces pour la tarification par nombre de prompts

La tarification par nombre de prompts équivaut un ‘prompt’ à une soumission de tâche. Il faut estimer :

  • P0_i : nombre de prompts par nouvelle session
  • P1_i : nombre de prompts par itération
  • Cprompt_i : prix unitaire par prompt (yuan/prompt)

Formule de coût en espèces :

Cashi(prompt)=Si+Cprompti⋅(Ns⋅P0i+Nit⋅P1i)\mathrm{Cash}^{(\mathrm{prompt})}_i = S_i + Cprompt_i \cdot (N_s \cdot P0_i + N_{it} \cdot P1_i)

Pour les produits ‘forfait mensuel incluant N fois’, on peut utiliser un prix fantôme (shadow price) comme approximation : si le coût d’abonnement de la période est S_i et le quota Q_i, alors Cprompt_i \approx S_i / Q_i. Bien que ce ne soit pas strictement le coût marginal en espèces, cela permet de transformer la ‘rareté du quota’ en un coût d’opportunité calculable.

Points de bascule : formules de séparation entre deux outils

Unifions les formules ci-dessus en une seule forme. Pour l’outil i :

Totali=Si+Ns⋅(c0i+R⋅h0i)+Nit⋅(c1i+R⋅h1i+R⋅pfail,i⋅hre,i)\mathrm{Total}_i = S_i + N_s \cdot (c0_i + R \cdot h0_i) + N_{it} \cdot (c1_i + R \cdot h1_i + R \cdot p_{\mathrm{fail},i} \cdot h_{\mathrm{re},i})

Où c0_i et c1_i représentent respectivement les coûts en espèces du démarrage à froid et d’une itération unique, correspondant aux différents développements dans les trois modes de tarification.

Étant donné deux outils A et B, avec N_s fixe, en posant Total_A = Total_B, on peut résoudre le point de bascule du nombre d’itérations :

Nit∗=(SB−SA)+Ns⋅((c0B−c0A)+R⋅(h0B−h0A))(c1A−c1B)+R⋅(h1A−h1B)+R⋅(pfail,A⋅hre,A−pfail,B⋅hre,B)N_{it}^{\ast} = \frac{ (S_B - S_A) + N_s \cdot \bigl((c0_B - c0_A) + R \cdot (h0_B - h0_A)\bigr) }{ (c1_A - c1_B) + R \cdot (h1_A - h1_B) + R \cdot \bigl(p_{\mathrm{fail},A} \cdot h_{\mathrm{re},A} - p_{\mathrm{fail},B} \cdot h_{\mathrm{re},B}\bigr) }

Explication :

Lorsque le dénominateur est positif, si N_{it} > N_{it}^{\ast} alors A est plus avantageux, si N_{it} < N_{it}^{\ast} alors B est plus avantageux. Lorsque le dénominateur est négatif, le sens de l’inégalité s’inverse. Lorsque le dénominateur est proche de 0, cela signifie que le coût marginal combiné par itération est presque identique, le choix dépend principalement des coûts fixes et du démarrage à froid.

Vous pouvez utiliser cette formule pour calculer trois points de bascule typiques : outil de tarification par token vs outil de tarification par prompt, outil de tarification par token vs outil de tarification par appels d’API, et outil de tarification par appels d’API vs outil de tarification par prompt. Il suffit de développer les c0, c1 respectifs en tokens, nombre d’appels, ou nombre de prompts selon le contexte ci-dessus.

Stratégies pratiques : méthodes pour réduire les coûts

1. Développement immersif : stratégie d’optimisation pour la tarification par token

Pour les outils de tarification par token (comme Codex Cli), la stratégie centrale est de maintenir le contexte de travail stable.

Principe : éviter de payer Tin0_i plusieurs fois. Travailler en continu dans le même projet permet de répartir le coût de chargement initial du contexte, et l’augmentation du taux de hit du cache accélère significativement la vitesse de réponse.

Pratique : éviter de changer fréquemment de projet ou d’effacer le contexte. Si vous fermez le projet après avoir corrigé un seul bug, la valeur de la lecture initiale de nombreux fichiers ne peut pas être pleinement exploitée.

2. Regroupement des besoins : stratégie d’optimisation pour la tarification par appels d’API

Pour les outils de tarification par nombre d’appels (comme Gemini Code Assistant), la stratégie centrale est de tirer pleinement parti des appels ’d’établissement du contexte’.

Principe : amortir le coût A0_i. Les appels d’outil, les lectures de fichiers, etc., sont tous comptés dans le nombre d’appels.

Pratique : regrouper plusieurs besoins liés dans une même session pour augmenter la densité de valeur des opérations initiales de lecture de fichiers. Évitez de déconnecter immédiatement après avoir terminé une petite tâche.

3. Traitement des grandes tâches : stratégie d’optimisation pour la tarification par prompt

Pour les outils de tarification par nombre de prompts (comme l’ancienne version de Cursor), ils conviennent pour traiter de grandes tâches ou de la maintenance à froid.

Principe : verrouiller le coût marginal. Quel que soit la longueur du contexte, le coût par prompt est fixe.

Pratique : Les ‘grandes tâches’ sont celles qui consomment énormément de tokens (lecture de nombreux fichiers, contexte très long) mais produisent une sortie limitée, ou qui nécessitent un modèle de haute qualité pour le contrôle. Ces tâches sont les plus rentables avec les outils de tarification par usage. Les petites tâches utilisant des outils de tarification par usage ont une rentabilité inférieure.

Un processus de choix calculable

Le diagramme de flux ci-dessous mappe les variables à la logique de choix. Après avoir estimé l’ordre de grandeur de N_s et N_{it}, utilisez la formule des points de bascule pour comparer et déterminer la solution optimale.

flowchart TD
    A[Définir la charge de travail de cette période] --> B[Estimer N_s : nombre de nouvelles sessions]
    B --> C[Estimer N_it : nombre d'itérations par session]
    C --> D[Estimer c0, c1 pour chaque type d'outil]
    D --> E[Appliquer la formule N_it*]
    E --> F{Forme principale de la charge ?}
    F -->|N_s grand, N_it petit| G[Priorité : tarification par prompt ou par appels]
    F -->|N_s petit, N_it grand| H[Priorité : tarification par token]
    F -->|Les deux sont grands| I[Diviser le flux de travail : démarrage à froid avec prompt/appels, phase approfondie avec token]

    classDef in fill:#2c3e50,stroke:#ecf0f1,stroke-width:2px,color:#ecf0f1
    classDef calc fill:#3498db,stroke:#2980b9,stroke-width:2px,color:#fff
    classDef decide fill:#f39c12,stroke:#d35400,stroke-width:2px,color:#fff
    classDef out fill:#27ae60,stroke:#229954,stroke-width:2px,color:#fff

    class A,B,C in
    class D,E calc
    class F decide
    class G,H,I out