🤓 Nolife Tokens – Verkleinerung des LLM-Kontexts ohne Zerstörung der Wiederherstellbarkeit

vom 16. August 2026

KI-Codierungsagenten haben ein bekanntes Leistungsproblem umgekehrt.

Jahrelang kämpften wir mit Datenmengen, HTTP-Roundtrips, Latenzbudgets und Prozessspeicher. Diese Einschränkungen sind nach wie vor relevant. Neu ist jedoch, dass ein Großteil der Kosten und Fehlerursachen einer Agentensitzung nun in der Eingabeaufforderung liegt: Tool-Ausgabe, Protokolle, Diffs, Repository-Strukturen, Compiler-Rauschen, JSON-Datenblöcke und dieselben Informationszeilen, die hunderte Male wiederholt werden.

Die naive Pipeline ist einfach:

Tool → giant stdout → LLM context

Das funktioniert so lange, bis der Kontext mit irrelevanten Daten gefüllt ist und das Modell immer noch die eine relevante Fehlerzeile finden muss. Größere Kontextfenster ermöglichen es zwar, alles zu senden, machen es aber nicht ratsam.

Dieser Artikel dokumentiert nolife-tokens, ein bewusst kleines Symfony + Flow-Experiment. Die These ist eng gefasst und überprüfbar:

Das Entfernen von Informationen aus dem aktiven LLM-Kontext bedeutet nicht zwangsläufig deren Verlust. Der Kontext kann stark komprimiert werden, während ausgelassene Informationen weiterhin deterministisch über leichtgewichtige Referenzen wiederhergestellt werden können.

Wir haben Volumen, Signalspeicherung und bytegenaue Wiederherstellung bei Testgeräten gemessen. Die vom Anbieter abgerechneten Token, die End-to-End-Agentenlatenz und die Kosten in Dollar haben wir noch nicht gemessen. Diese Unterschiede sind wichtig.

Inspiration ohne Produkte zu kopieren

Mehrere offene Projekte erforschen verwandte Ideen: RTK (Komprimierung der Befehlsausgabe, bevor der Agent sie liest), Kontextmodus (Rohdaten aus dem Fenster halten und bei Bedarf abrufen), Headroom (inhaltsbewusste Komprimierung mit reversibler Speicherung), Claude-mem (progressive Offenlegung des Speichers).

Sie müssen diese Codebasen nicht kennen. Der gemeinsame Nutzen liegt nicht in „einem weiteren Agenten-Framework“. Er liegt vielmehr darin:

Führen Sie weitere deterministische Arbeiten durch, bevor Sie Daten an das LLM senden.

Das Deduplizieren von Logs, das Entfernen von Telemetrieschlüsseln, das Klassifizieren eines Git-Diffs, das Hashen eines ausgelassenen Abschnitts – all das erfordert kein Modell. Das Kontextbudget des Modells sollte für Mehrdeutigkeiten und Entscheidungen verwendet werden, nicht für fünfhundert Kopien von [INFO] Anfrage gestartet.

nolife-tokens ist ein Labor für diese Idee im Darkwood-Stack: PHP 8.5, Symfony Console und darkwood/flow. Keine Einbettungen, keine Vektordatenbank, kein MCP, kein Redis, keine LangChain.

Ausgangspunkt: ein Grundgerüst und eine Observable-Pipeline

Das Projekt begann als einfaches Symfony 8.1-Gerüst. Der Anwendungscode bestand im Wesentlichen aus einem Kernel. Flow war bereits eine Composer-Abhängigkeit, wurde aber nicht verwendet.

Der erste Meilenstein, TOKEN_PIPELINE_POC, stellte eine minimale Flow-Pipeline über ein veränderliches ContextPacket her:

Load
→ Classify
→ MeasureRaw
→ Optimize
→ MeasureOpt
→ EvaluateSignals

CLI-Oberfläche:

bin/console tokens:analyze fixtures/sample.log
bin/console tokens:benchmark

Der Ablauf ist hier nicht wegen der Notwendigkeit einer gleichzeitigen Orchestrierung nützlich, sondern weil jede Phase beobachtbar ist. Das Paket sammelt eine Ablaufverfolgung: Bytes und geschätzte Token nach dem Laden, Inhaltstyp nach der Klassifizierung, Größe nach der Optimierung, Erfolg/Misserfolg nach den Signalprüfungen. Der Leser (und der Entwickler) sieht:

raw → classified → reduced → evaluated

statt eines undurchsichtigen optimizeContext(), das verbirgt, wo die Lautstärke verschwunden ist.

Ein typischer tokens:analyze-Trace sieht im Prinzip so aus:

LOAD         | fixtures/sample.log | 19,354 bytes
CLASSIFY     | log
MEASURE_RAW  | 19,354 bytes        | ~4,839 tokens
OPTIMIZE     | log refs=1          | 4,813 bytes
MEASURE_OPT  | markers~4 referenced~3671 | ~1,204 tokens
SIGNAL       | PASS
RECOVERY     | PASS

Diese Stufenliste ist das Produkt. Wenn etwas schiefgeht – unzureichende Einsparungen, ein fehlerhaftes Signal, zu viele Referenzen – lässt sich erkennen, welcher Schritt dafür verantwortlich ist, ohne eine separate Metrikplattform einrichten zu müssen.

Warum das Projekt klein halten? Weil Kontextsysteme dazu neigen, sich zu Frameworks auszuwachsen, bevor überhaupt getestet wurde, ob die Kernidee funktioniert. nolife-tokens ist bewusst eher ein Konsolenlabor als eine Bibliothek-API. Keine Ports, Adapter oder spekulative Schnittstellen. Einfache PHP-Klassen, Symfony-Dienste via Autowiring, Dateien unter var/.

Geschätzte Token, nicht abgerechnete Token

Die Messung verwendet eine dokumentierte Näherung, dieselbe Heuristik, die RTK öffentlich dokumentiert:

// TokenEstimator.php (excerpt)
estimatedTokens: (int) ceil($bytes / 4),

Prozentangaben zwischen Rohdaten und optimierten Daten sind für den Vergleich nützlich. Absolute Zahlen entsprechen nicht den vom Anbieter abgerechneten Token. Unterschiedliche Modelle verwenden unterschiedliche Tokenisierungsmethoden. In diesem Artikel bezeichnet „Token“ diese Schätzung, sofern nicht anders angegeben.

Deterministische Klassifizierung zuerst

Die Komprimierungsstrategie hängt vom Inhaltstyp ab. Die Klassifizierung erfolgt heuristisch und ohne LLM.

Diese Unterscheidung ist nicht akademischer Natur. Unterschiedliches Rauschen lässt sich unterschiedlich komprimieren.

• Protokolle: Wiederholungen und Meldungen mit geringem Signal müssen vermieden werden; wichtige ERROR-/WARNING-Zeilen müssen erhalten bleiben.
• JSON: Telemetriedaten, Padding, Anfrage-IDs; Entscheidungsfelder (id, status, error) müssen erhalten bleiben
• Git-Diffs: Viele + / - Zeilen enthalten die nützlichen Informationen; aggressives Kürzen ist gefährlich
• Dateilisten: können zu Baumstrukturen mit Zählungen zusammengefasst werden
• Text: Nur leichte Leerzeichen im aktuellen POC

Erster Vergleichsmaßstab: Lautstärke vs. Signal

Die Testdaten enthalten absichtlich kritische Zeichenketten. Eine Optimierung, die lediglich das Ende abschneidet, würde zwar oft „Tokens sparen“, aber gleichzeitig den eingefügten Fehler löschen. Der Benchmark überwacht daher SIGNAL: Jede erwartete Teilzeichenkette muss im optimierten sichtbaren Text noch vorhanden sein.

Ergebnisse des ersten Meilensteins (verlustbehaftete Optimierung – ausgelassenes Material wurde noch nicht gespeichert):

* geschätzt als Bytes / 4

Zu den platzierten Signalen gehörten:

• ERROR PaymentService line 421 in der Protokolldatei
• authentizitätsprüfung entfernt und src/Security/AuthGuard.php im Diff
• Zahlungs-ID, "status": "fehlgeschlagen" und die Fehlermeldung im JSON-Format

Die entscheidende Kennzahl ist nicht „Wie viel haben wir entfernt?“, sondern: Sind die für die Entscheidungsfindung notwendigen Informationen erhalten geblieben?

JSON: Strukturiertes Rauschen lässt sich gut komprimieren

JSON war der einfachste Fall. Strukturierte Schlüssel ermöglichten es einem deterministischen Filter, Telemetriedaten zu verwerfen oder später darauf zu verweisen, während Entscheidungsfelder erhalten blieben. Eine Nutzlast, die hauptsächlich aus Füll- und Debug-Frames bestand, reduzierte sich von geschätzten ~6.800 Token auf wenige Dutzend sichtbare JSON-Token im ersten Meilenstein mit SIGNAL PASS.

Das ist der strukturelle Vorteil von typisiertem Rauschen: Man kann benennen, was entbehrlich ist.

Protokolle: Wiederholung ist kostenloses Geld – bis die Signale ausfallen

Die Protokolle werden komprimiert, weil die Agenten dieselbe Zeile wiederholt sehen:

[INFO] request started
[INFO] request started
[INFO] request started
[INFO] request started

wird zu:

[INFO] request started ×4

Wichtige Signalzeilen bleiben unverändert. Das klingt trivial, bis man einen deterministischen Test zur Datenspeicherung schreibt. Eine frühe Testumgebung verwendete [ERROR] PaymentService Zeile 421, während das erwartete Signal ERROR PaymentService Zeile 421 lautete. Der Teilstring schlug aufgrund der schließenden eckigen Klammer ] zwischen ERROR und PaymentService fehl. Die Lehre daraus ist simpel und wichtig: Signaltests reagieren empfindlich auf Formatierungsänderungen, und wichtige Signalzeilen müssen sowohl für Menschen als auch für Prüfungen stabil genug bleiben.

Git-Diffs: ein nützlich schwaches Ergebnis

Die Diff-Fixture sparte nur etwa 24 % ein. Das ist kein Fehler des Experiments. Besteht der Großteil der Eingabe aus sinnvollen Änderungszeilen, gibt es kaum unbedenkliches Rauschen. Ein blindes Anstreben einer „90%igen Reduzierung“ würde die Entscheidungsgrundlage verschlechtern (beispielsweise durch das Entfernen der Authentifizierungsprüfung in AuthGuard.php).

Git-Diffs zeigen eine natürliche Komprimierungsgrenze. Genau solche Ergebnisse wünscht man sich von einem Laborexperiment: wo man nicht noch weiter pushen sollte.

Was der erste Meilenstein in einem Satz lehrte: Token-Reduzierung ohne Signaltest ist sinnlos. Mit einem Signaltest lässt sich der Unterschied zwischen „Wir haben Rauschen entfernt“ und „Wir haben den Fehler beseitigt“ erkennen.

Die fehlende Eigenschaft: entfernen ≠ zerstören

Der erste Proof of Concept wies eine strukturelle Schwäche auf. Sobald Inhalte verworfen wurden, waren sie nicht mehr im aktiven Kontext verfügbar und somit nicht mehr zugänglich. Falls ein Agent später entschied, dass die verworfenen Telemetriedaten relevant waren, gab es nichts abzurufen.

Das führt zum zweiten Meilenstein: REVERSIBLE_CONTEXT_POC.

Prinzip:

REMOVE FROM CONTEXT
≠
DESTROY INFORMATION

Optimierer geben nun ein OptimizeResult zurück:

// OptimizeResult.php
final class OptimizeResult
{
    /**
     * @param list<array{reason: string, content: string, marker_placeholder?: string}> $omissions
     */
    public function __construct(
        public readonly string $visible,
        public readonly array $omissions = [],
    ) {}
}

ContextOptimizer speichert jede Auslassung unter var/context/<id> .json und fügt eine kurze Markierung in den sichtbaren Text ein:

// ContextOptimizer.php (excerpt)
$id = $this->store->makeId($packet->sourcePath, $omission['reason'], $omission['content']);
$ref = new ContextReference(
    id: $id,
    source: $packet->sourcePath,
    type: $packet->type->value,
    reason: $omission['reason'],
    content: $omission['content'],
);
$this->store->put($ref);
// ...
$visible = str_replace($placeholder, $ref->marker(), $visible);

Die IDs sind deterministisch und kurz: ctx_ plus die ersten Hexadezimalziffern von sha256(source|reason|content).

Tatsächliche gespeicherte Form (abgekürzt):

{
  "id": "ctx_31154f",
  "source": "fixtures/sample.log",
  "type": "log",
  "reason": "deduplicated repeated lines",
  "content": "[INFO] request started\n..."
}

Der aktive Kontext benötigt lediglich Folgendes:

#ref:ctx_31154f

Im logischen Groblauf kostet diese Markierung etwa vier geschätzte Token, während ~3.600 geschätzte Token außerhalb des Kontextes auf der Festplatte liegen.

Retrieval ist ein Konsolenbefehl, keine Suchmaschine:

bin/console tokens:show-ref ctx_31154f

// TokensShowRefCommand.php (excerpt)
$ref = $this->store->get($id);
$io->writeln(sprintf('Source: %s', $ref->source));
$io->writeln(sprintf('Type: %s', $ref->type));
$io->writeln(sprintf('Reason: %s', $ref->reason));
$io->writeln('--- RAW CONTENT ---');
$io->writeln($ref->content);

ContextStore::get normalisiert #ref:ctx_… oder reine IDs und liest die JSON-Datei. Die Wiederherstellung in der Pipeline erfolgt bytegenau: Jede Referenz wird neu geladen und der Inhalt mit dem während der Optimierung geschriebenen Inhalt verglichen.

Aktualisierte Flow-Pipeline

Load
→ Classify
→ MeasureRaw
→ Optimize (+ store refs)
→ MeasureOpt
→ EvaluateSignals
→ EvaluateRecovery

Die Konstruktion bleibt ein FlowFactory-Generator von Closures über ContextPacket:

// TokenPipelineFactory.php (excerpt)
return $this->flowFactory->create(static function () use (...) {
    yield static function (ContextPacket $packet): ContextPacket {
        $packet->type = $classifier->classify($packet->raw);
        $packet->addTrace('CLASSIFY', $packet->type->value);
        return $packet;
    };

    yield static function (ContextPacket $packet) use ($optimizer): ContextPacket {
        $optimizer->optimize($packet);
        $packet->addTrace('OPTIMIZE', sprintf('%s refs=%d', $packet->type->value, count($packet->references)));
        return $packet;
    };

    // … MEASURE_OPT, SIGNAL …

    yield static function (ContextPacket $packet) use ($store): ContextPacket {
        foreach ($packet->references as $ref) {
            $loaded = $store->get($ref->id);
            if ($loaded === null || $loaded->content !== $ref->content) {
                $missing[] = $ref->id;
            }
        }
        $packet->recoveryPass = $missing === [];
        $packet->addTrace('RECOVERY', $packet->recoveryPass ? 'PASS' : 'FAIL');
        return $packet;
    };
});

Zwei Invarianten:

1. SIGNAL – Eingebettete kritische Zeichenketten bleiben im sichtbaren optimierten Text erhalten.
2. WIEDERHERSTELLUNG — jede #ref-Nachricht wird byteweise von var/context/ übertragen.

Reversibler Benchmark

Aktuelle Messergebnisse:

So lesen Sie die Spalten:

• RAW — geschätzte Token der ursprünglichen Eingabe
• SICHTBAR — geschätzte Tokens, die sich noch im aktiven Kontext befinden (einschließlich #ref-Markierungen)
• MARKIERUNGSMARKIERUNGEN — geschätzte Kosten nur für die Markierungsmarkierungen
• VERWENDET — geschätzte Tokens, die außerhalb des Kontextes gespeichert wurden.
• GESPART — Reduzierung des sichtbaren im Vergleich zum Rohmaterial
• SIGNAL-/WIEDERHERSTELLUNG — die beiden Invarianten für bestanden/nicht bestanden

JSON lässt sich weiterhin stark reduzieren (ca. 98 % sichtbare Reduzierung), wobei Entscheidungsfelder erhalten bleiben und ca. 6.200 geschätzte Token hinter strukturellen Referenzen geparkt werden. Diffs bleiben der resistenteste Fall (ca. 24 %), jetzt mit einer einzigen groben Referenz für den reduzierten, unveränderten Kontext anstelle von Dutzenden von Mikroreferenzen.

Grob vs. fein: Referenzgranularität hat ihren Preis

Für die Protokolle werden beide Granularitätsstufen des Benchmarks ausgeführt.

Der Feinmodus verdreifachte die Referenzanzahl und den Marker-Overhead, um etwa zwei geschätzte sichtbare Token einzusparen. Für diese Arbeitslast war der Grobmodus besser geeignet: einfacherer Abruf, weniger IDs, die ein Agent verfolgen muss, nahezu identischer aktiver Kontext.

Das ist kein allgemeingültiges Gesetz. Die Granularität sollte dem erwarteten Abrufmuster entsprechen. Protokolle benötigen oft einen einzigen Blob, der alle zusammengefassten Daten enthält. Strukturiertes JSON benötigt häufig Referenzen an Feldpositionen, damit das Modell weiterhin erkennt, wo die Telemetriedaten gespeichert wurden.

Logarithmische Grobeinmission (Auszug):

// LogOptimizer.php (coarse branch excerpt)
$out[] = sprintf('%s ×%d', $prev, $count);
$coarseParts[] = $expanded;
// …
$visible .= "\n\nRepeated informational logs omitted.\n" . $placeholder;
$omissions[] = [
    'reason' => 'deduplicated repeated lines',
    'content' => implode("\n\n", $coarseParts),
    'marker_placeholder' => $placeholder,
];

Strukturelle JSON-Referenzen

Konzeptionell:

{
  "id": 42,
  "status": "failed",
  "error": "PaymentService timeout",
  "telemetry": { "... huge payload ..." }
}

wird zu:

{
  "id": 42,
  "status": "failed",
  "error": "PaymentService timeout",
  "telemetry": "#ref:ctx_xxxxxx"
}

Das Modell erfasst weiterhin semantische Position, Kennungen, Status und Fehler. Schätzungsweise sechstausend Telemetrie-Token sind außerhalb des Zeitfensters verfügbar. Die aktuelle Konfiguration liefert neun Referenzen (Rauschschlüssel + gruppierte Auffüllung), ca. 36 Marker-Token, SIGNAL PASS und RECOVERY PASS.

Dies ist robuster als das Löschen von Schlüsseln: Die Struktur bleibt erhalten, selbst wenn die Werte aus der Eingabeaufforderung entfernt werden.

Im Code werden Rauschschlüssel nicht verworfen; ihre Werte werden zu Platzhaltern, die ContextOptimizer später in #ref:… umschreibt. Padding-Schlüssel, die padding_* / noise_* entsprechen, werden nach Möglichkeit zu einer einzigen Auslassung zusammengefasst, damit ein großer Block nicht in achtzig kleine Referenzen zerfällt:

// JsonOptimizer.php (excerpt)
if ($this->isPaddingKey($key)) {
    $paddingBucket[$key] = $item;
    continue;
}

if ($this->isNoiseKey($key)) {
    $placeholder = '{' . '{REF_' . count($omissions) . '}' . '}';
    $omissions[] = [
        'reason' => 'omitted json field: ' . $key,
        'content' => json_encode($item, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT) ?: '',
        'marker_placeholder' => $placeholder,
    ];
    $result[$key] = $placeholder;
    continue;
}

Das sichtbare JSON sieht daher immer noch wie die API-Antwort aus. Das ist wichtig für Agenten, die Feldnamen ebenso wie Fließtext analysieren.

Dies ist kein RAG

nolife-tokens verwendet keine Einbettungen, Vektorsuche, semantische Suche, externe Datenbanken, LangChain, MCP oder Redis.

Die heutige Abfrage ist:

reference id → local JSON file → exact bytes

Diese Einfachheit ist beabsichtigt. Wir wollen Beweise dafür, dass eine kostengünstige Strukturreduktion bereits den größten Teil des offensichtlichen Überschusses beseitigt. Die semantische Suche kann warten, bis Messungen deren Notwendigkeit aufzeigen.

Auswirkungen auf Kodierungsagenten

Eine diszipliniertere Pipeline sieht folgendermaßen aus:

Tool
  → deterministic reducer
  → high-signal context (+ #ref markers)
  → LLM

          ↓ (only if needed)
     tokens:show-ref / expand
          ↓
       raw source

Dies erfordert weder einen Ersatz für Cursor noch die Entwicklung einer anderen IDE. Eine zukünftige Integration kann so einfach sein wie:

bin/console tokens:context …

und das optimierte Ergebnis in einen bestehenden Agenten einzufügen oder weiterzuleiten. Ziel ist ein besserer Kontext für die bereits verwendeten Tools – keine weitere Agentenoberfläche.

Kosten und Latenz (sorgfältige Ansprüche)

Weniger Eingabetoken können die Kosten für den Anbieter, den Vorverarbeitungsaufwand, die Latenz und das Rauschen reduzieren. Wir haben diese Auswirkungen in diesem Projekt nicht anhand einer Live-Anbieter-API getestet. Bisher haben wir Kontextvolumen, Signalspeicherung und Wiederherstellung gemessen. Eine Volumenreduzierung fälschlicherweise als Kostensenkung zu interpretieren, wäre irreführend.

Es gibt noch einen weiteren Effekt zweiter Ordnung, der für die Agenten relevant ist: Ablenkung. Selbst wenn ein Modell den Fehler in einem 20 KB großen Protokoll findet, kann es seine Aufmerksamkeit auf die umgebenden Wiederholungen richten. Deterministische Datenreduktion dient nicht nur der Kostenoptimierung, sondern schafft eine klarere Entscheidungsgrundlage für das Modell. Dieser Effekt ist schwieriger zu quantifizieren als die Anzahl der Bytes, und wir haben hier auch nicht versucht, ihn zu quantifizieren.

Eine praktische, kurzfristige Anwendung innerhalb von Darkwood-Workflows ist derzeit noch offline möglich: Man führt tokens:analyze auf einer Fixture oder einem erfassten Tool-Dump aus, untersucht den Stage-Trace und entscheidet, ob der sichtbare Kontext für das Einfügen in Cursor ausreicht. Eine Integration, die jeden Shell-Befehl abfängt (RTK-Stil), ist für diese Meilensteine ​​ausdrücklich nicht vorgesehen.

Ingenieurphilosophie

Bevor Sie ein Model anrufen, fragen Sie:

Kann PHP diesen Teil deterministisch lösen?

In dieser Codebasis, die Folgendes beinhaltet: Inhalte klassifizieren, Protokolle deduplizieren, JSON-Rauschen entfernen oder referenzieren, Dateistrukturen reduzieren, Git-Metadaten und lange unveränderten Kontext verwerfen, Auslassungen hashen, Referenzen speichern, Größen messen, Signale überprüfen, Wiederherstellung überprüfen.

Komponenten (Aufgaben, keine Dateiausgabe):

Fehlermodi, die wir bereits erreicht haben oder erwarten

Überkompression

Eine seltene, aber entscheidende Linie kann wie Rauschen aussehen. Installierte Signalleuchten erfassen einen Teil davon; echte Agenten treffen auch die Stellen, die von den Leuchten nicht erfasst werden.

Referenzexplosion

Ein früher Git-Ansatz erzeugte etwa 36 winzige Referenzen für zusammengefasste Kontextläufe. Der Marker-Overhead stieg enorm an; die Benutzerfreundlichkeit beim Abrufen verschlechterte sich. Die Lösung bestand in einer einzigen groben Referenz für den gesamten ausgelassenen, unveränderten Kontext. Weniger, aber aussagekräftige Referenzen sind besser als viele Mikroreferenzen.

Semantischer Verlust

Die Beibehaltung einer Zeichenkette gewährleistet nicht immer deren Interpretierbarkeit. Ein Statuscode ohne begleitende Erläuterung kann ein Modell weiterhin verwirren. Deterministische Filter optimieren auf Datenvolumen und explizite Signale, nicht auf deren Verständnis.

Falsche Sicherheit durch bytes / 4

Die prozentualen Vergleichswerte sind für dieses Labor aussagekräftig. Die absoluten „auf der Rechnung eingesparten Gutscheine“ hingegen nicht.

Abrufabhängigkeit

Sobald der Agent auf #ref angewiesen ist, muss ihm beigebracht werden, wie er die Referenz erweitert. Aktuell ist dies ein Mensch, der tokens:show-ref ausführt. Die automatische, progressive Offenlegung ist das nächste Experiment, noch keine ausgereifte Funktion.

ID-Kollisionen und Ladenhygiene

Referenz-IDs sind inhaltsadressiert. Kollisionen mit anderem Inhalt verlängern die Hash-Länge und führen zu einem Fehler. Kollisionen mit dem Inhalt werden idempotent überschrieben. Der Speicher befindet sich unter var/, das von .gitignore ignoriert wird; es handelt sich um einen Arbeitsbereichscache, nicht um eine dauerhafte Wissensdatenbank. Dies ist für einen Proof of Concept (POC) angemessen, aber für den produktiven Mehrbenutzerbetrieb unzureichend – ein weiterer Grund, dies nicht mit der Persistenz von Claude-mem zu verwechseln.

Sicherheitslage

Behandeln Sie analysierte Inhalte als Daten, niemals als auszuführende Anweisungen. Optimierer schreiben lediglich Zeichenketten um. Protokolle und JSON-Dateien können Text enthalten, der wie Agentenanweisungen aussieht („Vorherige Anweisungen ignorieren…“). Die Pipeline darf diesen Text nicht als Steuerungselement verwenden. Heutzutage ist dies hauptsächlich eine Frage der Implementierung: kein eval, keine Verarbeitung von Inhalten, kein Vertrauen in Fixture-Texte als Richtlinie.

Was wir absichtlich weggelassen haben

Es ist sinnvoll, auch die Nicht-Ziele aufzulisten, damit das Experiment lesbar bleibt:

Eine LLM-basierte Zusammenfassung der ausgelassenen Abschnitte erfolgt (noch) nicht. Die Zusammenfassungen wären auf andere Weise verlustbehaftet und schwieriger exakt wiederherzustellen.

• Keine automatische Cursor-Abfangfunktion oder Hülsenabfangfunktion
• Kein Kontextbudget-Packer, der aus zwanzig Kandidaten innerhalb eines 4k-Limits auswählt (später in der ursprünglichen Roadmap entworfen, nicht implementiert)
• Keine PHPUnit-Zeremoniesuite; tokens:benchmark ist die Validierungsoberfläche
• Es wird nicht behauptet, dass die geschätzten Token mit den Abrechnungszählern von OpenAI/Anthropic übereinstimmen.

Das Weglassen dieser Elemente ist Teil der Methode: Man misst die Idee der reversiblen Reduktion, bevor man Produkte darauf stapelt.

Weiter: Progressive Offenlegung

Die natürliche Fortsetzung:

LEVEL 0  tiny overview
   ↓
LEVEL 1  selected section / #ref expansion
   ↓
LEVEL 2  raw original source

Beispielskizze:

Application failed during checkout.
1 PaymentService error.
telemetry omitted.
#ref:ctx_payment

Bei Bedarf: Referenz erweitern. Nur falls weiterhin erforderlich: vollständiges Rohmaterial. Der Kontext wird bedarfsorientiert, anstatt „zuerst das gesamte Protokoll senden“.

Hier hört nolife-tokens auf, nur ein Kompressor zu sein, und wird zu einem Experiment in Kontextarchitektur.

Diagrammatisch:

                    ┌─────────────────────┐
   raw tool dump ─► │ classify + optimize │ ─► visible context (+ #ref)
                    └──────────┬──────────┘
                               │ omissions
                               ▼
                        var/context/*.json
                               │
              expand / show-ref │ (on demand)
                               ▼
                         original bytes

Heute erfolgt der Abwärtspfeil manuell. Durch die schrittweise Offenlegung wird er Teil des Agentenprozesses: zuerst die Übersicht, dann die ausgewählten Erweiterungen und erst dann die Rohdaten, wenn die kostengünstigeren Ebenen fehlschlagen.

Abschluss

Große Kontextfenster verleiten zu einer bequemen Standardeinstellung: alles senden. Die technische Frage verschiebt sich von „Wie viel kann das Modell verarbeiten?“ zu:

Welcher minimale Kontext ist für die richtige Entscheidung erforderlich, und wie kostengünstig können wir den Rest ermitteln?

Zwei Meilensteine ​​der Nolife-Tokens lassen sich bereits anhand von Messungen ablesen:

• Bei verrauschten Protokollen und JSON sind große deterministische Reduktionen möglich.
• Die Signalerhaltung kann als Invariante erster Klasse getestet werden
• ausgelassenes Material kann bytegenau wiederherstellbar bleiben
• Die Referenzgranularität selbst verursacht messbare Kosten (grob ist besser als fein bei unserer Messlatte).
• Inhaltstypen haben unterschiedliche natürliche Komprimierungsgrenzen (Git-Diffs ~24% hier).

Das Problem ist nicht gelöst. Die Kosten für die Anbieter, die agentengesteuerte Expansion und die schrittweise Offenlegung bleiben weiterhin ungelöst. Das Labor ist bewusst klein gehalten: klein genug, dass jeder Mechanismus noch verständlich ist – was bei Kontextsystemen möglicherweise genau der Sinn der Sache ist.

In dieser Arbeit verwendete Befehle

bin/console tokens:analyze fixtures/sample.log
bin/console tokens:analyze fixtures/sample.log --granularity=fine
bin/console tokens:analyze fixtures/sample.json
bin/console tokens:analyze fixtures/sample.diff
bin/console tokens:benchmark
bin/console tokens:show-ref ctx_31154f

Quellcode

Repository: https://github.com/matyo91/nolife-tokens
Slides: https://github.com/matyo91/slidewire