Chidori: Durable TypeScript-Agenten auf einer Rust-Laufzeit
The agent framework where every run is durable, replayable, and resumable by default.
Auf einen Blick
- Was ist das?
- Chidori verlegt jeden Seiteneffekt eines Agenten durch einen Host-Call-Log und macht Läufe dadurch checkpoint-, replay- und resume-fähig. Eine Einordnung für Teams, die LLM-Agenten mit Wiederaufnahme statt mit Graph-DSLs bauen wollen.
- Für wen ist es gedacht?
- Chidori passt zu Teams, die lange laufende TypeScript-Agenten mit LLM-Aufrufen, menschlichen Freigaben und teuren Debugging-Zyklen betreiben und dafür keine Graph-DSL lernen wollen. Wer bereits Temporal oder Restate produktiv einsetzt, tauscht einen ausgereiften Cluster gegen eine einzelne Binärdatei und verliert dabei die dortigen Wiederholungs- und Timeout-Primitive.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 6 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Rust, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Das Problem: nicht reproduzierbare, teure, lang laufende Agenten
Ein Agent, der einen Bug erst im dritten Lauf zeigt, ist ohne Aufzeichnung praktisch nicht zu debuggen. Jeder Reproduktionsversuch kostet erneut Token, weil die LLM-Aufrufe live wiederholt werden. Bricht der Prozess mitten in einer mehrstufigen Kette ab, ist der bisherige Fortschritt verloren. Und eine Freigabe durch einen Menschen bedeutet nach dem README, einen Prozess über Stunden offen zu halten. Diese vier Punkte nennt das Projekt selbst als Ausgangslage. Adressiert sind damit Entwickler, die Agenten in TypeScript schreiben und LLM-Aufrufe, Tool-Aufrufe sowie HTTP-Requests als teure, nicht deterministische Operationen behandeln. Wer nur einen einzelnen, kurzen Prompt gegen ein Modell schickt, hat keines dieser Probleme und braucht Chidori nicht.
Ein Grenzübergang: der Host-Call als einziger Weg nach draußen
Die Mechanik hängt an einer einzigen Regel. Jeder Seiteneffekt, also jeder LLM-Aufruf, Tool-Aufruf und HTTP-Request, läuft als sogenannter host call durch die Laufzeit. Der Agent berührt die Außenwelt nie direkt. Weil die Laufzeit damit jeden Seiteneffekt sieht, kann sie ihn protokollieren, cachen, erneut abspielen, anhalten und ab dem Haltepunkt fortsetzen. Das ist die eigentliche Architektur, alles andere folgt daraus.
Ein Replay führt denselben Code gegen das Call-Log aus und bekommt laut README jeden aufgezeichneten Prompt-, Tool- und HTTP-Aufruf sofort zurück, ohne Token zu verbrauchen und mit identischem Ergebnis. Die Determinismus-Zusage stützt sich auf Laufzeitrichtlinien wie eine feste Uhr und seed-basierte Zufälligkeit, nicht auf eine nachträgliche Angleichung. Checkpoints entstehen an jedem host safepoint. Wird der Prozess beendet, spielt ein neuer Prozess das Log bis zum Haltepunkt ab und arbeitet danach live weiter. Für Wartezeiten auf Menschen gibt es chidori.input() und benannte Signale, die den Lauf auf die Platte suspendieren. Erwähnenswert ist die Prompt-Cache-Anmerkung: stabile Präfixe werden laut README automatisch für den Provider-Cache markiert, mit rund zehn Prozent der Basisrate bei Anthropic. Das ist eine Anbieterangabe aus der Projektdokumentation, kein unabhängig gemessener Wert.
Installation: eine Binärdatei, zwei optionale SDKs
Der schnellste Weg führt über das Installationsskript:
curl -fsSL https://raw.githubusercontent.com/ThousandBirdsInc/chidori/main/scripts/install.sh | sh
Es lädt die passende Binärdatei für macOS (Apple Silicon oder Intel) oder Linux (x86_64 oder arm64) aus dem neuesten GitHub-Release, legt sie in ~/.chidori/bin ab und gibt bei Bedarf einen PATH-Hinweis aus. Die Prüfung erfolgt mit chidori --version. Alternativ lässt sich das Tarball pro Plattform manuell von der Release-Seite holen.
Wer aus den Quellen baut, nutzt cargo install chidori, womit die Binärdatei in ~/.cargo/bin landet. Dafür ist laut README eine stabile Rust-Toolchain ab 1.95 nötig. Ein Checkout plus cargo build --release erzeugt die Binärdatei unter ./target/release/chidori und bringt zusätzlich die gebündelten examples/ mit. Das Repo pinnt seine Toolchain über rust-toolchain.toml.
Wichtig ist die Paketaufteilung, die das README ausdrücklich klarstellt: Die hier installierte Binärdatei ist die Laufzeit. Die Pakete auf npm (@1kbirds/chidori) und PyPI (chidori) sind die SDKs, also dünne, optionale Clients, die die Laufzeit über HTTP ansprechen. Es gibt keine nativen Bindings und kein Node. Die JavaScript-Engine ist in Rust eingebettet. Wer die SDKs weglässt, spricht die Laufzeit direkt über HTTP an.
Replay als Testfall, Pause als Zustand auf der Platte
Zwei Konsequenzen aus dem Call-Log sind praktisch relevant. Erstens lässt sich ein aufgezeichneter Lauf als Checkpoint in git einchecken und als Integrationstest verwenden. Der Test kostet dann nichts und läuft nach Angabe des Projekts in Millisekunden. Das ist eine andere Kategorie als ein Test, der gegen ein echtes Modell geht und bei jedem Durchlauf driftet.
Zweitens verschwindet die Notwendigkeit, für eine menschliche Freigabe einen Prozess offen zu halten. Der Lauf wird auf die Platte suspendiert, die Antwort kann Minuten oder Tage später kommen, und der Lauf setzt an derselben Stelle fort. Das ist der Punkt, an dem sich Chidori von Frameworks unterscheidet, die Orchestrierung über dem Chaos der Seiteneffekte aufbauen, statt die Seiteneffekte selbst zu erfassen. Ein Graph oder eine DSL ist hier nicht nötig: Der Agent ist gewöhnliches async/await-TypeScript mit if, for und try. Jedes await chidori.* ist bereits ein dauerhafter, replaybarer Haltepunkt, ohne dass Schritte annotiert oder Activities definiert werden.
Wo das Modell an seine Grenzen stößt
Die zentrale Einschränkung folgt direkt aus dem Entwurf. Die Garantien gelten nur für Seiteneffekte, die als host call durch die Laufzeit fließen. Ruft der Agent einen HTTP-Client direkt auf, statt über chidori.* zu gehen, liegt dieser Aufruf außerhalb des Call-Logs. Er wird weder aufgezeichnet noch replayed noch beim Resume berücksichtigt. Der Determinismus ist also keine Eigenschaft der Sprache, sondern eine Eigenschaft der Disziplin, jeden Seiteneffekt über die Laufzeit zu leiten. Das README nennt die Regel, aber es beschreibt nicht, wie die Laufzeit einen Verstoß erkennt oder meldet.
Ein zweiter Punkt ist die Bindung an die eingebettete Engine. Weil kein Node, Deno oder V8 zum Einsatz kommt, ist die verfügbare JavaScript-Umgebung nicht identisch mit der eines Node-Prozesses. Das README führt das als Vorteil (keine Laufzeitabhängigkeiten), aber für ein Projekt, das auf npm-Pakete mit nativen Bindings oder Node-spezifischen APIs angewiesen ist, ist es ein Ausschlusskriterium. Drittens ist die Replay-Zusage an die Laufzeitrichtlinien gebunden, etwa feste Uhr und seed-basierte Zufälligkeit. Alles, was der Agent an Nichtdeterminismus von außerhalb der Laufzeit bezieht, untergräbt diese Zusage. Und schließlich: Für einen einzelnen kurzen Modellaufruf ist der Apparat aus Call-Log, Checkpoints und Resume überdimensioniert.
Abgrenzung zu Temporal und Restate
Die naheliegende Alternative für dauerhafte Ausführung ist Temporal. Der Unterschied im Ansatz ist grundlegend. Temporal verlangt, dass Arbeitsabläufe in Workflows und Activities zerlegt werden, mit deterministischen Workflow-Definitionen und explizit als Activities markierten Seiteneffekten. Der Entwickler entscheidet also, was ein dauerhafter Schritt ist. Chidori dreht das um: Jeder Seiteneffekt, der die Laufzeit passiert, ist automatisch ein Haltepunkt, und der Agent bleibt gewöhnliches TypeScript ohne Schrittannotation. Dafür bringt Temporal einen ausgereiften Betriebsapparat mit, den Chidori in dieser Form nicht beschreibt. Wer Wiederholungsstrategien, Timeouts und Backoff auf Infrastrukturebene braucht, findet sie dort als etablierte Primitive.
Restate verfolgt einen ähnlichen Gedanken der dauerhaften Ausführung, setzt aber ebenfalls auf explizite Dienstgrenzen und einen eigenen Betrieb. Chidori wählt den entgegengesetzten Rand: eine einzelne Rust-Binärdatei ohne Laufzeitabhängigkeiten, in der die Durability aus dem Host-Call-Log entsteht. Der Preis für diese Einfachheit ist, dass es keinen Cluster und keine verteilte Koordination gibt, jedenfalls nicht laut dem vorliegenden Material. Wer horizontale Skalierung über mehrere Knoten mit gemeinsamer Zustandshaltung braucht, muss das außerhalb von Chidori lösen.
Wartung, Versionierung und Lizenz
Das Projekt ist nicht archiviert. Der letzte Push liegt auf dem 10. September 2026, die letzten Releases sind v3.8.1 vom 30. August 2026, v3.7.0 vom 29. Juli 2026 und v3.6.0 vom 7. Juli 2026. Das ist ein Rhythmus von etwa einem Minor-Release pro Monat über den Sommer 2026. Wer auf v3 aufsetzt, sollte mit regelmäßigen Minor-Upgrades rechnen. Ob diese Upgrades Breaking Changes enthalten, geht aus dem vorliegenden Material nicht hervor, das lässt sich nur anhand der Release Notes selbst klären.
Die Lizenz ist Apache-2.0. Das erlaubt kommerzielle Nutzung, Modifikation und Weitergabe unter den Bedingungen dieser Lizenz, einschließlich der Beibehaltung von Copyright- und Lizenzhinweisen sowie einer Klausel zu Patenten. Das ist eine Einordnung, keine Rechtsberatung. Wer die Binärdatei weiterverteilt oder ein Produkt darauf aufbaut, sollte die konkreten Pflichten aus Apache-2.0 mit der eigenen Rechtsabteilung prüfen. Ein Hinweis auf eine kommerzielle Edition oder Supportverträge findet sich im vorliegenden Material nicht.
Für wen sich der Aufwand lohnt
Der Nutzen skaliert mit der Laufzeit und den Kosten eines Agenten. Je länger ein Lauf dauert, je mehr LLM-Aufrufe er enthält und je häufiger er auf eine menschliche Entscheidung wartet, desto mehr wiegen Replay ohne Tokenverbrauch und Resume nach einem Absturz. Ein Agent, der in Sekunden durchläuft und einen einzigen Modellaufruf macht, gewinnt nichts. Ein Agent, der eine Stunde läuft, mehrere Tools aufruft und zwischendurch auf Freigabe wartet, gewinnt fast alles.
Die entscheidende Prüfung vor der Adoption ist keine Frage der Leistung, sondern der Abdeckung. Man sollte im eigenen Code nachsehen, ob jeder Seiteneffekt tatsächlich über chidori.* läuft oder ob irgendwo ein HTTP-Client oder ein Tool direkt aufgerufen wird. Jeder solche Aufruf ist eine Lücke im Call-Log und damit eine Stelle, an der Replay und Resume nicht mehr greifen. Wer diese Disziplin nicht durchhält, bekommt die Zusagen des Frameworks nur teilweise.
Redaktionelles Fazit
Chidori passt zu Teams, die lange laufende TypeScript-Agenten mit LLM-Aufrufen, menschlichen Freigaben und teuren Debugging-Zyklen betreiben und dafür keine Graph-DSL lernen wollen. Wer bereits Temporal oder Restate produktiv einsetzt, tauscht einen ausgereiften Cluster gegen eine einzelne Binärdatei und verliert dabei die dortigen Wiederholungs- und Timeout-Primitive. Vor der Adoption sollte man prüfen, wie sich ein abgebrochener Lauf mit chidori.input() über einen Prozessneustart hinweg verhält und ob die eigene Tool-Schicht vollständig über chidori.* läuft, denn ein direkt aufgerufener HTTP-Client liegt außerhalb des Call-Logs.
Community-Notizen