Skip to main content
Workers continuing their jobs inside isolated Rooms in the Dorf village

Dorf

Durable AI workers on infrastructure you control.

Dorf makes your coding agent a durable worker—Codex today, more harnesses over time. Give it a job, walk away, and come back to the same work.

Each Worker gets a full development environment for its native tools and workflows. The Room keeps that work isolated from the rest of your infrastructure.

Run a coding Job

Install Dorf and run the one-time guided setup:

uv tool install dorf
dorf setup

See Getting started for current prerequisites and setup details.

Then create a Worker and give it one complete goal:

dorf worker spawn python-developer

dorf job assign build-retry-queue \
  --to python-developer \
  --goal "Build a small Python retry queue with tests, run them, and publish the results as evidence."

dorf job wait build-retry-queue

Close the terminal while the Job runs, then return from another shell:

dorf job inspect build-retry-queue
dorf job message build-retry-queue "Add a test for exponential backoff and publish the new results."
dorf job wait build-retry-queue

Workers do Jobs in Rooms

Resource Meaning
Worker Durable identity around an agent harness
Job Pinned goal with its own conversation and retained evidence
Room Isolated environment supplied by a Room provider

An Assignment records the exact Worker, Job, and Room binding for lifecycle and recovery. Most human-facing commands need only the Worker or Job name.

Workers wrap the harnesses developers already use; they are not a replacement agent framework. The control plane is harness- and sandbox-provider agnostic by design. Codex and local Incus VMs are the only supported adapters today; other harnesses and local or cloud VM providers can fit the same boundaries once validated.

Why Dorf

  • Leave without losing the thread. Worker and Job identity survive the client that started them.
  • Return to the situation, not a transcript. Inspect state, timeline, and evidence without asking the Worker to recap.
  • Let the harness do its best work. Give it a complete development environment and contain that environment with a clear isolation boundary.
  • Build workflows above the runtime. Dorf owns durable execution; applications own policy, acceptance, and presentation.

Alpha status

Dorf is alpha software. See Setup support for current adapters, host requirements, and limitations.

Coding-to-PR showcase

Coding-to-PR is the first application built on Dorf, not the runtime's identity. It takes a coding task from an isolated workspace through checks, review, follow-up, and a PR proposal.

dorf start "Fix the checkout timeout and add a regression test"
# Or leave an issue running unattended:
dorf afk 42
dorf job inspect JOB
dorf job inspect JOB --json  # structured outcome pulse for agents
dorf verify JOB
dorf publish JOB

New coding Jobs use the Provider Connection selected by dorf setup. Pass --provider-connection NAME only to intentionally override that host-local default.

The official dorf-codex image is the coding workstation: repository preparation and checks come from the cloned repository's contract, while GitHub access remains a separately scoped host-side integration. See the North Star for how it fits the broader runtime.

Build on Dorf

Build workflow-specific applications with the experimental Python SDK. It exposes the same Worker, Room, Job, and Assignment controls used by the CLI; coding-to-PR is the first example.

from dorf import Dorf


def run_coding_workflow(task: str) -> str | None:
    with Dorf.open(provider_connection="personal-chatgpt") as dorf:
        dorf.spawn_worker("developer")
        dorf.assign_job(
            "implementation",
            worker_name="developer",
            goal=(
                f"{task}\n\n"
                "Acceptance:\n"
                "- Run the repository checks.\n"
                "- Publish the results as evidence."
            ),
        )
        result = dorf.wait_for_job_input("implementation")
        if result.outcome != "done":
            raise RuntimeError(result.detail or result.outcome)
        return result.response

The SDK is experimental and does not yet carry a third-party compatibility promise. See the Runtime Surface for the current responsibility boundary.

Learn more

Dorf is licensed under the Apache License 2.0.

Metadata

Release files for dorf 0.1.2

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for dorf 0.1.2
File Size Uploaded
dorf-0.1.2.tar.gz 143.6 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for dorf 0.1.2
File Interpreter ABI Platform
dorf-0.1.2-py3-none-any.whl Python 3 none any Details

Total release size: 307.9 kB

Release files / dorf-0.1.2.tar.gz

Download URL dorf-0.1.2.tar.gz
Size 143.6 kB
Tags Source
SHA-256 checksum
How to use checksums
e084c70691820de1112524d6eeaf18aa6b5f837d9fa2e0d5c0ad8facbb22711d
BLAKE2b-256 checksum
How to use checksums
0c113563c6c0f585054e03b6b60191b63686c727e062676f496d7e61643d300f
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 5, 2026.

Transparency log

Release files / dorf-0.1.2-py3-none-any.whl

Download URL dorf-0.1.2-py3-none-any.whl
Size 164.3 kB
Tags Python 3
SHA-256 checksum
How to use checksums
78b452b8e9be33794c502bc6bf02d6b7250c105c2d2f9f4cdefe18d1748235dc
BLAKE2b-256 checksum
How to use checksums
2755188178e84ed720dc3c222d57a444108c8f4f2fd66841fedc55ab591ca324
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 5, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.1.2 This release

2 release files

0.1.1

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page