Run Claude Code/Codex/OpenCode on a sandbox in autopilot. Call the harnesses via a CLI or API's through an OpenCode-compatible API spec.
lite login
lite claude-code
lite claude-code
claude-sonnet-4-6 · localhost:4096 · sess_a1b2c3
/clear to reset history · Ctrl+C or "exit" to quit
❯ monitor CI every hour and fix any bugs
⠙ thinking…
✓ bash {"command":"gh run list --limit 5"}
I'll set up a recurring CI monitor. Checking the last 5 runs now...
lite opencode
lite opencode
claude-sonnet-4-6 · localhost:4096 · sess_d4e5f6
/clear to reset history · Ctrl+C or "exit" to quit
❯ dm github stargazers daily
⠙ thinking…
✓ bash {"command":"gh api /repos/LiteLLM-Labs/lite-harness/stargazers"}
Got 42 new stargazers. Drafting DMs...
Supported agents: opencode
claude-code
github-copilot
codex
export MASTER_KEY=$(openssl rand -hex 32)
echo "MASTER_KEY: $MASTER_KEY"
docker run -p 4096:4096 \
-e LITELLM_API_BASE=https://your-litellm-gateway \
-e LITELLM_API_KEY=sk-... \
-e MASTER_KEY="$MASTER_KEY" \
ghcr.io/litellm-labs/lite-harness:latest
Open localhost:4096, paste the master key on the login page.
Needs a LiteLLM gateway. Full config: docs/configuration.md.
By default, sessions (history, model context) are lost when the server restarts. To keep them across restarts, mount persistent storage at the data directory:
Docker:
docker run -p 4096:4096 \
-v ./data:/home/sandbox/.local/share/lite-harness \
-e LITELLM_API_BASE=... \
-e LITELLM_API_KEY=... \
-e MASTER_KEY=... \
ghcr.io/litellm-labs/lite-harness:latest
Custom path (e.g. a mounted cloud volume at /mnt/data
):
-e DB_PATH=/mnt/data/db.db
On restart the server logs hydrated N session(s) from db
and all prior sessions are immediately available.
Set E2B_API_KEY
or DAYTONA_API_KEY
and agents get an isolated Linux sandbox automatically. Full options (templates, snapshots, vault): docs/configuration.md.
We built lite-harness because running opencode and claude-code as separate servers got hard to maintain - multiple services, different API specs, unreliable session management, different inputs for MCP tools and system prompts.
So we wrapped all harnesses in an OpenCode-compatible server and put it in one Dockerfile, giving us one service to maintain, with shared MCP tools, prompts, and session management across all harnesses.
API reference · Architecture · Configuration · CLI · Add a harness
MIT