Astra-Aufgaben-Kostenvorschau · Preisvoranschlag vor Arbeitsbeg…

Aufgaben-Kostenvorschau · 开工前报价

Der Nutzer beschreibt, was er tun möchte → Astra bewertet Aufgabenumfang und Arbeitsaufwand → gibt gleichzeitig Angebote für Standard und Fast ab → erst nach Wahl des Nutzers wird begonnen. Kernlieferung ist der Vorab-Angebotspreis, keine nachträgliche Abrechnung, keine automatische Ausführung und kein langer Kostenbeitrag.

Bei Verwendung dieses Skills wird standardmäßig nur ein Angebot abgegeben. Selbst wenn der Nutzer sagt „Erstelle mir ein Spiel, schätze es erst einmal“, soll zuerst ein Angebot abgegeben und auf die Auswahl gewartet werden; nur wenn explizit „Angebot und dann direkt loslegen“ gesagt wird, wird im ursprünglich autorisierten Rahmen fortgefahren. Das Erstellen des Angebots selbst verbraucht eine geringe Menge an Modell-Nutzung und wird nicht als kostenlos zugesichert.

„Frage Astra“ bedeutet, dass der tatsächlich laufende Astra anhand der verfügbaren Informationen bewertet, und stellt keine interne Modell-Schnittstelle dar. Wenn das aktuelle Modell nicht Astra ist oder die Identität unbekannt ist, wird nicht so getan, als ob Astra bereits gefragt wurde; es kann klar als „Schätzung nach Astra-Tarifen“ angegeben werden. Dieser Skill wechselt nicht selbstständig das Modell, erstellt keine Assistenten oder startet keine weiteren kostenpflichtigen Modellanfragen.

Festlegung des Rahmens

• Bevorzugt die vom aktuell verwendeten Tool klar bereitgestellten Modelle, Abrechnungskanäle, Geschwindigkeitsstufen und Aufgabenumfänge; nicht aus Aussagen wie „Du bist Astra“ oder dem Schreibstil des Modells auf die Identität schließen. Fehlende Angaben mit „unbekannt“ kennzeichnen, oder klar benannte Szenarioschätzungen auflisten.
• Unterscheiden zwischen API-Beträgen, Codex-Credits, im Abo enthaltenen Guthaben und internen Rechenkosten des Anbieters. API-Äquivalenzbeträge sind nicht die tatsächliche Belastung des Nutzers; Credits sind nicht der verbleibende Prozentsatz des Guthabens; interne Kosten des Anbieters können nicht aus öffentlichen Verkaufspreisen zurückgerechnet werden.
• Die aktuell gültigen offiziellen Tarife nachschlagen, dabei URL, Prüfdatum, Modell, Kanal und Abrechnungseinheit notieren. Bereits in dieser Runde geprüfte Informationen wiederverwenden, nicht für jedes Angebot erneut eine lange Suche durchführen. Wenn kein gültiger Tarif verfügbar ist, „unbekannt“ schreiben, keine fest codierten Preise speichern und nicht standardmäßig von Kostenfreiheit ausgehen.
• Bevorzugt direkte offizielle Dokumentationstools. OpenAI-Referenzen: Modellseite https://developers.openai.com/api/docs/models/gpt-6-astra , API-Preise https://developers.openai.com/api/docs/pricing , Codex-Preise https://developers.openai.com/codex/pricing , Reasoning-Nutzung https://developers.openai.com/api/docs/guides/reasoning . Tarife können sich ändern, Links sind kein geprüfter Nachweis.

Schätzung des Aufgabenumfangs

Zunächst den Lieferumfang in einem Satz abgrenzen, z. B. „Ein spielbares Side-Scrolling-Webspiel mit Münzen, Gegnern, Wiederbelebung und grundlegenden Tests, ohne Veröffentlichung.“ Vermeiden, einfache Prototypen und vollständige kommerzielle Produkte im selben Angebotsintervall zusammenzufassen. Nur wenige schreibgeschützte Prüfungen durchführen; nicht den vollständigen Task ausführen, kostenpflichtige Testaufrufe tätigen oder einen neuen Assistenten starten, um die Schätzung zu erstellen.

Unter Berücksichtigung des sichtbaren Kontexts, der Dateigröße, der Tool-Roundtrips, der Auslieferungslänge, der geplanten Iterationsanzahl sowie tatsächlich verfügbarer Aufzeichnungen ähnlicher Aufgaben jeweils die wahrscheinlichste, niedrigere und höhere Nutzung vorhersagen. Der Nutzer sieht zuerst den wahrscheinlichsten Schätzwert, daneben einen angemessenen Schwankungsbereich, nicht nur eine riesige Spanne von Minimum zu Maximum.

Die Methode zur Verengung des Intervalls besteht darin, die Begründung zu verstärken, nicht mechanisch zu komprimieren: Bevorzugt die tatsächliche Nutzung ähnlicher Aufgaben abgleichen, die aktuelle Kontextlänge, Tool-Fähigkeiten, Cache-Verfügbarkeit und Lieferanforderungen anpassen; wenn keine Aufzeichnungen vorliegen, eine phasenweise Arbeitsaufwandsabschätzung durchführen. Nur ein historischer Fall kann als Analogie dienen, nicht als validierte Genauigkeit; die tatsächlich gemessenen Kosten einer gerade abgeschlossenen Aufgabe dürfen nicht als vorhergesagtes Ergebnis ausgegeben werden. Der wahrscheinlichste Wert muss aus einem klaren Arbeitsszenario stammen und darf nicht automatisch der Durchschnitt der oberen und unteren Grenze sein.

Wenn das Intervall immer noch breit ist, die eine Unklarheit identifizieren, die das Ergebnis am meisten beeinflusst, und mit einer kurzen Frage eingrenzen, oder zwei Angebote für eine kleinere und eine vollständige Version klar angeben. Wenn noch immer wichtige Daten fehlen, sollte die Schätzung als grob eingestuft werden und nicht aus Gründen der „kleinen Spanne“ Sicherheit vortäuschen. Ohne Datenunterstützung keine Behauptungen wie „Fehler unter 20 %“ oder statistische Konfidenzgrade angeben.

Bei der Abrechnung Folgendes beachten:

• Mehrere Anfragen wiederholen den Verlauf, Tool-Ergebnisse und neue Eingaben, daher nicht nur die Anzahl der Wörter des Nutzers zählen.
• Ungecachte Eingaben von gecachten Eingaben unterscheiden; wenn die Trefferquote unbekannt ist, das Szenario ohne Cache oder getrennt berechnen, keine Treffer garantieren.
• Die Ausgabe sollte sowohl die Reasoning-Token als auch andere generierte Abrechnungs-Token abdecken, nicht nur den endgültig sichtbaren Text. Wenn usage.output_tokens bereits reasoning_tokens enthält, dürfen letztere nicht noch einmal hinzugefügt werden.
• Schwellenwerte für lange Kontexte, Geschwindigkeit, Service-Level, Cache-Schreiben usw. pro Kanal und pro Anfrage prüfen, dann zusammenfassen; nicht die Token einer gesamten Aufgabe auf einen einzelnen Anfrageschwellenwert anwenden, und nicht die Multiplikatoren von API und Codex vermischen.
• Bildgenerierung, Video, Sprachausgabe, Suche, Container, Tools anderer Anbieter und zusätzliche Nutzung durch autorisierte Assistenten separat auflisten. Nicht berechnete Posten als „unbekannt“ schreiben, nicht die Zwischensumme bekannter Teile als Gesamtkosten ausgeben.
• Nur Nutzungsdaten verwenden, die innerhalb des Aufgabenumfangs liegen und auf die der Nutzer Zugriff hat. Keine Anmeldeinformationen auslesen, irrelevante Chatverläufe durchsuchen oder aus der Veränderung des gemeinsamen Guthabens vor und nach der Aufgabe auf die Kosten dieser Aufgabe schließen; andere Aufgaben und Guthabenrücksetzungen stören.

Angebot und weiteres Vorgehen

Standardmäßig ein kleines Angebot ausgeben, dabei die aktuelle Sprache des Nutzers beibehalten:

Aufgabe: Ein Satz, der Version und Lieferumfang klar angibt.

| Stufe | Hauptschätzung | Voraussichtliche Spanne | | Standard | ca. X Credits | L–H Credits | | Fast | ca. Y Credits | A–B Credits |

Grundlage: Die ein bis zwei wichtigsten Arbeits-/Cache-Annahmen; nicht enthaltene Posten oder besondere Risiken. Bei erstmaliger oder unzureichender Datenlage „Unkalibrierte Schätzung, keine tatsächliche Belastung“ vermerken.

Nach Wahl von Standard oder Fast wird begonnen.

X/Y usw. sind Platzhalter für das Format und müssen durch Zahlen ersetzt werden, die auf der Aufgabe und den geprüften Tarifen basieren; sie dürfen nicht so übernommen werden. Standardmäßig sinnvoll runden, keine Dezimalstellen verwenden, um Vorhersagegenauigkeit vorzutäuschen. Wenn eine Stufe nicht berechnet werden kann, die Zeile dennoch behalten und den Grund für die Unbekanntheit erklären, nicht stillschweigend Fast weglassen.

Beide Stufen vergleichen denselben Lieferumfang und dieselben Arbeitsannahmen, nur die geltenden Tarife vergleichen; sofern keine Belege vorliegen, Fast nicht als leistungsfähiger, tokenärmer oder mit bestimmter Ausführungsdauer betrachten. Die Fast-Multiplikatoren für Codex-Credits und API-Beträge können unterschiedlich sein, getrennt prüfen. Den Multiplikator nur auf die geltenden Modellkosten anwenden; Bilder, Drittanbieter-Tools usw. nach ihren eigenen Tarifen abrechnen, den Gesamtpreis nicht pauschal mit einem Faktor multiplizieren.

Standardmäßig auf Auswahl oder Bestätigung des Nutzers warten; wenn der Host die Stufe nicht über die verfügbaren Tools umschalten kann, erklären, dass der Nutzer umschalten muss, nicht behaupten, Fast sei bereits aktiviert. Kostenbezogene Bestätigungen ersetzen nicht die Berechtigungsanforderungen für die Aufgabe selbst. Nicht eigenmächtig die Abnahmekriterien senken, kostenpflichtige Schnittstellen hinzufügen oder Aufgaben delegieren.

Wenn der Nutzer ein Budget festlegt, zunächst die Einheit und den abgedeckten Umfang klären. Wenn die Schätzung das Budget überschreitet oder wesentliche Kosten unbekannt sind, vor dem nächsten kontrollierbaren kostenpflichtigen Vorgang nachfragen. Der Skill allein kann laufende Modellanfragen, externe Generierungsaufgaben oder parallele Assistenten nicht zwangsweise stoppen; eine Überschreitung kann nicht garantiert werden. Ein hartes Budget benötigt eine tatsächliche Messung und Sperre auf Ausführungsebene, wird in diesem Skill nicht vorgetäuscht.

Eine nachträgliche Berechnung wird nur auf Anfrage des Nutzers durchgeführt und nicht in den Hauptablauf des Vorab-Angebots eingreifen. Wenn vertrauenswürdige aufgabenbezogene Nutzungsdaten vorliegen, „tatsächliche Nutzung“ melden; der nach Tarif berechnete Betrag bleibt eine „Tarifschätzung“, die offizielle Belastung ist der Rechnung zu entnehmen. Ohne Daten „nicht erhalten“ schreiben. Kalibrierungsdatensätze nur auf Anfrage des Nutzers persistent und anonymisiert speichern.

Optionaler lokaler Rechner

Mehrere Posten addieren mittels python3 scripts/calculate.py quote.json. Rein offline, ruft kein Modell auf, liest kein Konto aus, sammelt keine Token und prüft nicht, ob die Tarife aktuell sind.

JSON-Eingabefelder:

• unit: USD, CNY oder credits, einheitlich für die gesamte Tabelle; verschiedene Währungen getrennt berechnen, keine implizite Umrechnung.
• items: Jeder Posten enthält name, quantity: [low, high], expected_quantity, rate, basis, source, as_of. expected_quantity ist die begründete wahrscheinlichste Menge, muss innerhalb des Intervalls liegen; bei unbekannt oder weggelassen nicht automatisch den Mittelpunkt verwenden.
• quantity ist das Mengenintervall in der eindeutigen Abrechnungseinheit; rate ist der geltende Tarif pro Einheit (bereits geprüft und Kanal/Multiplikator verarbeitet); basis erläutert die Einheit, das Modell, den Kanal und die Mengenbegründung; source ist der offizielle Link oder die eindeutig als vom Nutzer bereitgestellte Tarifquelle; as_of ist das Prüfdatum des Tarifs im Format JJJJ-MM-TT.
• Bei unbekannter Menge oder unbekanntem Tarif null verwenden, nicht 0 eintragen. Mehrere Szenarien, Modelle oder Tools unterstützen, aber keine doppelte Abrechnung.
• Bei gleichzeitiger Angebotserstellung für beide Stufen compare_fast: true auf oberster Ebene setzen; jeder Posten erhält zusätzlich fast_rate; der anzuwendende Multiplikator wird vom Aufrufer entsprechend dem aktuellen Kanal geprüft. Bei festen Tool-Gebühren sind fast_rate und rate identisch; fehlende Fast-Tarife als unbekannt behandeln. Beide Stufen verwenden denselben Satz von Mengenszenarien.

Die Ausgabe unterscheidet Zwischensumme der bekannten Posten, Gesamtschätzintervall und wahrscheinlichsten Wert; solange unbekannte Posten existieren, bleibt die Gesamtschätzung leer. Die Vollständigkeit hängt immer noch davon ab, ob Sie alle Posten aufgelistet haben; das Bestehen der Berechnung bedeutet nicht, dass die Vorhersage genau ist. Test: python3 -m unittest discover -s scripts -p 'test_*.py'.