kitorz/token-step-tracker

Token-Warnungen nichts für Jungfrauen

Verfolge den ungefähren Tokenverbrauch, ohne die Aufgabe zu unterbrechen oder Abrechnungsgenauigkeit zu beanspruchen.

Tracking starten

1. Unterteile die Aufgabe in sinnvolle, ergebnisorientierte Schritte. Behalte den bestehenden Plan bei, falls bereits einer vorhanden ist.
2. Gib einmal an, dass die Tokenzahlen Schätzungen sind und versteckte System-, Reasoning- und Plattform-Overhead nicht enthalten.
3. Lies ein positives ganzzahliges Alarmintervall aus der Benutzeranfrage, z. B. 5000 in „Alarm alle 5000 Token“. Verwende 10000, wenn der Benutzer Alarme ohne Angabe eines Intervalls anfordert. Gib das aktive Intervall einmal an.
4. Setze die nächste Alarmschwelle auf ein Intervall und erhöhe sie nach jedem Alarm um das Intervall.
5. Führe keine zusätzlichen Tool-Aufrufe durch, lese keine Dateien erneut oder generiere keine zusätzlichen Inhalte, nur um eine Schätzung zu verbessern.

Jeden abgeschlossenen Schritt melden

Füge diesen kompakten Checkpoint nach der Meldung des nützlichen Ergebnisses des Schritts an:

Token-Checkpoint · Schritt {n}: {name}
Dieser Schritt: ≈{niedrig}–{hoch} Token | Kumuliert: ≈{niedrig}–{hoch}
Haupttreiber: {größte beobachtbare Quelle}
Nächstes Sparen: {ein umsetzbarer Vorschlag oder „Keine sinnvolle Änderung – aktuellen Ansatz beibehalten.“}

Zähle einen Schritt nur, wenn er ein sinnvolles Ergebnis liefert. Erstelle keine Checkpoints für Statusmeldungen, Genehmigungen, Wartezeiten oder triviale interne Aktionen.

Schwellenwarnungen anzeigen

Vergleiche nach jedem Checkpoint den Mittelpunkt des kumulierten Bereichs mit der nächsten Alarmschwelle. Wenn er die Schwelle erreicht oder überschreitet, füge an:

> :red_circle: TOKEN-ALARM | **{schwelle} geschätzte Token verbraucht**

Verwende einen roten Kreis plus fette Ziffern als portablen Fallback. Wenn der Host sichere Inline-HTML-Farben unterstützt, gib den Wert als <span style="color:#d00"><strong>{schwelle}</strong></span> aus; sende niemals rohe Terminal-Escape-Codes. Ein reines Skill kann keine Betriebssystem-Benachrichtigung erstellen oder Textfarbe garantieren, daher nenne dies einen Alarm, kein System-Popup.

Wenn ein Schritt mehrere Schwellen überschreitet, sende einen Alarm für die höchste überschrittene Schwelle und erhöhe die nächste Schwelle über den kumulierten Mittelpunkt hinaus. Wiederhole niemals einen bereits ausgegebenen Alarm.

Konsistent schätzen

Schätze anhand des beobachtbaren Inhalts, der während des Schritts verarbeitet oder erzeugt wurde:

• Englischer Text: etwa 1 Token pro 4 Zeichen.
• Chinesischer Text: etwa 1 Token pro 1,5–2 Zeichen.
• Code und strukturierte Daten: etwa 1 Token pro 3 Zeichen.
• Berücksichtige relevanten Prompt-Text, neu gelesene Tool-Ausgaben, generierte Inhalte und sichtbar für den Schritt wiederverwendeten Kontext.
• Vermeide Doppelzählung desselben Artefakts innerhalb eines Schritts.
• Verwende einen Bereich von mindestens ±25%; erweitere ihn, wenn die Kontextwiederverwendung unklar ist.
• Runde Grenzen auf sinnvolle Werte. Bevorzuge ≈800–1.200, nicht ≈917–1.143.
• Addiere Schrittbereiche, um den kumulierten Bereich zu erhalten.

Schließe niemals versteckte Reasoning-Token, Plattformanweisungen, Cache-Verhalten, Abrechnung oder monetäre Kosten ein. Wenn die Laufzeitumgebung explizit Verbrauchsdaten bereitstellt, melde diese getrennt als genauen Laufzeitverbrauch, anstatt sie in die Schätzung einzumischen.

Einsparungen empfehlen

Gib höchstens eine Empfehlung pro Checkpoint. Ziele auf die größte beobachtbare vermeidbare Kostenquelle:

• Große Dateilesevorgänge: zuerst suchen, dann nur passende Abschnitte lesen.
• Wiederholte Lese- oder Suchvorgänge: das bereits erhaltene Ergebnis wiederverwenden.
• Breite Tool-Ausgabe: Pfade, Felder, Datumsbereiche oder Ergebnismengen einschränken.
• Überdimensionierter Kontext: stabile Ergebnisse zusammenfassen, bevor fortgefahren wird.
• Lange generierte Ausgabe: ein kompakteres Format anfordern oder erstellen, wenn Details unnötig sind.
• Wiederholte Fehler: den Fehler prüfen und den Ansatz vor dem erneuten Versuch ändern.
• Übermäßige Beispiele: ein repräsentatives Beispiel behalten, es sei denn, ein Vergleich ist erforderlich.

Empfehle nicht, Validierung, Sicherheitsprüfungen, erforderliche Nachweise oder vom Benutzer angeforderte Details nur zur Reduzierung von Token zu überspringen. Wenn keine sinnvollen Einsparungen möglich sind, sage dies, anstatt Ratschläge zu erfinden.

Tracking abschließen

Füge eine kurze Zusammenfassung nach dem endgültigen Ergebnis der Aufgabe an:

Token-Schätzung Zusammenfassung
Schritte: {anzahl} | Gesamt: ≈{niedrig}–{hoch} Token
Größter Schritt: {Schrittname} (≈{niedrig}–{hoch})
Alarmintervall: {intervall} Token | Ausgelöste Alarme: {anzahl}
Bestes Einsparungspotenzial für nächsten Durchlauf: {ein Vorschlag mit höchster Wirkung}
Genauigkeit: Nur Schätzung; enthält versteckten System-, Reasoning-, Cache- und Plattform-Overhead nicht.

Halte Checkpoints und die Zusammenfassung gegenüber der eigentlichen Aufgabe des Benutzers nachrangig.