Skip to content

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.

  • 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
    Requires Pi 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:prune

    Environment variables

    • CODEARBITER_PRUNE required
      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:sprint

    Environment variables

    • FARM_API_KEY required
      API key for the OpenAI-compatible endpoint that runs the farm workers. Without it, --farm cannot dispatch.
    • FARM_API_BASE_URL optional
      Endpoint base URL for the worker API. Defaults to the OpenCode Zen endpoint when unset.
    • FARM_MODEL optional
      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
    Requires Docker 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.

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

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.

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

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.