Tesserae v0.20.2 — das Modell liest jetzt alles

<!-- translations:start -->

English · 한국어 · 中文 · 日本語 · Русский · Español · Français

<!-- translations:end -->

Veröffentlicht 2026-07-14 · PyPI · GitHub release · pip install --upgrade tesserae==0.20.2

Die zweite Hälfte des Long-Session-Fixes. v0.20.1 entfernte die 300-Turn-Import-Obergrenze, sodass die vollständige Konversationshistorie den Store erreicht; dieses Release behebt die Konsum-Seite, sodass jedes LLM, das diese Historie liest, tatsächlich alles davon liest — unabhängig von der Gesamtlänge.

Was nach 0.20.1 noch falsch war

• Session-Excerpts wurden passend gestutzt: jenseits eines Horizonts von 24,000 Zeichen pro Projekt ließen Summaries ganze Sessions mit "…more sessions omitted for length" fallen — das Modell hat sie nie gesehen.
• Ein unbegrenzter Prompt: die Summary-Narrative und das Agent-Decision-Mining schickten jeweils alles in einem einzigen LLM-Aufruf — in einem geschäftigen Zeitfenster größer als jedes Kontextfenster.
• max_turns_per_chunk zählte Turns, nicht Größe: dreißig Turns können einen einzigen 500KB-Tool-Dump enthalten; Chunks der Session-Graph-Extraction konnten weiterhin überlaufen.

Was sich geändert hat

Neu ist tesserae/llm_chunking.py: ein deterministischer Block-Packer und ein Map-Reduce-Runner, dimensioniert auf ein konservatives Kontext-Budget (48,000 Zeichen ≈ 12k Tokens; TESSERAE_LLM_CHUNK_CHARS zum Feinjustieren). Jeder LLM-Konsument von Session-Historie iteriert jetzt über budget-große Chunks — PART i/N-Map-Aufrufe, dann ein hierarchischer Merge — Truncation-Marker sind verschwunden, ein einzelner übergroßer Turn wird zeilenweise über Chunks aufgeteilt statt überzulaufen, und kleine Inputs behalten exakt den alten Single-Call-Pfad.

--max-turns bleibt ausschließlich ein Scan-Memory-Guard — es begrenzt nicht mehr, was das Modell liest.

Direkt gegen die Anforderung verifiziert: 600KB Session-Historie → 82 begrenzte Aufrufe (max. Prompt 7,525 Zeichen unter einem Test-Budget von 8,000 Zeichen) → eine zusammengeführte Narrative, in der jede Session berücksichtigt ist. Der Acceptance-Test platziert eine Decision in der letzten Session jenseits des alten Truncation-Horizonts — auf dem Code vor dem Fix schlägt er fehl.