Book a demo
Backed by Y Combinator

Fork your data
like code.

High-performance file systems for parallel AI workloads.

Book a demoRead the docs
forks
2
bytes copied
0 B

of a 4.2 TB workspace

  • stored once
  • shared by reference
  • written by a fork

Picture: a 4.2 TB workspace called main, drawn as a sheet of solid blocks. Two forks of it, fork-a3f2 and fork-9c41, are stacked with it: fork-a3f2 behind it, up and to the left, and fork-9c41 in front of it, down and to the right. Each fork is drawn as outlines of main's blocks, because it shares them and holds no copy. The few solid blocks in a fork are the ones that fork has written. Bytes copied: 0.

Amulet in four numbers

mount, any size
<100ms
copied per fork
0B
p99 read
1.9ms
sustained per mount
8.4GB/s

Built by researchers and engineers from

Buckets were not built for parallel agents.

Run a fleet on one and you get two bad choices. Copy the data for every agent, or let them share it and overwrite each other.

14:02:11.204agent-01PUT results/eval.jsonl200 OK

14:02:11.911agent-02PUT results/eval.jsonl200 OK

14:02:12.050agent-01GET results/eval.jsonlagent-02's bytes

Both writes return 200 OK. One of them is gone.Diagram, drawn isometrically: two agents sit over a bucket and write the key results/eval.jsonl in one bucket, less than a second apart. Both requests succeed. The second write replaces the first, block by block, and nothing reports it.
copy per agentCopies are slow.
Give each agent its own copy and every run waits on 4.2 TB before it starts.
one shared prefixShared writes are last-writer-wins.
Two agents write the same key. Both get 200 OK. The later write replaces the earlier one.

A faster foundation for parallel AI.

Built for the work that cannot wait

  1. 01/ 04

    Snapshots & branches

    Snapshot, branch, and roll back instantly

    Freeze a clean dataset, branch in milliseconds, and merge or roll back without copying.

    Diagram: a base checkpoint as a stack of four slabs of blocks. Three training runs branch off it. Each run is a thin, nearly empty plate holding only the few blocks it changed.

  2. 02/ 04

    Shared workspaces

    Keep every worker on the same data

    People and agents share one live workspace, so every run picks up where the last one ended.

    Diagram: one workspace as a slab of blocks, with four workers above it, vm-01 to vm-04. Each is tied straight down to the same workspace: one writable namespace, four writers.

  3. 03/ 04

    Protected data

    Experiment freely. Keep your data safe.

    Work survives interruptions, failures, and restarts—ready when you return.

    Diagram: a workspace as a slab of blocks, with three sandboxes above it. One is running. One has been torn down and is drawn dashed; the blocks it wrote are still lit in the workspace. A new one has just mounted the workspace, in under 100 ms.

  4. 04/ 04

    Instant access

    Reach any dataset instantly

    Open what you need fast, from a few gigabytes to an entire data estate.

    Diagram: three stores of data side by side, one of gigabytes, one of terabytes and one a whole data estate, each a taller stack of blocks than the last. One agent sits above them with a line straight to a single lit block in each. p99 read is 1.9 ms.

Mount. Fork. Work. Publish. Restore.

Each step is the operation itself: what was run, what came back, and what changed.

  1. 01/ 05Mount

    Mount in under 100 ms.

    A workspace mounts as an ordinary Linux filesystem in under 100 ms. Its size does not change that.

    p99 read 1.9 ms · 8.4 GB/s per mount

    mount
    <100ms
    p99 read
    1.9ms
    per mount
    8.4GB/s
    agent-01bash
    agent-01 $ amulet mount corpus ./corpus &
    mounted# 4.2 TB in < 100 ms
    agent-01 $ ls ./corpus
    checkpoints datasets evals runs
    Diagram: the branch main, 4.2 TB, at revision v-0214, mounted at the path ./corpus.

  2. 02/ 05Fork

    Fork it. Copy nothing.

    A fork takes milliseconds and copies 0 bytes. Each agent gets a writable workspace; blocks stay shared until a fork writes.

    2 forks · 0 B copied

    sbx-a3f2 · sbx-9c41bash
    sbx-a3f2 $ amulet mount corpus@fork-a3f2 ./work &
    mounted# 0 B copied
    sbx-9c41 $ amulet mount corpus@fork-9c41 ./work &
    mounted# 0 B copied
    agent-01 $ amulet branches corpus
    fork-a3f2 fork-9c41
    Diagram: two branches leave main at v-0214, fork-a3f2 and fork-9c41. Each copied 0 B.

  3. 03/ 05Work

    Every change is a commit.

    Agents read and write plain paths. Each change lands as an immutable, content-addressed commit that records who produced it.

    agent · session · run

    sbx-a3f2bash
    sbx-a3f2 $ python eval.py --suite regress --out ./work/evals
    wrote ./work/evals/regress-0412.jsonl wrote ./work/evals/summary.json# commit c-41d7
    sbx-a3f2 $ ls ./work/evals
    regress-0412.jsonl summary.json
    Diagram: fork-a3f2 gains commits c-9f2c and c-41d7, and fork-9c41 gains c-7be0. Commit c-41d7 changed three blocks, and records agent eval-runner, session s-51c2 and run r-0412.

  4. 04/ 05Publish

    Publish. Conflicts are explicit.

    Publishing is conflict-checked. A stale writer gets an explicit conflict, never a silent overwrite.

    no last-writer-wins

    corpus / main

    Commit history of main, newest first
    RevisionChangeAgentSessionRunState
    1v-0215publish fork-a3f2address 9f2c41d7…e0b3eval-runners-51c2r-0412published
    2—publish fork-9c41base v-0214 · head v-0215address 7be05a19…c44ftrainers-88d0r-0413conflict
    v-0214baselineaddress 2d6e88f0…1a7cingests-17aar-0398published
    • publish fork-a3f2mainv-0215 published
    • publish fork-9c41mainconflict: base v-0214, head v-0215
    1. fork-a3f2 lands on main as v-0215.
    2. fork-9c41 started from v-0214, so its write is refused. Nothing is overwritten.
    3. Each commit names its agent, session and run.
    3

    commit c-41d7

    agent
    eval-runner
    session
    s-51c2
    run
    r-0412
    parent
    v-0214
    address
    9f2c41d7…e0b3
    Diagram: fork-a3f2 is published and main moves to v-0215. fork-9c41, still based on v-0214, tries to publish. Its write is wiped back and flagged as a conflict: base v-0214, head v-0215.

  5. 05/ 05Restore

    Restore any revision, exactly.

    Any published revision can be restored exactly. The same content address means the same bytes.

    same address, same bytes

    corpus / main

    Commit history of main, newest first
    RevisionChangeAgentSessionRunState
    2v-0216restore v-0214identical to v-0214address 2d6e88f0…1a7copss-9e31r-0414restored
    v-0215publish fork-a3f2address 9f2c41d7…e0b3eval-runners-51c2r-0412published
    1v-0214baselineaddress 2d6e88f0…1a7cingests-17aar-0398published
    • restore v-0214mainv-0216, identical to v-0214
    1. Pick any published revision.
    2. main returns to it as v-0216.
    3. Same content address: the same bytes.
    3

    restore exact

    v-0216
    2d6e88f0…1a7c
    v-0214
    2d6e88f0…1a7c
    difference
    0 B
    Diagram: main is restored to v-0214 as a new revision, v-0216, with the same content address.

Agents never hold bucket keys.

An agent gets a path and a token. The credentials and the data stay in the cell.

Short-lived tokens
An agent mounts with a token that expires and is scoped to one workspace.
An ordinary path
The agent sees a filesystem path. Its tools need no storage adapter.
No bucket keys
Agents never hold object-store credentials. No bucket key reaches a sandbox.
Data stays in the cell
Hot and cold data both stay inside the Amulet cell.
Diagram: an agent outside the Amulet cell. It holds a short-lived token scoped to one workspace, and no bucket keys. The token takes it through the wall of the cell to its workspace, which it sees as the path ./workspace. The hot and cold stores behind the workspace are inside the cell, and nothing leads from them to the agent.

Five questions, answered.

Pricing is on its own page
01

What is Amulet?

A high-performance file system for parallel AI workloads. Workspaces mount as ordinary Linux filesystems, fork without copying data, and keep every change as a versioned commit.

02

How fast are mounts and forks?

A mount completes in under 100 ms, regardless of workspace size. A fork takes milliseconds and copies 0 bytes: data is shared until a fork writes.

03

How does versioning work?

Every change is an immutable, content-addressed commit that records the agent, session and run behind it. Publishing is conflict-checked, and any published revision can be restored exactly.

04

Do agents need cloud credentials?

No. Agents mount with short-lived, workspace-scoped tokens and see an ordinary filesystem path. They never hold object-store credentials, and data stays in the Amulet cell.

05

How do I get access?

Amulet is in private beta. Accounts are approved in small batches. Book a demo and tell us about your workload.

See it on your
own workload.

Amulet is in private beta. Accounts are approved in small batches.

Book a demoRead the docs