What's in the Forge
This is the current contents of the Feature Forge: every codeArbiter feature in preview right now. Preview features are opt-in and off by default. This list is generated from the same allowlist that stamps the preview badge on the reference pages, so it stays in step with them automatically.
Currently in Preview
Section titled “Currently in Preview”- ca-pi (Pi governance adapter) preview
Brings the shared codeArbiter governance core to Pi with a rich footer, permission and plan modes, bounded background work, native compaction, and hardened child dispatch. Its promotion matrix is green; the preview label remains while broader real-world host and workflow coverage accumulates.
Opt in:pi install git:github.com/arbiterForge/codeArbiter@ca-pi-v<version>. Details
RequiresPi 0.80.5 or 0.80.10, Node.js 22.19+, and Python 3.Help it graduate: use it in real repositories and report any host or workflow mismatch.
- Live transcript pruning preview
Reclaims room in a long session's context window by trimming transcript bulk (tool-output sidecars, oversized results, folded thinking, stale file reads) at safe boundaries, while keeping the message chain and the most recent turns verbatim.
Opt in:CODEARBITER_PRUNE=dry. Reference for /ca:pruneEnvironment variables
CODEARBITER_PRUNErequired
The opt-in switch, with three modes: off (default, fully dormant), dry (logs what it would trim without touching the transcript), and on (active pruning).
Help it graduate: run it in dry mode and send the log.
- Pluggable execution farm preview
Routes each implementation task to worker agents running in isolated git worktrees, behind the same review chain and hard gates as a normal sprint. It changes who writes the code, never whether it is reviewed, so you can put a cheaper or different model on the keyboard without loosening a single gate.
Opt in:/ca:sprint --farm. Reference for /ca:sprintEnvironment variables
FARM_API_KEYrequired
API key for the OpenAI-compatible endpoint that runs the farm workers. Without it, --farm cannot dispatch.FARM_API_BASE_URLoptional
Endpoint base URL for the worker API. Defaults to the OpenCode Zen endpoint when unset.FARM_MODELoptional
Pin a specific worker model id. Normally left unset so the dispatch skill auto-selects one.
Help it graduate: run it on a real sprint and report the results.
- ca-sandbox (local Codespace) preview
A local Codespace equivalent: clone an untrusted repo into an ephemeral, host-isolated Docker container and explore it under isolation that holds by construction (cap-drop ALL, non-root, read-only root, offline by default), not by trust.
Opt in:install the ca-sandbox plugin. Details
RequiresDocker and nixpacks on PATH.Help it graduate: explore real repos in it, run --with-claude, and report back.
When this list changes it is because a feature entered or left the Forge: a new preview was added, or one was promoted to stable and is now on by default for everyone.
How Each Preview Works
Section titled “How Each Preview Works”Each feature above is in preview for the same reason: it works, but it has not yet earned the evidence to be on by default. Here is what each one actually does, and why it is worth turning on.
ca-pi (Pi governance adapter)
Section titled “ca-pi (Pi governance adapter)”ca-pi brings the same checked-in .codearbiter/ state and generated governance core used by
Claude Code and Codex to Pi. It includes the rich parent footer, final tool wrappers, explicit
execute permissions, read-only plan mode, bounded session-only background work, native compaction,
diagnostics, and hardened child dispatch.
The automated contracts and hosted Windows, macOS, and Linux promotion matrix are green. The open question is breadth: real repositories, providers, terminals, and long-running workflows can expose integration edges that a bounded matrix cannot. The adapter is available now and use is welcome. Its Feature Forge status records that codeArbiter is still collecting that evidence rather than claiming 100% validation or stable status.
The payoff: teams moving to Pi can keep the same governed project state and working discipline without maintaining a second policy implementation. Install a pinned Git tag from the Pi guide and report any mismatch between the documented contract and live behavior.
Live transcript pruning
Section titled “Live transcript pruning”A long Claude Code session dies when its transcript fills the context window. Most of that weight is
not conversation. It is toolUseResult sidecars, oversized tool outputs, folded thinking blocks, and
stale file reads that no longer matter. The pruner trims that bulk at safe quiescence points (after a
turn settles, at compaction) while leaving three things untouched: the uuid/parentUuid chain that
threads the conversation, every line type (including future ones it does not recognize), and the most
recent tool-bearing turns, kept verbatim.
The gains land when you resume or compact the session, not on the current turn, because the running
CLI replays its in-memory history to the API rather than re-reading the file. The opt-in is staged for
exactly that reason: CODEARBITER_PRUNE=dry runs the full analysis and logs every cut it would make
without ever touching the live transcript, so you accumulate evidence that it is safe before you let it
write anything. Three tiers (gentle, standard, aggressive) control how hard it trims. See the
/ca:prune reference for the modes and tiers.
The payoff: a session that would have hit the wall keeps going, and it does so without losing the thread of what you were doing.
Pluggable execution farm
Section titled “Pluggable execution farm”--farm swaps the engine that writes implementation code without touching anything that decides
whether that code is good. On a normal /ca:sprint, a premium subagent implements each task. With
--farm, Claude still writes the spec, the failing tests, and the plan; then a pool of worker agents
picks up each task in its own isolated git worktree and works until the test passes. Claude reviews the
result and merges it.
The point is the seam. A worker cannot redefine the gates, only pass them. Every task the farm reports
green still runs through the same spec-compliance, quality, and fresh-verification reviews a premium
sprint uses, plus two zero-token guards the dispatcher adds: a literal-leak check that rejects code
which merely hard-codes the value the test asserts, and a mutation pass that perturbs the worker’s code
and re-runs the test to confirm the test actually constrains it. Tasks run in parallel, each isolated,
and a circuit breaker aborts the run if too many tasks escalate, a sign the chosen model is not up to
the slice. Best-of-N sampling (FARM_SAMPLES) takes it further, drawing several candidates per task in
parallel and accepting the first that clears the gate.
The payoff: you can route implementation to a cheaper or different model and keep the exact same safety
chain. The behavior that protects you does not change; only who types the first draft does. The
autonomous sprints guide walks through a --farm run end to end.
ca-sandbox (local Codespace)
Section titled “ca-sandbox (local Codespace)”ca-sandbox is a separate sibling plugin for one job: running code you do not trust without exposing
your machine. Give it a repo URL and it clones the code into a Docker named volume (never onto your
host filesystem), builds a dependency-cached image with nixpacks, and starts a container you can
explore.
The isolation holds by construction, not by trust: --cap-drop ALL, non-root, a read-only root
filesystem, no-new-privileges, the source mounted only at /work/repo, and no bind mount, no docker
socket, never --privileged. Network defaults to offline; clone-then-cut fetches dependencies at
build time and then cuts egress. --with-claude runs Claude Code inside the box under hardened
defaults through a separate gated routine, so you can point an agent at unfamiliar code from inside the
cage.
The payoff: it is a local Codespace for the moment you want to actually run an unknown repo (build it, test it, let an agent poke at it) and be certain the worst it can do is trash a throwaway container.
Turning One On
Section titled “Turning One On”See Using features still in the Forge for how to enable a preview feature and what to expect while it is still in the Forge.