open source · MIT · v0.7

Durability for agents.

Agents are loops of LLM calls and tool calls, and sometimes they run long enough for the process underneath them to die. Norns keeps track of each agent's progress, allowing new workers to pick up where crashed ones left off. Your code and your keys stay on your workers.

Named for the three who sit beneath the world tree and spin every thread of fate.

Install

$ brew install nornscode/tap/nornsctl

Walk through the hello example →

$nornsctl runs events 189 cloud.nornscode.com

1 04:08:20 run_started

2 04:08:20 llm_request claude-sonnet-4-6 · step 1

3 04:13:20 retry timeout · attempt 1 · transient

"LLM task timed out — worker may have disconnected"

4 04:13:21 llm_request claude-sonnet-4-6 · step 1

— no worker for 1 h 47 min —

5 06:00:07 llm_request claude-sonnet-4-6 · step 1

6 06:00:11 llm_response 1,980 in · 5 out

7 06:00:11 run_completed

A real run from 2026-10-04: a test message sent to Mimir while its worker was offline. Norns held it, and finished the run when a worker came back.

The three ways a run dies in production.

A buggy tool.

Without Norns

The tool errors, the worker fails, and your orchestrator dutifully restarts it with an empty memory. The run is gone, and so are the eight model calls that came before it.

With Norns

The run's progress is saved outside the worker. Fix the tool, redeploy, and the run picks up at that step.

Timeouts and network errors.

Without Norns

The call times out, the client retries, the tool runs again. You charge the customer twice and explain it to support tomorrow.

With Norns

The retry carries the same key as the first call. The worker recognizes it and returns the original result instead of charging again.

A deploy ships mid-flight.

Without Norns

In-flight runs die with the old workers. Users see half-done tasks vanish.

With Norns

The new workers pick the run up where the old ones left it.

Every run leaves a record of the work.

Each prompt, response, tool call and result, with timestamps, tokens and cost, appended as it happens.

Audit: nornsctl runs events 189 --json is the whole run, step by step: what the model saw, what it decided, what the tool returned.
Evals: Real production runs, not synthetic ones. Pull the logs over the API and run your evals against what actually happened.
Forks and retries: POST /runs/:id/fork from any step, with a different model or system prompt if you like, and compare the two logs. Or send a failed run again from the top.
Cost: Every run knows its own token counts and cost, the sub-agents it launched included.

It has been running Mimir since April.

Mimir is a Slack bot that answers questions about a project from the GitHub repos and pages you point it at. Every Slack thread is a Norns run. Since 2026-04-15 that is 62 threads and 130 runs, with the runtime underneath it redeployed 104 times and Mimir itself 44. Eleven runs failed, each one a provider or request error you can read in its event log; none was lost to a worker going away.

See Mimir Source on GitHub

From zero to a running agent.

Workers run wherever you run them. The orchestrator never sees an API key; it holds the log, dispatches the next step, and waits.

Install and run

$ brew install nornscode/tap/nornsctl
$ nornsctl dev
$ nornsctl new my-agent && cd my-agent
$ uv sync && uv run my-agent-worker

Send a message python

result = client.send_message(
    "support-bot",
    "Where is my order?",
    wait=True,
)

Read the full quickstart Star on GitHub