xxwzkdwz/astra-cost-preview-skill

Aperçu du coût des tâches · Devis avant exécution

L'utilisateur décrit ce qu'il veut faire → Astra évalue le périmètre et la charge de travail → donne simultanément un devis Standard et Fast → l'utilisateur choisit avant de commencer. La valeur principale est le devis préalable, pas la vérification a posteriori, l'exécution automatique ou un long exposé sur les coûts.

Quand vous utilisez ce Skill pour demander un prix, par défaut seul le devis est fourni. Même si l'utilisateur dit « Crée-moi un jeu, estime d'abord », vous devez d'abord donner le devis et attendre le choix ; ce n'est que s'il dit explicitement « fais-le après le devis » que vous pouvez continuer dans le cadre de l'autorisation initiale. Le devis lui-même consomme un peu d'utilisation de modèle, sans garantie de coût zéro.

« Demander à Astra » signifie laisser l'Astra en cours d'exécution évaluer selon les informations disponibles, et non qu'il existe une interface de devis interne au modèle. Si le modèle actuel n'est pas Astra ou que son identité est inconnue, ne faites pas semblant d'avoir interrogé Astra ; vous pouvez préciser « estimation basée sur les tarifs Astra ». Ce Skill ne change pas de modèle tout seul, ne crée pas d'assistant et ne lance pas une autre requête de modèle payante.

Définir le périmètre

• Utilisez en priorité le modèle, le canal de facturation, le niveau de vitesse et le périmètre de tâche explicitement fournis par l'outil courant ; ne déduisez pas d'après le fait que l'utilisateur dit « Tu es Astra » ou du style d'écriture du modèle. En l'absence d'information, mentionnez « inconnu » ou listez des scénarios nommés clairement.
• Distinguez le montant API, les crédits Codex, les quotas inclus dans l'abonnement, les coûts internes du fournisseur. Le montant équivalent API n'est pas le débit réel de l'utilisateur ; les crédits ne sont pas un pourcentage de quota restant ; les coûts internes du fournisseur ne peuvent pas être déduits du prix public.
• Consultez les tarifs officiels en vigueur, enregistrez l'URL, la date de vérification, le modèle, le canal et l'unité de facturation. Réutilisez les informations déjà vérifiées dans ce tour, ne refaites pas une longue recherche pour chaque devis. En l'absence de tarif disponible, écrivez « inconnu », ne mémorisez pas de prix codé en dur, ne supposez pas que c'est gratuit.
• Privilégiez les outils d'accès direct à la documentation officielle. OpenAI : page des modèles https://developers.openai.com/api/docs/models/gpt-6-astra, tarifs API https://developers.openai.com/api/docs/pricing, tarifs Codex https://developers.openai.com/codex/pricing, utilisation inférence https://developers.openai.com/api/docs/guides/reasoning. Les tarifs changent ; un lien n'est pas une preuve vérifiée.

Estimer l'utilisation de la tâche

Commencez par délimiter le périmètre de livraison en une phrase, par exemple « un jeu de plateforme web jouable avec un niveau, incluant pièces, ennemis, respawn et tests de base, sans déploiement ». Évitez de mélanger un prototype simple et un produit commercial complet dans la même fourchette de devis. Effectuez seulement quelques vérifications en lecture seule ; ne lancez pas la tâche complète, un appel payant de test ou un nouvel assistant pour évaluer.

En combinant le contexte visible, la taille des fichiers, les allers-retours d'outils, la longueur de livraison, le nombre d'itérations prévu et les enregistrements de tâches similaires réellement disponibles, prédisez respectivement l'utilisation la plus probable, la plus basse et la plus haute. L'utilisateur voit d'abord la valeur la plus probable, accompagnée d'une fourchette de variation raisonnable, pas seulement une plage immense du prix le plus bas au plus haut.

Pour réduire la fourchette, augmentez les justifications plutôt que de la comprimer mécaniquement : privilégiez la correspondance avec l'utilisation réelle de tâches similaires, ajustez en fonction de la longueur du contexte actuel, des capacités de l'outil, de la disponibilité du cache et des exigences de livraison ; en l'absence d'enregistrement, faites une estimation par phase de travail. Un seul cas historique peut servir d'analogie, mais ne représente pas une précision vérifiée ; ne présentez pas le coût réel d'une tâche tout juste terminée comme s'il avait été prédit avant. La valeur la plus probable doit provenir d'un scénario de charge de travail clair, ne peut pas être automatiquement la moyenne des bornes inférieure et supérieure.

Si la fourchette reste large, identifiez l'ambiguïté qui a le plus d'impact sur le résultat et posez une question courte pour la réduire, ou donnez explicitement deux devis : une version réduite et une version complète. Si des données clés manquent encore, admettez que l'estimation est grossière, n'inventez pas de certitude pour satisfaire à une « fourchette étroite ». Sans données, ne prétendez pas à une « erreur inférieure à 20 % » ou à un intervalle de confiance statistique.

Attention à la facturation :

• Les requêtes multiples répètent l'historique, les résultats d'outils et les nouvelles entrées, il ne faut pas compter seulement la phrase de l'utilisateur.
• Distinguez l'entrée non mise en cache de l'entrée mise en cache ; en l'absence d'information sur le cache, utilisez le scénario sans cache ou calculez séparément, sans garantie de hit.
• La sortie doit couvrir les tokens de raisonnement et les autres tokens de génération facturés, pas seulement le texte visible final. Si usage.output_tokens inclut déjà reasoning_tokens, il ne faut pas les additionner à nouveau.
• Les seuils de contexte long, la vitesse, le niveau de service, l'écriture en cache, etc. sont vérifiés canal par canal pour chaque requête, puis agrégés ; n'appliquez pas les seuils d'une seule requête à l'ensemble des tokens cumulés de la tâche, et ne mélangez pas les multiplicateurs API et Codex.
• Listez séparément la génération d'images, de vidéos, de voix, la recherche, les conteneurs, les autres outils du fournisseur et l'utilisation supplémentaire des assistants autorisés. Écrivez « inconnu » pour les éléments non facturés, ne faites pas passer un sous-total partiel pour le coût total.
• Utilisez uniquement les données d'utilisation dans le périmètre de la tâche et accessibles à l'utilisateur. Ne lisez pas les identifiants, ne parcourez pas les conversations non liées, et ne déduisez pas le coût de cette tâche à partir de la variation du quota partagé du compte ; d'autres tâches et des remises à zéro de quota peuvent interférer.

Devis et suite

Par défaut, affichez un petit tableau de devis dans la langue actuelle de l'utilisateur :

Tâche : version et périmètre de livraison clairs en une phrase.

| Niveau | Estimation principale | Fourchette prévue | | Standard | ~ X credits | L–H credits | | Fast | ~ Y credits | A–B credits |

Justification : une ou deux hypothèses de charge de travail / cache les plus importantes ; éléments non inclus ou risques particuliers. En cas de première fois ou de données insuffisantes, mentionnez « estimation non calibrée, pas un débit réel ».

Choisissez Standard ou Fast pour commencer.

X/Y sont des espaces réservés de format ; ils doivent être remplacés par des nombres calculés en fonction de la tâche et des tarifs vérifiés, ne les recopiez pas. Par défaut, arrondissez raisonnablement, n'utilisez pas de décimales pour simuler une précision de prédiction. Si vous ne pouvez pas calculer un niveau, conservez la ligne et expliquez « inconnu », ne supprimez pas silencieusement Fast.

Pour comparer les deux niveaux, utilisez le même périmètre de livraison et les mêmes hypothèses de charge de travail, comparez uniquement les tarifs applicables ; sauf preuve du contraire, ne considérez pas Fast comme plus performant, consommant moins de tokens ou ayant une durée d'exécution déterminée. Les multiplicateurs Fast pour les crédits Codex et les montants API peuvent être différents ; vérifiez-les séparément. Appliquez le multiplicateur uniquement aux coûts de modèle concernés ; les images, outils tiers, etc. sont facturés à leur propre tarif, ne multipliez pas le prix total par un taux uniforme.

Par défaut, attendez le choix ou la confirmation de l'utilisateur ; si l'hôte ne peut pas changer de niveau via les outils disponibles, expliquez que l'utilisateur doit le faire, ne prétendez pas que Fast est déjà activé. Les confirmations liées au coût ne remplacent pas les exigences d'autorisation de la tâche elle-même. N'abaissez pas les critères de validation, n'ajoutez pas d'interface payante ou ne déléguez pas de tâche sans autorisation.

Lorsque l'utilisateur fixe un budget, confirmez d'abord l'unité et le périmètre couvert. Si l'estimation dépasse le budget ou qu'un coût clé est inconnu, demandez avant la prochaine opération payante contrôlable. Un Skill seul ne peut pas arrêter de force une requête de modèle en cours, une génération externe ou un assistant concurrent ; il ne peut pas garantir un dépassement nul. Un budget strict nécessite une mesure et une interception au niveau de l'exécution réelle, ne le simulez pas dans ce Skill.

Le recalcul a posteriori n'est effectué que si l'utilisateur le demande, il ne prend pas le pas sur le devis préalable. S'il existe une utilisation fiable au niveau de la tâche, rapportez « utilisation réelle », le montant calculé selon le tarif reste une « estimation tarifaire », le débit officiel fait foi sur la facture. En l'absence de données, écrivez « non obtenu ». Ne persistez les enregistrements de calibration anonymisés que si l'utilisateur le demande.

Calculateur local optionnel

Pour additionner plusieurs éléments : python3 scripts/calculate.py quote.json. Hors ligne, n'appelle pas de modèle, ne lit pas de compte, ne collecte pas de tokens, et ne vérifie pas si les tarifs sont à jour.

Champs d'entrée JSON :

• unit : USD, CNY ou credits, uniforme dans tout le tableau ; calculez les devises séparément, sans conversion implicite.
• items : chaque élément contient name, quantity: [low, high], expected_quantity, rate, basis, source, as_of. expected_quantity est la quantité la plus probable justifiée, doit se trouver dans l'intervalle ; si inconnue ou omise, ne prenez pas automatiquement le milieu.
• quantity est un intervalle de quantité pour une unité de facturation claire ; rate est le tarif applicable par unité (déjà vérifié et tenant compte du canal/multiplicateur) ; basis explique l'unité, le modèle, le canal et la justification de la quantité ; source est le lien officiel ou explicitement la source du tarif fournie par l'utilisateur ; as_of est la date de vérification du tarif au format AAAA-MM-JJ.
• Si la quantité ou le tarif est inconnu, utilisez null, ne mettez pas 0. Prenez en charge plusieurs scénarios, modèles ou outils, mais ne doublez pas la facturation.
• Pour rapporter deux niveaux simultanément, définissez compare_fast: true au niveau racine, et ajoutez fast_rate à chaque élément ; le multiplicateur applicable est vérifié par l'appelant selon le canal courant. Pour les frais d'outil fixes, fast_rate est égal à rate ; si le taux Fast manque, traitez-le comme inconnu. Les deux niveaux utilisent le même ensemble de scénarios de quantité.

La sortie distingue le sous-total des éléments connus, l'intervalle d'estimation total et la valeur la plus probable ; s'il y a au moins un élément inconnu, l'estimation totale est vide. L'exhaustivité dépend toujours de si vous avez listé tous les éléments ; un calcul correct ne signifie pas une prédiction exacte. Test : python3 -m unittest discover -s scripts -p 'test_*.py'.