Lite-Harness Turns Coding Agents Into Team Infrastructure — and Makes the Harness the Product

Lite-Harness is not interesting because the world needed another chat box for coding agents. It is interesting because it treats Claude Code, OpenCode, Codex, and GitHub Copilot-style agents as interchangeable workers behind a team control plane. That is the architectural line the agent market keeps trying to avoid drawing: the model is not the product, and increasingly the individual terminal UX is not the product either. The product is the harness.

LiteLLM-Labs launched Lite-Harness as a self-hosted server for deploying coding agents across a team through CLI, API, and Slack. The README lists support for opencode, claude-code, github-copilot, and codex. The example flow is telling: deploy a scheduled outreach agent, check whether the runtime supports sandboxing and vaults, store credentials, create the agent, attach a cron schedule, run a test, and route approval through an inbox. That is not a toy assistant flow. That is job-runner vocabulary.

The repo is young — created on May 27, pushed again early May 31, and sitting at 18 stars and 3 forks during research — so nobody should confuse this with finished infrastructure. But early projects are useful when they reveal where the pressure is. Lite-Harness is pointed directly at the bottleneck teams hit after the first wave of Claude Code adoption: once agents run on schedules, touch credentials, post in Slack, and operate in sandboxes, “which model answered?” is no longer the first operational question. The first questions become: who authorized this run, what workspace did it touch, which secrets were mounted, where are the logs, what happens after restart, and who approves side effects?

The harness boundary is where the real product starts

The architecture docs make one particularly good decision: harness selection is a per-session immutable property set at POST /session. After the first message, the stored harness routes every request. That sounds like plumbing until you imagine the alternative. A Claude Code session and an OpenCode session do not have identical semantics around tools, memory, event streams, prompts, compaction, or errors. Letting callers swap harnesses mid-session would produce the kind of ghost bugs that only reproduce after a long transcript, a partial tool call, and a tired engineer asking Slack why the bot edited the wrong branch.

Locking the harness at session creation is boring in the best way. It makes behavior auditable. It lets logs tell a coherent story. It forces migration to be explicit: if you want to move work from one harness to another, create a new session and accept the boundary. That friction is not a UX failure; it is the cost of preserving state integrity.

Lite-Harness takes a different stance on models. Model selection is per-message, not per-session, and the adapter proxies GET /v1/models to a LiteLLM gateway. That maps neatly onto the economic reality of coding agents in 2026. Teams want cheap models for routine turns, stronger models for hard reasoning, provider-specific routing for procurement, and enough flexibility to switch without rebuilding the workflow. The catch is that model routing without traceability is just vibes with a dropdown. If a session can change model per turn, every turn needs model, provider, latency, usage, failure, and cost metadata joined to the harness event stream. Otherwise the team will know it saved money only until the first incident review asks which model made the destructive recommendation.

Slack, sandboxes, vaults, cron: the dangerous good stuff

The reason this project matters for Claude Code teams is not the unified UI. It is the combination of Slack, scheduled runs, sandbox hooks, vault injection, approvals, and persistence. Those are exactly the ingredients that turn an individual coding assistant into shared infrastructure. They are also the ingredients that turn a harmless demo into an internal platform with a blast radius.

The docs wire sandbox support for E2B and Daytona, and vault injection through VAULT_URL and VAULT_PROXY_TOKEN. That is the correct direction. A coding agent that runs as a team service should not share the developer’s full machine, ambient credentials, and unfiltered network. But the rollout work is larger than adding a sandbox provider. Teams need repo-scoped credentials, network egress policy, secret redaction, artifact retention, default-deny external sends, and approval messages that include enough context for a human to make a real decision. “Approve?” is not an approval workflow. “This agent wants to send this exact payload to this external system using this credential from this sandbox after reading these files” is closer.

The in-memory session warning is also not a footnote. Lite-Harness says session state is in memory by default and does not survive restart unless persistent storage is mounted. For local exploration, fine. For scheduled team agents, that is a production-readiness gate. If an agent runs every four hours with credentials, a process restart cannot erase the audit trail, orphan pending approvals, or lose enough state that retry behavior becomes guesswork. Before using this for unattended work, kill the process mid-run, restart it, test session hydration, recover approvals, inspect stuck-run behavior, verify sandbox cleanup, and confirm events are durable enough for a later incident review.

There is a broader lesson here for every team experimenting with Claude Code. The first phase of adoption is personal productivity: one developer, one terminal, one repo, one model subscription. The second phase is coordination: Slack entry points, scheduled tasks, shared credentials, multiple harnesses, and model routing. The second phase needs platform engineering discipline, not more prompt polish. You need ownership, logging, policy, and failure modes documented before the clever bot gets a cron schedule.

Lite-Harness may or may not become the durable implementation. It is early, lightly adopted, and still carrying obvious “do not skip this” warnings around persistence. But it is directionally right because it names the real category. Coding-agent adoption will not be won by another attractive chat surface wrapped around a model. It will be won by the boring layer that can operate agents safely: sessions, routing, sandboxes, vaults, approvals, cron, persistence, telemetry, and recovery.

The market is splitting into model surfaces and harness surfaces. Claude Code, Codex, OpenCode, Copilot, Cursor, and others will keep competing on developer experience and model integration. Teams will still need a control plane that makes those agents schedulable, governable, observable, and cheap enough to run. That is why Lite-Harness is worth watching even at 18 stars. It looks less like a finished product than a correct diagnosis.

Sources: Lite-Harness README, Lite-Harness architecture docs, Lite-Harness configuration docs, HN Show HN item