Comparison By Hsin, Head of Product

Containarium vs Kilo: one agent runtime, or many?

Your best reviewer is a Claude agent. Your fastest drafter is Codex. Your cheapest summarizer runs on Gemini. Today they live in three terminals, share one laptop, and hand each other work through you. The question this post answers: do you want one great agent that can call many models, or a platform where many different agents work together?

Kilo is the first. Containarium is the second. Both answers are good. They are just answers to different questions.

Disclosure: we build Containarium, so we're biased. Every Kilo fact below comes from Kilo's own site, docs and GitHub repository as of November 2026. Every Containarium fact comes from our open-source code, and we say plainly where a feature is still new or limited.

What Kilo is, and what it does well

Kilo (often still called Kilo Code) is an MIT-licensed, open-source coding agent. It runs as a VS Code extension, a JetBrains plugin, a CLI, and a hosted Cloud Agent you start from the browser. Its CLI is a fork of OpenCode. It is very good at the job most developers actually have: one person, one repo, an agent in the editor.

  • Model breadth. 500+ models at the provider's price with no markup, or your own keys. You can switch models mid-task.
  • Agents and subagents. Built-in Code, Plan, Ask and Debug agents, plus custom subagents that each can pin their own model and that a primary agent calls through a Task tool.
  • Parallel sessions. The Agent Manager runs several sessions side by side, each in its own git worktree, and can run one prompt as up to four parallel versions with a different model on each.
  • A careful cloud design. Kilo's Cloud Agent keeps your real GitHub and Kilo tokens out of the sandbox and hands it short-lived, container-bound stand-ins instead.

If that is your workflow, Kilo is a strong choice and you may not need us. Read on if your workflow is starting to look less like "my agent" and more like "our agents."

The real difference: many models vs. many runtimes

Kilo's multi-agent features are many Kilo agents. They can call different models, but they share Kilo's harness, its tools, and its configuration. Kilo's own docs say Agent Manager sessions use the same sign-in, provider settings, BYOK keys, MCP servers and permission rules as the sidebar. A worktree separates the files and the git branch, not the machine. On Kilo's Cloud Agent, each user gets one isolated Linux container, and all of that user's chats share it.

Containarium starts from the other end. The unit is not a chat session; it is a box: a real, persistent Linux environment (an LXC container or a Kubernetes pod) on infrastructure you own, or on our hosted cloud. Each agent gets its own box, and the agent inside can be a different runtime:

  • Coding-agent CLIs in a box. containarium code run starts Claude Code, OpenAI's Codex CLI, or pi inside a box as a detached run. The run keeps going after your laptop disconnects, and you reattach later from the exact byte where you left off.
  • Agent skills with an engine per skill. A skill is a packaged agent: a box, a system prompt, a set of allowed scopes and a list of allowed peers. Each skill's manifest names its engine: claude (Claude Agent SDK), codex (Codex SDK) or gemini (Google Gen AI SDK). You can override the engine and the model for each member at run time.
  • Crews and task graphs. A crew wires skills together as a pipeline, an orchestrator, or freeform. A task graph goes further: independent nodes run in parallel (five at a time by default), and each node waits only for the nodes it depends on.

So the positioning is simple. Kilo gives one excellent agent access to many models. Containarium lets many different agents, with different models, runtimes and skills, work on one job, each in its own box.

At a glance

Containarium compared with Kilo across seven dimensions
Dimension Kilo Containarium
Primary unit of work An agent session in your editor, terminal or browser A box (Linux environment), plus skills, crews and task graphs that run in boxes
Agents and models One runtime (Kilo); 500+ models; subagents and up to 4 parallel versions with different models Several runtimes: Claude Code, Codex CLI and pi in boxes; claude, codex and gemini engines for skills, chosen per member
Isolation Git worktree per local session; one container per user on Cloud Agent, shared by that user's chats One box per agent; each task-graph node gets fresh boxes; per-box network policy
Persistence Local worktrees persist; Cloud Agent containers are ephemeral, and idle sessions are deleted after 7 days in beta Boxes persist across sessions; skill boxes are reused across runs
Governance and tenancy Organization profiles, admin-managed settings, sandbox-bound credential stand-ins Per-skill scoped tokens, enforced allowed_peers, one audit trace per run, multi-tenant control plane
Interface VS Code, JetBrains, CLI, web, Slack CLI, platform MCP server, REST/gRPC API, an MCP server inside every box
Licensing MIT Apache 2.0 (open source); a hosted Cloud is optional

Kilo details checked against kilo.ai, its docs and github.com/Kilo-Org/kilocode in November 2026. Products change; check current docs before deciding.

What a heterogeneous split looks like

Say you want a change reviewed from two angles before anyone edits code. Define two skills in your own catalog: one on Codex, one on Claude. Containarium loads external catalogs from a directory at startup, so you don't need to rebuild anything. 

# skills/reviewers.yaml  (loaded from CONTAINARIUM_SKILLS_DIR)
skills:
  - id: security-review
    name: Security Review
    description: Reviews a change for security issues.
    recipe_id: agent-runtime
    system_prompt: You review code for security issues. Return JSON findings.
    allowed_scopes:
      - containers:read
    allowed_peers: []
    engine: codex
  - id: api-review
    name: API Review
    description: Reviews a change for API compatibility.
    recipe_id: agent-runtime
    system_prompt: You review code for breaking API changes. Return JSON findings.
    allowed_scopes:
      - containers:read
    allowed_peers: []
    engine: claude

Then write a task graph. The two reviews have no edge between them, so they run at the same time, each in its own fresh box. The third node waits for both. It is the built-in diff-crew, a two-member pipeline where one agent drafts a change and a second finalizes it against its own checkout of the same commit. 

# plan.yaml
goal: Review the change from two angles, then draft the fix
nodes:
  - id: security
    goal: Find security issues in the change
    skill_id: security-review
  - id: api
    goal: Find breaking API changes
    skill_id: api-review
  - id: fix
    goal: Address both sets of findings
    crew_id: diff-crew
edges:
  - { node_id: fix, depends_on: security }
  - { node_id: fix, depends_on: api }
containarium crew run freeform-crew --plan plan.yaml --concurrency 5 \
  --git-source https://github.com/<org>/<repo> --git-ref <commit-sha> \
  --server <host>

The daemon validates the whole graph before it creates any box. Every member checks out the same pinned commit into its own workspace, so they share the code through git, not through a shared filesystem. Each downstream node receives its dependencies' outputs as JSON. If one review fails, the fix is blocked, but the other review still finishes, and the final status keeps every node's result.

For the issue-to-PR case there's a ready-made pipeline: engineer-crew runs an implementer, then a reviewer, then a test runner. The test runner runs the repository's tests in its own box and produces the proof pack, and the platform refuses a crew whose proof comes from the coder's box. On Containarium Cloud, the engineer crew can be started from a GitHub issue on a connected repo and opens a pull request.

Why separate boxes matter once agents talk to each other

When one person runs one agent, the person is the safety boundary. When agents hand work to other agents, something else has to be. Containarium's answer is that the boundary belongs to the platform, not to the prompt:

  • Scoped tokens per skill. Each run mints a platform token limited to that skill's declared scopes. A typo in a scope fails at load time. It never silently grants too much.
  • Declared peers, enforced. An agent may call only the peers its manifest lists. The API rejects any other call before traffic leaves. A crew whose topology needs an edge the manifests don't allow is rejected before any box exists. On Linux you can also arm an eBPF egress allowlist so the kernel drops the traffic.
  • One trace per run. Every agent-to-agent hop is audit-logged under a shared trace id, and each member writes a JSON-lines journal you can tail with containarium crew logs.
  • Keys out of the box. Agent boxes can call a daemon-side model gateway instead of holding a long-lived provider API key, and token usage is metered per tenant and per skill.

Kilo solves part of this well too: its Cloud Agent keeps real tokens out of the sandbox. The difference is scope. Kilo protects one user's agent sessions. Containarium governs a crew of different agents across tenants on one control plane.

Where we're honest about today

Mixed-engine crews are new. Per-skill engine routing is implemented and unit-tested, and the open-source catalog ships a reference two-engine crew (a Claude member handing off to a Codex member). The live CI lane that runs it against both providers is wired but has not run yet. Gemini's structured output is prompt-only for now.

Parallelism lives in task graphs. A plain pipeline runs its members in order. An orchestrator or freeform crew without a plan hands the task to its entry agent. To run independent work at the same time, give the crew a task graph, as above.

Cloud and self-host differ. The task-graph path is in the open-source daemon. Containarium Cloud's catalog lists the reference crews, the diff crew and the engineer crew today. The engineer crew needs the Pro plan, and the two-engine reference crew is not in the Cloud catalog yet.

It's not an editor. Containarium has no in-editor autocomplete and no IDE panel. Your agents run in boxes; you drive them from a CLI, an MCP client or the API.

Shared kernel. Boxes are containers, not microVMs. For genuinely hostile code, that is a weaker boundary, and we say so in a separate post.

How to choose

↳ One developer, one repo, an agent in the IDE with any model? Kilo.

↳ A few parallel attempts at one task, compared side by side? Kilo's Agent Manager does this well on your own machine.

↳ Claude, Codex and Gemini agents on one job, each with its own environment and credentials? Containarium.

↳ Agents that keep a persistent box, run detached, and live on infrastructure you own? Containarium.

↳ Both? They aren't exclusive. Kilo supports MCP servers, and every Containarium box exposes one.

Keep reading

Put your agents on one platform.

Run the open source on your own VM, or start free on the hosted cloud and give each agent its own box.

Try Containarium Cloud Star the open source