1 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • À partir du 31 juillet 2026, la page Usage des offres en libre-service comme Individual et Teams passe à un affichage uniquement en tokens, et les métriques Spend, la colonne Cost et les coûts en dollars dans les CSV disparaissent
  • La raison invoquée est que le coût converti de l’usage inclus apparaissait bien plus élevé que le prix réel de l’offre, ce qui créait de la confusion ; l’affichage en dollars est maintenu pour les offres Enterprise, dont la structure d’agrégation d’usage est différente
  • Le changement s’applique au moment de la consultation, si bien que même les anciennes requêtes renvoient chargedCents: 0, usageBasedCosts: "$0.00", et il n’est plus possible de voir le coût par requête, même pour des requêtes on-demand réellement facturées
  • Les administrateurs Teams peuvent consulter certaines données de dépense via le Dashboard et l’Admin API, mais les offres en libre-service ne fournissent plus le détail en dollars par modèle auparavant disponible
  • Les utilisateurs disent qu’avec des prix par token différents selon les modèles, il devient difficile de comparer coût, efficacité et budget, et demandent un graphique en dollars distinguant usage inclus et facturation réelle, ou une option de bascule d’affichage

Disparition de l’affichage des coûts dans les offres en libre-service

  • Avec le changement déployé le 31 juillet 2026, la page Usage des offres en libre-service, dont Individual et Teams, passe à un affichage uniquement en tokens
    • La métrique Spend et la colonne Cost sont supprimées
    • Les coûts en dollars ne sont plus affichés non plus dans le CSV d’usage, et la valeur Cost encore présente est définie à 0.0 pour tous les enregistrements
    • Il n’est pas possible dans les paramètres de basculer entre tokens et dollars ni de revenir à l’ancien écran
  • Les offres Enterprise, dont la structure agrège l’usage, peuvent toujours afficher les montants en dollars dans l’écran Usage

Pourquoi ce passage à une base en tokens

  • L’offre Individual inclut un volume d’usage généreux, si bien que le montant obtenu en convertissant les requêtes au tarif API pouvait parfois sembler supérieur au coût réel de l’offre
  • Pour réduire cette confusion, Cursor a remplacé le référentiel de reporting de l’usage, passant des dollars aux tokens pour les offres en libre-service
  • L’usage inclus d’Ultra est affiché avec un nombre de tokens et la mention Included, et aucun coût distinct n’est facturé dans cette plage
  • Au départ, il avait été indiqué que l’usage on-demand au-delà du volume inclus resterait affiché en dollars dans la colonne Cost et dans le CSV, mais cela a ensuite été corrigé : ni l’écran Usage ni le CSV des offres en libre-service ne fournissent désormais de coûts en dollars

Voies actuellement disponibles pour consulter les coûts

  • Dans Dashboard > Spending, le total On-Demand Spending du cycle de facturation en cours est affiché et correspond au montant réellement facturé
  • Les administrateurs Teams peuvent voir les totaux on-demand par utilisateur dans Dashboard > Members > On-Demand
  • Dans les offres Teams en libre-service et Individual, il n’est plus possible de voir le détail en dollars par modèle que l’ancien écran Usage fournissait
  • Les administrateurs Teams peuvent obtenir des données de dépense et des champs de coût pour les événements d’usage via l’Admin API prise en charge
    • Des utilisateurs du forum demandent un endpoint permettant de récupérer directement les coûts pour un utilisateur et une période donnés, ainsi qu’une interface d’administration plus simple

Endpoint Usage et données historiques

  • https://cursor.com/api/dashboard/get-filtered-usage-events renvoyait jusqu’à ce changement les champs de coût par requête suivants
    • chargedCents
    • usageBasedCosts
    • tokenUsage.totalCents
  • Depuis le 31 juillet 2026, chargedCents vaut 0, usageBasedCosts vaut "$0.00" et totalCents est omis
  • Comme la suppression des coûts s’applique au moment de la lecture des données, elle a aussi été répercutée sur les anciens événements d’usage, et même les requêtes on-demand réellement facturées n’affichent plus de coût dans l’endpoint Usage
  • Il a été confirmé qu’il ne s’agit pas d’une erreur temporaire de reporting mais bien d’un changement intentionnel
  • Les totaux facturés par période existent toujours, mais les rapports indépendants de coût par requête construits sur les anciens champs ne fonctionnent plus de la même manière

Comment les informations de coût étaient utilisées

  • Plusieurs utilisateurs gardaient l’onglet Usage ouvert en permanence ou le consultaient plusieurs fois par jour pour suivre des budgets quotidiens, hebdomadaires et mensuels
  • Les utilisateurs Teams consultaient les dépenses par membre dans la limite on-demand partagée, et analysaient les coûts par utilisateur, modèle et requête
    • Un utilisateur Teams a indiqué que le coût cumulé d’usage pour le cycle de facturation en cours atteignait 30 000 dollars, en grande partie basé sur les tarifs API
  • Certains rechargeaient la page Usage avant et après une requête pour comparer coût et performances selon le modèle
    • Après une requête Cursor Grok 4.5, hausse d’environ $0.32
    • Après utilisation d’Opus 5, hausse d’environ $2.56
  • Certains utilisaient le montant affiché non comme facture réelle, mais comme indicateur de la valeur d’usage et des économies réalisées grâce à l’abonnement
  • Comme les prix par token diffèrent selon les modèles, le seul nombre de tokens ne permet pas de comparer directement les coûts ni le rapport prix/performance

Alternatives demandées par les utilisateurs

  • Même si Tokens reste la valeur par défaut, des demandes portent sur l’ajout d’un toggle ou menu déroulant permettant de sélectionner l’ancien graphique en dollars
  • En séparant dans les graphiques la valeur convertie de l’usage inclus et le montant on-demand réellement facturé, il serait possible de réduire la confusion tout en conservant l’information en dollars
  • Les totaux par utilisateur ne remplacent pas l’analyse par jour, par modèle ou par requête ; les demandes de rétablissement de la colonne Cost et des champs API par requête se poursuivent
  • Si une transition à long terme vers une tarification basée sur les tokens est prévue, les utilisateurs estiment qu’elle devrait être annoncée publiquement ; beaucoup disent que ce changement rend plus difficile l’estimation des dépenses mensuelles et le contrôle des coûts

Autre problème distinct lié à la sélection des sous-agents

  • Un autre problème soulevé concerne le fait qu’un modèle différent est parfois sélectionné automatiquement malgré le réglage par défaut du sous-agent
  • explore est un type de sous-agent, et Agent peut exécuter d’autres types de sous-agents utilisant différents modèles
  • Davantage d’informations sur ce comportement figurent dans Sub agents triggers even when disabled and uses Opus for no reason

1 commentaires

 
GN⁺ 1 시간 전
Commentaires de Hacker News
  • Il est recommandé de mesurer régulièrement, pour des tâches spécifiques, l’usage de tokens par combinaison de harness et de modèle
    Même avec le même modèle et le même environnement sur la même tâche, l’efficacité en tokens et le gaspillage varient fortement selon l’agent
    Voici les résultats obtenus en répétant 10 tâches d’agent avec GPT 5.6 Sol sur une VM Ubuntu 26.04, avec plusieurs harnesses

    Harness Total API Entrée En cache Hors cache Sortie
    smol 172,807 142,334 8,704 133,630 30,473
    Pi 427,211 392,767 137,216 255,551 34,444
    OpenCode 1,564,429 1,523,957 1,204,736 319,221 40,472
    Codex 3,005,744 2,953,154 2,649,344 303,810 52,590
    Hermes 3,856,611 3,808,231 3,167,232 640,999 48,380
    Claude Code 5,073,137 5,029,969 4,587,008 442,961 43,168

    https://x.com/__tosh/status/2083593799872237680
    Je m’attendais à ce que Claude Code ne soit pas optimisé pour les modèles OpenAI, mais un tel écart dû au seul harness m’a choqué
    smol, que je développe moi-même, est un harness simple qui n’utilise qu’un prompt système minimal et un seul outil shell, sans fichiers de fonctionnalités
    Il ne faut pas sous-estimer la quantité de contenu que les harnesses populaires injectent dans la fenêtre de contexte

    • Je me demande s’il existe des données permettant de déterminer si ce contenu est vraiment inutile, ou s’il s’agit au contraire d’un contexte utile propre au projet ou au langage de programmation
    • Je me demande à quel point les tâches effectuées avec smol sont complexes. J’aimerais savoir si l’agent traite tout avec sed, s’il a créé ses propres outils, et pourquoi Pi n’est pas utilisé
      L’écart de tokens entre les deux harnesses est aussi intéressant. Les prompts système ne devraient pas beaucoup différer, Pi semble même probablement plus court, et il est difficile d’expliquer cet écart avec seulement quatre outils ; j’aimerais donc tester moi-même
    • Claude Code injecte une multitude d’outils dans le prompt système, et le seul système de mémoire dépasse les 10 000 tokens
      Sur des tâches comme des boucles de monitoring, qui consomment peu de contexte mais tournent de nombreuses fois, le coût peut facilement doubler
      Il faut supprimer les outils inutiles avec --disallowed-tools, mais de nouveaux outils sont sans cesse ajoutés, ce qui devient un jeu de taupe sans fin
    • La fenêtre de contexte n’est pas seulement importante : c’est tout. Pour utiliser Claude Code efficacement, il faut décider soi-même quand compresser
      Par défaut, il utilise un contexte d’un million de tokens et ne se limite pas de lui-même. À l’inverse, le très faible volume de lectures en cache de smol pourrait aussi venir d’un problème de configuration
    • Je me demande quels outils ont été utilisés pour la comparaison, ou si le prompt a simplement été exécuté puis vérifié avec un outil comme ccusage
      Je cherche un outil de comparaison de harnesses d’agents, et j’aimerais voir non seulement les entrées et sorties, mais aussi les prompts système, les traces d’exécution et les appels d’outils
      Un faible nombre de tokens n’est pas un bon résultat si des vérifications importantes ont été omises ; un nombre élevé n’est pas non plus forcément meilleur, cela peut refléter une réflexion excessive. Voir les traces complètes d’exécution de la même tâche aiderait à comprendre pourquoi Codex consomme beaucoup et Pi peu
  • J’utilisais Cursor avec enthousiasme depuis 2023 et je payais pour, mais je ne l’ai presque pas ouvert ces six derniers mois
    Ces temps-ci, j’écris du code avec Claude Code et Codex, je lis et relis dans GitHub, et quand je regarde en local j’utilise un éditeur de texte ordinaire
    Je me demande quelle est la valeur de Cursor en 2026

    • J’ai utilisé Windsurf et Cursor et j’ai aussi donné des retours produit à l’équipe Cursor, mais le coût a fait disparaître sa valeur. Le principal avantage de Cursor semble être de prendre l’argent des utilisateurs plus vite que Claude
    • Cursor a deux avantages. D’abord, cela reste un IDE, donc on peut travailler sans devoir ouvrir VSCode/Cursor séparément de Codex, et il est plus pratique de relire les changements en profondeur dans l’IDE que dans la vue de diff de GitHub
      Ensuite, il prend en charge tous les modèles, ce qui est pratique pour en tester un autre quand le premier résultat ne convient pas
    • Pour l’édition directe, Cursor Tab est utile, mais je ne suis pas sûr que cela vaille 20 dollars par mois. À 5 dollars par mois, je pourrais m’abonner juste pour Cursor Tab et l’oublier
      Le palier à 20 dollars est beaucoup trop concurrentiel, et je préfère les plugins Claude ou Codex à la sidebar de codage agentique de Cursor
    • Les changements récents semblent avoir rendu l’édition directe de code dans Cursor moins bonne. Je ne sais pas ce qu’ils visent, et cela ne ressemble plus vraiment à un fork de VSCode ; j’envisage donc des alternatives
      Cela dit, le workflow consistant à passer de Claude Code à Codex puis à relire dans GitHub paraît fastidieux, alors que Cursor est plus intégré et offre moins de friction
    • Cursor CLI mérite aussi un coup d’œil : https://cursor.com/cli
  • En tant qu’employé de Cursor, je confirme qu’il est toujours possible de voir le montant réellement facturé sur la page Spending
    En nettoyant un vieux feature flag, nous avons accidentellement cassé la veille l’affichage des coûts en dollars dans l’export CSV Usage, et c’est désormais corrigé
    Ce flag affichait aussi à certains utilisateurs en self-service un graphique d’usage en dollars, mais il incluait en dollars l’usage compris dans certains forfaits qui n’était pas réellement facturé, ce qui prêtait à confusion. Comme certains utilisateurs le prenaient pour une dépense réelle, nous avons supprimé le graphique

    • L’indicateur circulaire de coût à côté de l’affichage de l’usage du contexte a également été supprimé. Il est maintenant plus facile de ne pas se rendre compte qu’on a laissé un modèle coûteux activé jusqu’à épuiser tous les crédits inclus, et il est difficile de croire que ce n’était pas l’objectif du changement
    • Voici l’écran où je ne peux pas le voir sur la page Spending : https://www.pasteboard.co/dNXUdT-h8Giy.png
      Si la réponse est que seuls les administrateurs peuvent le voir, cela n’aide pas. On ne peut pas demander chaque jour à l’administrateur où on en est, ni lui demander de vérifier le rapport coût-efficacité du modèle à chaque session
    • Je me demande vraiment si vous pensez que les abonnés voient l’affichage en dollars sans comprendre qu’il s’agit des tarifs API qui s’appliqueraient hors abonnement ; c’est un très mauvais changement
  • Cursor s’est rapidement diffusé en facilitant la migration depuis Visual Studio Code, mais c’est une arme à double tranchant. Il est aussi facile de revenir à VS Code avec des extensions d’agents

    • J’étais passé de VS Code à Cursor en 2023, puis je suis revenu à Claude Code et VSCode en décembre 2025, quand Opus 4.7 ou 4.6 a fait un gros bond en avant
      Venant de Sublime Text, j’avais les raccourcis par défaut de VSCode dans les doigts, mais Cursor m’a lassé en interceptant presque toutes les combinaisons avec CMD
      Maintenant que je n’ai besoin que d’un visualiseur de code rapide, je pourrais bien revenir à Sublime Text
    • Cursor propose un assistant pour importer les paramètres de VS Code, mais aucun outil de migration dans l’autre sens. Il y a quelques mois au moins, il n’y avait même pas d’outil de migration entre machines
  • À l’avenir, Elon paiera les salaires de ses employés en tokens, et les épiceries afficheront elles aussi des prix dynamiques basés sur les tokens, si bien que le prix d’un article changera entre le moment où on le prend et le passage en caisse. De toute façon, Elon a dit que l’argent allait bientôt disparaître, donc tout ira bien

    • Ma femme n’a jamais utilisé l’IA et lit même des livres papier
      Moi, je ne peux pas lire un livre ni rester assis tranquillement sur une plage ; je dois toujours nager vers un endroit qui a du sens, donc pendant que je vibe-code la prochaine web app canadienne, je dois même demander le menu du dîner à Copilot
      J’aime ma femme et elle apporte clairement de la valeur, mais qu’elle partage mes tokens, ça, c’est compliqué
  • Je l’ai vu pas plus tard qu’hier au travail : un changement qui masque le coût du service est ouvertement hostile aux utilisateurs
    Il n’y a pas d’autre façon d’emballer un changement qui pénalise les utilisateurs et profite à l’entreprise. Il faut croire qu’ils doivent justifier le rachat, pour 60 milliards de dollars, d’un IDE et d’un modèle qui était correct à l’époque

  • Quand les utilisateurs commencent à calculer le ROI des produits d’IA, il suffit de cacher le I de l’investissement pour régler le problème

    • Ces entreprises semblent vouloir rendre l’usage des tokens opaque, un peu comme les factures AWS de nombreuses organisations
      Avec une discipline stricte et des tags appropriés, on peut comprendre où va l’argent, mais peu d’endroits le font réellement
      On dirait qu’elles veulent rendre très difficile la distinction entre les ingénieurs qui gaspillent de l’IA et ceux qui créent une forte valeur par token
  • Cursor a été un excellent point d’entrée vers l’ingénierie à base d’agents, mais sa compétitivité tarifaire sur Claude semble surtout venir d’achats en gros
    Son vrai avantage défensif est Composer 2.5 ; pour moi, l’expérience d’utilisation des agents et de l’IDE reste en dessous de Codex et Claude Desktop
    Sur le plan économique, Cursor est peut-être le plus rationnel, mais quand l’écart de prix n’est pas énorme, les capacités passent avant le coût
    Ces temps-ci, j’utilise Codex et Claude Desktop, et Zen quand j’ai besoin de vérifier du code. La fonction de conversation vocale en temps réel de Codex, qui n’est pas de la dictée, est sans équivalent lorsqu’elle est combinée à des workflows d’agents

    • Comme il appartient désormais à SpaceX, Grok 4.5 peut aussi être vu comme faisant partie de la même famille. Grok 4.5 donne l’impression d’être Sonnet, tandis que Composer correspond à Haiku : un modèle rapide et compétent
  • Cursor était le fournisseur de l’entreprise pour accéder à des modèles non Anthropic, mais avec la disparition des informations de coût et l’impossibilité de proxyfier les requêtes API, sa valeur a fortement chuté
    Ils ont fortement poussé au renouvellement en promettant de conserver les conditions du forfait existant, puis ont aussitôt rompu leur promesse ; je vais donc dire clairement à la direction qu’il faut minimiser l’usage de Cursor et ne pas renouveler
    Surtout si vous n’êtes pas un grand compte, vous ne pouvez pas confier votre propriété intellectuelle à Cursor, et les autres utilisateurs feraient bien de ne pas leur faire confiance non plus

  • C’est le scénario classique d’une entreprise qui devient cupide. J’ai archivé ce fil, et je me demande si Cursor va le fermer ou le supprimer