dff652/codex-token-saver

Codex Token Saver

Optimieren Sie den Arbeitsablauf, ohne Korrektheit, Verifikation, Sicherheit oder das gewünschte Ergebnis des Benutzers zu beeinträchtigen. Behandeln Sie Token-Ersparnisse als sekundäre Randbedingung: Überspringen Sie niemals eine notwendige Datei, Quelle, einen Test oder eine Genehmigung, nur um den Verbrauch zu reduzieren.

Wählen Sie den leichtesten sinnvollen Eingriff

Bevor Sie den Arbeitsablauf ändern, identifizieren Sie die tatsächliche Verschwendung:

• wiederholtes Lesen unveränderter Projektkontexte;
• häufiges Polling, während ein anderer Prozess noch läuft;
• eine lange Konversation, die veraltete Entscheidungen weiterträgt;
• ein leistungsfähiges oder teures Modell, das begrenzte mechanische Arbeit erledigt;
• Drift, spekulative Erweiterung oder wiederholte Nacharbeit.

Wenden Sie nur die unten aufgeführten relevanten Maßnahmen an. Fügen Sie keinen Prozess-Overhead für eine kurze, klar abgegrenzte Aufgabe hinzu.

Kontext wiederverwenden statt neu einlesen

• Trennen Sie dauerhaften Kontext von sich ändernden Beweisen. Dauerhafter Kontext umfasst Projektzweck, Architektur, Codierungskonventionen, feste Randbedingungen und Standardbefehle. Sich ändernde Beweise umfassen neue Anforderungen, Bearbeitungen, Fehler, Protokolle und Testergebnisse.
• Verwenden Sie eine prägnante, dauerhafte Zusammenfassung wieder, wenn sie bereits vertrauenswürdig ist. Lesen Sie nur die Dateien oder Abschnitte erneut, die sich möglicherweise geändert haben oder von denen die aktuelle Entscheidung tatsächlich abhängt.
• Suchen Sie nach Symbolen und Pfaden, bevor Sie große Dateien öffnen. Bevorzugen Sie gezielte Bereiche und fokussierte Abfragen gegenüber breiten Verzeichnis- oder Dokumentenlesevorgängen.
• Verlassen Sie sich nicht auf das Gedächtnis, wenn die Korrektheit vom aktuellen Dateiinhalt abhängt. Überprüfen Sie Zeitstempel, Diffs, Suchergebnisse oder die relevante Quelle, bevor Sie entscheiden, dass ein erneutes Lesen unnötig ist.
• Extrahieren Sie bei großen Dokumenten einmalig durchsuchbaren Text, wenn das Layout irrelevant ist. Behalten Sie das Original bei und überprüfen Sie es, wenn Bilder, Tabellen, Seitenumbrüche oder Formatierungen die Aufgabe beeinflussen.

Effizient auf langlaufende Arbeiten warten

• Bevorzugen Sie ereignisgesteuerte Wartezeiten oder das längste sichere Warteintervall, das vom aktuellen Tool unterstützt wird, gegenüber schnellen, leeren Polling-Schleifen.
• Rufen Sie nicht wiederholt eine leere Eingabe-/Poll-Operation auf, wenn die vorherige Operation bereits eine wiederverwendbare Sitzungs- oder Zellenkennung zurückgegeben hat.
• Wenn ein äußerer Ausführungsaufruf eine innere Wartezeit umschließt, geben Sie dem äußeren Aufruf genügend Zeit, um das innere Ergebnis zu empfangen, einschließlich einer angemessenen Pufferzeit. Respektieren Sie die aktuellen Höchstwerte der Plattform und Anweisungen mit höherer Priorität; codieren Sie kein Intervall fest, das die aktive Umgebung verbietet.
• Senden Sie während wirklich langer Wartezeiten prägnante, benutzerorientierte Fortschrittsaktualisierungen in der vom aktuellen Umfeld geforderten Kadenz.

Checkpoints für große Projekte

Erstellen oder aktualisieren Sie für Arbeiten, die sich über viele Phasen erstrecken oder wahrscheinlich in einer anderen Aufgabe fortgesetzt werden, DEV_STATE.md im Projekt, nur wenn die Persistenz sinnvoll ist und das Schreiben in den Aufgabenbereich fällt. Halten Sie es kompakt und sachlich:

# Entwicklungsstand

## Ziel
## Verifizierter aktueller Stand
## Entscheidungen und Begründungen
## Geänderte Dateien
## Tests und Ergebnisse
## Nächster Schritt
## Blockaden oder offene Fragen

• Zeichnen Sie validierten Zustand auf, kein Transkript.
• Entfernen Sie überholte Pläne, anstatt sie anzuhäufen.
• Behandeln Sie das Repository und die Testergebnisse als Quelle der Wahrheit, wenn sie mit dem Checkpoint in Konflikt stehen.
• Lesen Sie bei Wiederaufnahme zuerst den Checkpoint, dann prüfen Sie nur die Dateien, die erforderlich sind, um zu verifizieren, dass er noch aktuell ist.

Arbeit nach Schwierigkeit lenken (wenn autorisiert)

Wenn Modellauswahl oder Delegierung verfügbar und erlaubt ist:

• Behalten Sie die Interpretation mehrdeutiger Ziele, Architekturentscheidungen, Aufgabenzerlegung und finale Integration beim stärksten geeigneten Modell.
• Geben Sie einem kostengünstigeren Modell begrenzte Aufgaben mit expliziten Eingaben, Ausgaben, Randbedingungen und Akzeptanzprüfungen, wie z. B. fokussierte Überprüfung, isolierte Implementierung oder Fehlerdiagnose von Testfehlern.
• Delegieren Sie nicht nur, um Token zu sparen, wenn Koordination oder Nacharbeit wahrscheinlich teurer sind.
• Gehen Sie niemals von aktuellen Modellpreisen oder Kontingentmultiplikatoren aus. Wenn Kosten Teil der Empfehlung sind, überprüfen Sie diese anhand der aktuellen offiziellen OpenAI-Dokumentation.
• Befolgen Sie die Autorisierungsregeln der Umgebung für Unteragenten und Modellwechsel; diese Fähigkeit gewährt keine Berechtigung, Agenten zu erzeugen oder Modelle zu wechseln.

Drift und Nacharbeit verhindern

• Wenn die Ausführung von der Anfrage abweicht, stoppen Sie den unproduktiven Zweig, formulieren Sie das Ziel und die aktuellen Beweise neu und fahren Sie mit dem kleinsten gültigen nächsten Schritt fort.
• Halten Sie temporäre Nebenfragen aus dem Hauptimplementierungskontext heraus, wenn das Produkt ein separates Nebengespräch bietet und die Antwort im primären Verlauf nicht benötigt wird.
• Bevorzugen Sie die einfachste Implementierung, die den genannten Bedarf erfüllt, erstellen Sie eine ausführbare Minimallösung vor optionaler Erweiterung, verwenden Sie nach Möglichkeit ausgereifte Abhängigkeiten und vermeiden Sie Abkürzungen, die absehbare Wartungsschulden schaffen.
• Wiederholen Sie nicht wiederholt dieselbe fehlgeschlagene Aktion, ohne den Fehler zu überprüfen und den Ansatz zu ändern.

Ergebnis melden

Geben Sie zum Abschluss kurz an, welche Optimierungen den Arbeitsablauf wesentlich verändert haben, was noch gelesen oder getestet wurde, um die Korrektheit zu gewährleisten, und ob es noch Unsicherheiten gibt. Vermeiden Sie die Angabe eines prozentualen Anteils eingesparter Token, es sei denn, dieser wurde aus tatsächlichen Nutzungsdaten gemessen.