> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xorcise.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Roadmap

> What XORCISE does today, what carries an experimental label, and what is not built yet — with no dates attached.

This page is the state of XORCISE as we know it. It exists because parts of the product name things that do not work yet — a **Coming soon** badge, an experimental label, a command that prints a placeholder — and you should be able to look those up rather than discover them mid-task.

We do not put dates on anything here. When an item moves, this page moves with it.

<Note>
  Released versions and their changes are on the [GitHub releases page](https://github.com/xorcise-ai/xorcise/releases).
</Note>

## What is shipped

The whole single-machine loop works today, and it is the loop the rest of this documentation describes.

* Register an agent, install a mission from the free library, create a run, connect your agent, and read a score.
* Two mission types: `lab`, which brings up live targets on a per-run private network, and `static`, which ships attachments instead. See [Missions](/concepts/missions).
* Three harness adapters — `openhands`, `claude-code` and `codex` — plus a generic adapter that everything else replays through. See [Agents](/concepts/agents).
* OpenTelemetry ingest on both the traces and the logs signal, replayed as a timeline, a terrain map, and an event feed.
* Grading in two fixed halves, deterministic checks and an LLM judge, with re-evaluation of a finished run from the web UI, the REST API, and `xorcise run regrade`. See [How grading works](/concepts/grading).
* The free mission library, which needs no account, key, or sign-in.
* A web UI and a command line that reach the same state for every shared task, mapped row by row in the [CLI reference](/reference/cli).

## What is experimental

Two surfaces inside the product are labelled experimental by the CLI itself, and are not finished. We ship them because the CLI would otherwise hide the shape of the work, not because they are ready. A third ships outside the product altogether.

**Distributed and multi-machine operation.** `xorcise serve --role` accepts five roles, and only `all` is a complete install. `control` accepts a run and returns a run id without ever launching a container, so a run created against it never executes. `runner` and `headscale` serve a health endpoint and nothing else. `xorcise role show` and `xorcise role list` report the same thing and mark every role but `all` as experimental. Run XORCISE on one machine until we say otherwise.

**Multi-machine network addresses.** `xorcise config set-network` sets the Headscale URL and the advertised host for that unfinished path. It is command-line only, and the **Settings** page shows those addresses read-only rather than offering to change them.

**Playbook benchmarks.** `xorcise-playbooks` runs several models through the same missions and renders one eval card ranking them. It is a skill in the `xorcise-skills` repository rather than part of XORCISE: it drives a normal install over the REST API, adds nothing to the product, and is versioned separately — so nothing on this page and no release note here covers it. It also spends real money, since a benchmark is a matrix of full agent sessions. See [Evaluate Agents with Playbooks](/experimental/playbooks).

## What is not built yet

Each of these is referenced somewhere in the product or the ecosystem, so you may have seen it and wondered.

### Mission authoring and bundle ingestion

Missions in this release come from the free XORCISE library. Installing a mission from a bundle you wrote yourself is not part of it. `xorcise mission ingest` is a disabled stub: every form of the command, with or without a path, prints that ingesting your own mission bundle is coming soon and points you back at `xorcise mission list` and `xorcise mission pull <id>`. The **Ingest a bundle** button on the **Missions** page is still present and still clickable, but it opens a coming-soon preview of the feature rather than a directory picker, and it ingests nothing.

What is gated is those two surfaces, not the machinery behind them: the REST API's `POST /api/missions/ingest` and `GET /api/missions/ingest/{job_id}` are implemented and functional. The [mission manifest reference](/reference/mission-manifest) and [Author a mission](/guides/author-a-mission) stay accurate and are worth reading — they describe the format the feature will accept, so a bundle you prepare now is a bundle you can ingest when this lands.

<Note>
  To get missions today, browse the library with `xorcise mission list` and install one with `xorcise mission pull <id>`, or use the **Missions** page in the web UI. No account, key, or sign-in.
</Note>

### Multi-user sign-in and roles

The **Settings** page marks this **Coming soon**, and that is accurate: there is no sign-in, no user record, and no permission model. Today the REST API and the OTLP receiver have **no authentication at all**. They bind loopback plus the Docker bridge gateway by default, so every local process and every container on that bridge can already read your runs and traces, change your configuration, and start runs; widening the bind extends that to the network. Until this ships, reachability is the access control — [Security and isolation](/operate/security) sets out how to place it.

### Harness adapters beyond the three

`openhands`, `claude-code` and `codex` are the complete list of built-in adapters. `xorcise agent list` renders friendly display labels for a handful of other slugs, so an agent registered as `gemini` prints as `Gemini CLI`. Nothing sits behind those labels — no replay adapter, no telemetry provider, no launch command — and such an agent replays through the generic adapter exactly as a blank one does. The label is a rendering artefact, not support. We intend to add adapters, and we are not naming which ones until one exists.

### Sign-in and remote registries

`xorcise auth` is a hidden command that prints a placeholder, and `xorcise remote list` is the same. Neither does anything today, and neither is needed: the mission library is open and asks for no credential. They are the beginnings of pulling missions from registries other than the XORCISE catalog, which is not built.

### Cost estimation

Run statistics report token counts, call counts, and timings, and the cost field alongside them is unpopulated because no estimator ships. Treat an empty cost as "not measured", not as "free" — [what grading costs](/concepts/grading#what-grading-costs) explains where the spend actually occurs.

## Ask for something

What we build next is shaped by what people report. Open an issue or start a discussion on [GitHub](https://github.com/xorcise-ai/xorcise), and tell us which of the items above is blocking you rather than merely missing — that distinction is the one that moves work up the list.