pi-l1-cache im Benchmark: eine 138-µs-In-Memory-Cache-Schicht für den pi Coding Agent

Der pi Coding Agent erlaubt Extensions, den Provider-Round-Trip mit den Events before_provider_request und after_provider_response abzufangen. Das ist genug Raum für einen schnellen In-Memory-Cache — aber nur, wenn das Abfangen selbst billiger ist als der Round-Trip, den es spart. pi-l1-cache (v1.2.0, installierbar als npm:pi-l1-cache) ist ein bewusst minimalistischer Ansatz dafür: eine Datei, null Abhängigkeiten, ein FNV-1a-Hash, eine harte Speichergrenze, TTLs und ein CPU-Kill-Schalter bei 95 %. Wir haben es von npm installiert, gegen eine echte pi-Session geladen und das publizierte Artefakt benchmarkt — nicht das README.

Die Kernzahl ist ehrlich und brauchbar: Jeder abgefangene Request kostet etwa 138 µs — aber nur wenn der Request byte-identisch zu einem gecachten ist, entfällt der Provider-Round-Trip (1–3 s) komplett. Das ist das gesamte Wertversprechen, und es hat scharfe Kanten, die man kennen sollte, bevor man es einsetzt.

Wo es in pi einhakt

Der Cache sitzt zwischen Agent-Loop und Provider:

pi → [L1: RAM Map] → [L2: Redis via LiteLLM] → Provider
     ~138 µs         ~150 ms                1–3 s

Bei before_provider_request hasht die Extension model.id + JSON.stringify(messages) + JSON.stringify(parameters), schlägt in einer Map nach und liefert eine gecachte Antwort zurück, wenn der Eintrag frisch ist. Bei after_provider_response speichert sie die Antwort (mit einer GröBenschätzung auf JSON-Länge-Basis) und stößt die Eviction an. Ein 10-Minuten-setInterval räumt abgelaufene Einträge ab und wird bei session_shutdown sauber beendet.

Die Schlüsselableitung ist inhaltsadressiert: Modell, Messages und Parameter fließen alle in den Hash ein, der Cache antwortet also nur auf Requests, die buchstäblich identisch zu einem bereits gesehenen sind. Er rät nie und generalisiert nicht.

Die Konfiguration läuft über Umgebungsvariablen statt über Config-Dateien:

L1_CACHE_ENABLED=false        # hart aus
L1_CACHE_MAX_ENTRIES=500      # Eintragslimit (Standard 200)
L1_CACHE_MAX_MB=50            # Speicherlimit (Standard 20 MB)
L1_CACHE_TTL=7200             # TTL in Sekunden (Standard 3600)

Zur Laufzeit steuert ein einziger Slash-Command:

/l1-cache stats     # Einträge, MB, Hit-Rate, Init-CPU
/l1-cache clear     # Zähler + Map zurücksetzen
/l1-cache enable    # / disable

Was wir gemessen haben

Wir haben das echte npm-Artefakt (pi-l1-cache@1.2.0) unter Node 22.23 mit den eigenen Test-Hooks der Extension benchmarkt und dann den realen Interceptor-Pfad mit einer gemockten ExtensionAPI durchgespielt — genau so, wie pi Extensions bootet.