In Etappen arbeiten

Die vorangegangenen Artikel behandeln die Hebel einzeln: Caching (1), Limits (2), Fensterstrategie (3), Kontext (4), Modelle (5), Messwerte (6). Dieser Artikel setzt sie zu einem Arbeitsablauf zusammen und beantwortet drei Fragen, die dabei regelmäßig auftauchen.

Was ein Effort-Wechsel mitten in der Session tut

Effort ist ein Request-Parameter, kein Prompt-Inhalt. Er wirkt ab dem nächsten Turn und nicht rückwirkend:

• Nichts geht verloren. Antworten, die mit hohem Effort entstanden sind, bleiben unverändert in der Historie. Das Modell „vergisst" die Gründlichkeit nicht — es arbeitet ab jetzt nur weniger tief weiter.
• Runter (high → low): kürzere Reasoning-Ketten, weniger und stärker zusammengefasste Tool-Calls, weniger Selbstprüfung.
• Hoch (low → high): mehr Reasoning ab sofort — aber übersprungene Analyse aus der Low-Phase wird nicht nachgeholt. Steckt dort ein Fehler, musst du explizit ein Re-Check verlangen.
• Subagents erben den Session-Effort, sofern Agent-Definition oder Workflow ihn nicht überschreiben.
• /effort speichert die Wahl zusätzlich als Default für neue Sessions.

Daraus folgt: „hoch planen, niedrig ausführen" ist als Idee richtig, als Mitten-in-der-Session-Umschaltung aber teuer. Die billigeren Varianten:

Effort senken oder an ein kleineres Modell delegieren?

Beide Hebel senken den Verbrauch, aber an verschiedenen Stellen — und das entscheidet, welcher im konkreten Fall mehr fürs Kontingent bringt.

In langen Sessions dominiert der Input. 30k Kontext mal jeder Turn schlägt schnell die paar tausend Thinking-Tokens, die eine Stufe weniger Effort einspart. Genau deshalb ist Delegation bei abgeschlossenen Brocken der stärkere Hebel — wenn der Subagent den Hauptkontext nicht braucht.

Nach /clear weitermachen, wo man aufgehört hat

Der Kontext geht weg, die Dateien bleiben. Der Zustand muss also vor dem Clear auf Platte — sonst wird aus der Etappengrenze ein Neuanfang.

Das Handover-File

Eine Datei reicht. Sie wird vor dem Clear geschrieben und im ersten Turn danach gelesen:

# PLAN.md

## Ziel
<ein Satz — was am Ende stehen soll>

## Steps
- [x] 1. Schema in db/models.py erweitert
- [ ] 2. Migration schreiben   <- HIER WEITER
- [ ] 3. API-Endpoint anpassen

## Entscheidungen
- Alembic statt handgeschriebener SQL (wegen Rollback)
- Feld heisst `archived_at`, nicht `is_archived`

## Verworfen
- Soft-Delete ueber einen Trigger: bricht die bestehenden Fixtures

## Offen
- Timezone-Handling bei archived_at noch ungeklaert

Ablauf: Plan schreiben lassen → /clear → lies PLAN.md und mach bei Step 2 weiter. Der erste Turn nach dem Clear kostet damit rund zwei- bis dreitausend Tokens statt der vollen Historie.

Timing: früh schreiben, nicht am Limit

Das Handover entsteht am Ende einer Etappe, bevor der Kontext voll ist — nicht erst, wenn die Auto-Compaction anklopft. Eine Zusammenfassung, die aus einem bereits überfüllten Kontext gezogen wird, lässt genau die Details weg, die man später braucht: Sie sind zu dem Zeitpunkt schon aus dem Blick.

Drei Ergänzungen je nach Setup

Verwandt, aber nicht dasselbe: das Spec-Muster aus Artikel 3 trennt Planung und Implementierung in zwei Sessions. Das Handover-File hier trennt beliebige aufeinanderfolgende Etappen — auch mehrere Implementierungsschritte hintereinander. Beide schreiben denselben Zustand auf Platte; das Spec-File ist der Sonderfall für die erste Grenze.

Der Ablauf am Stück

Checkliste

1. Effort- und Modellwechsel an eine /clear-Grenze legen, nicht mitten in die Session
2. Alternativ zwei parallele Sessions führen — je eine mit eigenem warmem Cache
3. Bei langem Kontext delegieren statt Effort senken; bei kurzem, kontextabhängigem Edit umgekehrt
4. Vor jedem /clear: Steps, Entscheidungen und Sackgassen in eine Datei
5. Handover früh schreiben, nicht wenn der Kontext schon voll ist
6. Ein Commit pro Step — der Diff dokumentiert sich selbst
7. Nach dem Hochstufen des Efforts explizit ein Re-Check der Low-Effort-Phase verlangen
8. /usage statt Schätzung: die Aufschlüsselung nennt die Ursache selbst