Chidori: durable, replayable TypeScript agents on an embedded Rust runtime
The agent framework where every run is durable, replayable, and resumable by default.
At a glance
- What is it?
- Chidori records every LLM call, tool call and HTTP request as a host call so runs can be checkpointed, replayed with zero token spend, and resumed in a new process. The trade-off is that determinism only holds as far as that one boundary reaches.
- Who is it for?
- Chidori fits teams that already write agent logic in TypeScript and have been burned by unreproducible runs, re-billed debugging cycles or multi-hour human approval waits, and who can accept that durability stops at the host call boundary. It does not fit you if your agent logic lives in Python, if you need a durable workflow engine that also orchestrates non-JavaScript services, or if your side effects happen outside the runtime's host functions.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The failure mode Chidori is built around
An agent run is non-deterministic, expensive and long. The README lists the consequences directly: a bug that surfaces three runs deep and cannot be reproduced, a debugging cycle that re-bills the same tokens, a crash halfway through a multi-step run that loses everything, and an approval step that forces a process to stay alive for hours. These are not four separate problems. They are one problem with four symptoms, and the symptom that matters most is the first one, because without reproduction you cannot debug the other three.
The intended audience is narrow enough to state plainly: developers writing agent logic in TypeScript who want the durability guarantees of a workflow engine without adopting a workflow engine's programming model. The README is explicit that agents are plain async TypeScript rather than a graph or a DSL, with native if/for/try, real imports and editor tooling. If your agents are already Python functions calling an SDK, Chidori is not a drop-in; there is a Python SDK, but the README describes it as a thin client for driving the runtime over HTTP, not as a place to put agent logic.
One boundary: every side effect becomes a host call
The mechanism is a single chokepoint. Every side effect an agent performs, whether an LLM call, a tool call or an HTTP request, flows through the runtime as a recorded host call. Agents never touch the world directly. The README's framing is that because the runtime sees and records everything, it can log, cache, replay, pause and resume from that record.
That is the whole architecture, and its elegance is also its constraint. Determinism is enforced by runtime policy rather than by the agent author: a fixed clock and seeded randomness mean a replay is the same run, not an approximation of it. The README claims replay is byte-identical and costs zero tokens, and that checkpointing happens at every host safepoint. Note the word safepoint. A run is durable at the points where it crosses the boundary, not at arbitrary lines of TypeScript. Anything your agent does that does not go through a host function is outside the recorded record, and the README does not describe a general mechanism for capturing that.
The runtime itself is a single Rust binary with an embedded pure-Rust JavaScript engine. No Node, no Deno, no V8, no native bindings. SDKs talk to it over HTTP. That choice buys the no-dependency install and costs you the ability to reach for the npm ecosystem inside an agent, since the engine is not Node and the README does not claim Node compatibility.
Install, and the two packages people confuse
The fastest install is the prebuilt binary:
curl -fsSL https://raw.githubusercontent.com/ThousandBirdsInc/chidori/main/scripts/install.sh | sh
It downloads the platform binary from the latest GitHub release, places it in ~/.chidori/bin, and prints a PATH tweak if one is needed. Verify with chidori --version. The script covers macOS on Apple Silicon and Intel, and Linux on x86_64 and arm64; release pages list per-platform tarballs if you prefer to fetch by hand.
Alternatives exist. cargo install chidori builds from source and needs a stable Rust toolchain 1.95 or newer, landing the binary in ~/.cargo/bin. Cloning the repository and running cargo build --release puts it at ./target/release/chidori and also gets you the bundled examples/ directory. The repo pins its toolchain through rust-toolchain.toml, so cargo picks the right version automatically.
The distinction worth internalising: the chidori binary is the runtime, while the npm package @1kbirds/chidori and the PyPI package chidori are SDKs, thin optional clients for driving the runtime over HTTP from a TypeScript or Python application. Installing the SDK does not install the runtime. The README states you do not need the SDKs to run agents, and it does not state a version compatibility matrix between SDK and runtime, which is the kind of gap that bites at upgrade time.
Pausing for humans without holding a process open
The most concrete payoff in the README is chidori.input() and named signals. Both suspend the run to disk rather than blocking a process. A human or another agent can answer minutes or days later, and the run resumes from the stop point. The documentation for signals lives in docs/signals.md, which is where the naming and delivery semantics would be, and that file is not reproduced in the material available here, so the exact matching rules between a signal name and a waiting run cannot be confirmed from what is on hand.
The related trick is treating a checkpoint as a test. The README proposes committing a recorded run to git and asserting the agent's behaviour has not drifted. That is a full integration test that costs nothing in tokens and, per the README, runs in milliseconds. It is a genuinely different testing posture from mocking an LLM client, because the recording is the real call log from a real run rather than a hand-written stub. The catch is the same boundary as before: the test detects drift in the code paths that cross host calls, and says nothing about logic that does not.
Prompt caching is folded into the same layer. The README states stable prefixes are auto-marked for the provider cache, which it puts at roughly 10 percent of base input rate on Anthropic, and that replay pays nothing at all. That figure is the project's own claim about a third-party provider's pricing, not a measurement, and provider cache rules change.
Where the model breaks down
The honest limitation is the one the design implies. Durability is a property of host calls, so the guarantee is only as complete as the host call surface. An agent that shells out, writes a file through some path the runtime does not intercept, or calls a library that opens a socket directly is performing an unrecorded side effect, and replay will not reproduce it. The README does not claim otherwise, but the marketing sentence (every side effect flows through the runtime) is stronger than the mechanism (every side effect that goes through a host function).
A second constraint is the engine. Because the runtime embeds a pure-Rust JavaScript engine rather than Node, you cannot assume arbitrary npm packages work inside an agent. The README's promise is no Node, no Deno, no V8, which is a packaging benefit and an ecosystem cost at the same time. Anything relying on Node built-ins or native addons is a question mark, and the material here does not answer it.
Third, the release cadence is fast. v3.6.0, v3.7.0 and v3.8.1 landed between early July and late August 2026, with the last push to main in September 2026. Fast minor releases are normal for a young project, but they raise the odds that a checkpoint written by one version needs care when read by another, and no statement about on-disk format stability appears in the material.
Temporal is the comparison that matters
The closest analogue is Temporal. Both make a run durable by recording what happened and replaying it on recovery. The difference is where the boundary sits and what the unit of durability is.
Temporal asks you to structure work as workflows and activities, with determinism rules imposed on the workflow code and side effects pushed into activities. The programming model is a constraint you adopt up front, and the durable unit is the activity. Chidori inverts this: you write ordinary async TypeScript, and the durable unit is the host call, which the runtime inserts at the points where your code touches the outside world. There is no workflow definition to declare and no activity to annotate. The README's claim is that every await chidori.* is a durable, replayable safepoint.
That is a lower-friction model for agent code specifically, because agent code is mostly a sequence of LLM and tool calls, which are exactly the operations Chidori intercepts. Temporal's advantage is breadth: it is a general durable execution system for services, not only agents, and its determinism rules are documented in far more depth than the material available for Chidori shows. If your durable work is a payment saga rather than a chain of prompts, Temporal's model is the better fit. If your durable work is an agent whose steps are prompts and tool calls, Chidori's boundary lands in the right place by default.
Licence, upgrades and what to pin
The project is Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. It also requires that you preserve notices and state significant changes. That is a summary of the licence identifier, not legal advice; if you are embedding the runtime in a distributed product, read the LICENSE file in the repository and get your own counsel.
Upgrade cost is the part to plan for. Three minor releases in roughly two months, a Rust toolchain floor of 1.95 for source builds, and no published statement about checkpoint format stability in the material available here. The practical move is to pin the runtime version in CI, keep the recorded checkpoints you use as tests under version control alongside the code that produced them, and re-record rather than migrate when a checkpoint fails to replay after an upgrade. Source builds also carry the cost of tracking the pinned toolchain in rust-toolchain.toml, which is small but non-zero for a team without Rust experience.
The SDKs add a second version axis. The npm package @1kbirds/chidori and the PyPI package chidori are separate artifacts from the binary, and nothing in the material states which SDK version pairs with which runtime version. If you drive the runtime over HTTP from a TypeScript application, check that pairing before you upgrade either side.
Editorial conclusion
Chidori fits teams that already write agent logic in TypeScript and have been burned by unreproducible runs, re-billed debugging cycles or multi-hour human approval waits, and who can accept that durability stops at the host call boundary. It does not fit you if your agent logic lives in Python, if you need a durable workflow engine that also orchestrates non-JavaScript services, or if your side effects happen outside the runtime's host functions. Verify first that your provider mix is covered by the host call surface, that the SDKs on npm and PyPI match the runtime version you install, and that the checkpoint format survives a minor upgrade: the release cadence between v3.6.0 and v3.8.1 spans roughly two months, so pin the binary version in CI rather than tracking latest.
Community notes