agentvfs vs Turso agentfs
Single-file agent filesystem
The names are one letter apart, so this page exists to disambiguate. Turso agentfs is a filesystem / storage primitive: a single-file store with copy-on-write and snapshot / time-travel. agentvfs is a workspace runtime and execution boundary: it mounts a vault as a real directory, gates the top-level command an agent runs, and orchestrates forks, checkpoints, and a changed-files report inside your agent loop. They sit at different layers — the layer where bytes live versus the layer where you decide what runs and what to keep — and they can compose rather than compete.
Turso agentfs rows describe its publicly stated shape (a single-file store with copy-on-write and snapshot / time-travel); we do not quote version numbers, API names, or benchmarks. agentvfs rows are grounded in the agentvfs README, ROADMAP, and docs. This page exists to disambiguate a name collision, not to disparage — where the two occupy different layers we mark the row comparable rather than claim an advantage.
| Dimension | agentvfs | Turso agentfs | Advantage |
|---|---|---|---|
| Layer | Workspace runtime + command boundary | Filesystem / storage primitive | Comparable |
| Primary primitive | Vault mounted as a real directory | Single-file store | Comparable |
| Copy-on-write / versioning | Vault versioning + audit | Copy-on-write | Comparable |
| Snapshot / rollback | First-class `checkpoint save / restore` | Snapshot / time-travel | Comparable |
| Forking a workspace | `avfs vault fork` — cheap per-task clone | Not the stated framing (a store, not a runtime) | agentvfs |
| Policy before execution | PolicyEngine: allow / allow_with_checkpoint / deny / require_approval | Not a storage-layer concern | agentvfs |
| Changed-files summary | ChangeSummary in ExecutionEnvelope | Not the stated framing | agentvfs |
| Runs standard CLI tooling | git, cargo, npm, jq run unchanged in the mount | Provides the store the tooling would sit on | Comparable |
| Implementation language | Rust | Publicly stated as a filesystem/storage project | Comparable |
| License | MIT, source on GitHub | Refer to the project's own licensing | Comparable |
| Relationship | The boundary you drop into your agent loop | A store the boundary could sit on top of | Comparable |
Pick agentvfs when
- ▸You want a policy step before the top-level command your agent runs, plus an automatic checkpoint and a structured "what changed" report
- ▸You want the workspace mounted as a real directory so git, cargo, and npm run unchanged, not just a storage layer underneath them
- ▸You want fork, checkpoint save/restore, and a changed-files summary as first-class runtime primitives you drive from your agent loop
- ▸You want an MIT-licensed Rust binary you embed in your own process, with no managed service to depend on
Pick Turso agentfs when
- ▸You need a single-file storage primitive with copy-on-write and snapshot / time-travel as the place your bytes actually live
- ▸You are choosing the filesystem / storage layer rather than the command boundary and orchestration around it
- ▸You already run agentvfs (or another runtime) and want to compose it over a single-file store like this one
- ▸Your question is about durability and time-travel of the underlying store, not about gating or reporting on command execution
They often compose.
It is reasonable to run agentvfs inside Turso agentfs. The proxy boundary handles the agent-aware concerns (vault, fork, checkpoint, policy, change summary); Turso agentfs handles the lower-level isolation. Pick the pair that matches your threat model.