Roadmap

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.

​

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.
• Three harness adapters — openhands, claude-code and codex — plus a generic adapter that everything else replays through. See 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.
• 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.

​

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.

​

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 and 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.

​

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 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 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, 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.