chimera-budget-the-context

Sie betreiben eine Schleife, die bei jedem Schritt an eine Nachrichtenliste anhängt — ein ReAct-Agent, eine Coding-Runde, ein Tool-aufrufender Assistent — und die Liste wächst immer nur. Symptome: Der Provider wirft einen Fehler wegen der Kontextlänge, oder der Lauf überlebt, arbeitet aber nach einer langen Strecke an der falschen Datei.

Das gilt nicht für einen einmaligen Aufruf, dessen Prompt Sie selbst zusammengestellt haben und einmal messen können. Es gibt keine Verdrängungsstrategie zu entwerfen, wenn sich nichts ansammelt.

1. Schreiben Sie zwei Zahlen auf, bevor Sie die Schleife anfassen: das beworbene Fenster des Modells und den Anteil davon, den Sie für den Prompt ausgeben werden. Chimera gibt 0,6 aus (DEFAULT_BUDGET_FRACTION in chimera/core/context_budget.py). Der Rest bezahlt die Completion und die Lücke zwischen Ihrer Token-Schätzung und der echten Zählung des Providers.
2. Lösen Sie die Compaction bei einem Anteil des Budgets aus, nicht des Fensters — Chimera löst bei 0,8 des Budgets aus. Compaction braucht Platz, in den hinein sie verdichten kann; ein Auslöser am Fenster feuert dann, wenn keiner mehr übrig ist.
3. Messen Sie den festen Sockel getrennt vom wachsenden Teil. Die System-Nachricht plus die tools=-Payload werden bei jedem Schritt erneut mitgeschickt, und keine noch so gründliche Nachrichten-Compaction rührt sie an. Führen Sie chimera schema-bench aus (oder zählen Sie das JSON selbst), bevor Sie annehmen, dass die Historie das Teure ist. Ein geschwätziger MCP- oder OpenAPI-Import kann Zehntausende Tokens unter jeden einzelnen Schritt des Laufs legen.
4. Wenn der Sockel das Problem ist, verkleinern Sie den Sockel: Entfernen Sie rein annotierende Schema-Schlüssel (examples, title, default, $comment) und kürzen Sie Parameter-Prosa auf den ersten Satz, wobei type, properties, required und enum unangetastet bleiben, damit Tool-Auswahl und Argument-Gültigkeit unverändert sind. Genau das macht chimera/tools/schema_compact.py. Bieten Sie weniger Tools an, wenn es immer noch zu groß ist.
5. Legen Sie die Verdrängungsreihenfolge ausdrücklich fest: System-Nachricht nie, jüngste Runden wörtlich (Chimera behält 6), der ältere Abschnitt ersetzt durch eine Zusammenfassung oder eine sachliche Notiz. Schreiben Sie die System-Nachricht niemals um — sie ist das stabile Präfix, auf das der Prompt-Cache geschlüsselt ist, und sie zu bearbeiten macht jede zwischengespeicherte Runde dahinter ungültig.
6. Injizieren Sie nach dem Verdichten wieder, was der Lauf braucht, um noch er selbst zu sein: die Aufgabe wörtlich, den Plan, die Aufgabenliste mit Status und die Datei, die gerade bearbeitet wird. Lesen Sie die Datei erneut von der Platte, statt eine erinnerte Kopie wiederherzustellen.
7. Wenn Sie die Token-Größe selbst schätzen, zählen Sie die tool_calls-Payload mit, nicht nur content. Tool-Argumente reisen auf der Assistant-Nachricht mit und stehen nicht in content; eine Größenschätzung, die nur content liest, meldet genau die Nachrichten zu niedrig, die gewachsen sind.

Ein zu niedrig gesetztes Budget verdichtet Läufe, die das nie gebraucht hätten, und jede Compaction schreibt das Prompt-Suffix um und wirft die Cache-Treffer dahinter weg. In einer langen Coding-Sitzung ist das eine echte Rechnung, bezahlt, um einen Überlauf zu vermeiden, der nicht eingetreten wäre.

Die Schema-Compaction hat ihre eigene Kante: Eine Parameterbeschreibung auf einen Satz zu kürzen ist für die Argument-Gültigkeit unbedenklich, kann aber den Satz entfernen, der dem Modell sagte, wann das Tool zu verwenden ist. Es verändert das Auswahlverhalten, ohne irgendein Schema zu verändern, das der Validator prüft — es scheitert also als leicht schlechtere Tool-Wahl statt als Fehler. Messen Sie es als A/B, aktivieren Sie es nicht, weil es Tokens spart.

Und das ganze Muster bringt nichts, wenn die Aufgabe für das Modell schlicht zu groß ist. Budgetierung macht aus einer harten Decke eine weiche; sie schafft keinen Platz, der nicht da ist.