Verdict first: choose Kilo Code for local-first solo work where open source and local models matter, choose self-hosted Coder Agents for regulated teams that must keep both the agent and its execution inside infrastructure they control, and choose GitHub Copilot agent mode for editor-first developers who want autonomous multi-step coding inside the editors and review flows they already use. Everything below exists to defend that verdict: a criteria grid, per-contender best-for notes, the exact way we tested on our own hardware, and answers to the questions readers actually ask. For background on the rig and the workflow behind these tests, see what fits on a 6 GB RTX 2060, how our local agent team ships, and the September 15 digest that first surfaced all three tools side by side.
How to read this comparison
This is a pilot of a new comparison format: verdict first, then evidence, then method, then questions. Each contender solves a different constraint. Kilo Code is an open-source coding agent that meets you in the editor, the terminal, and the cloud from one portable core. Coder Agents is a fully self-hosted coding agent that runs the agent loop inside the customer-controlled deployment, including air-gapped setups. Copilot agent mode is an autonomous collaborator that plans multi-step solutions, edits code, runs commands and iterates until the task completes. We compare them on the dimensions that decide real purchases: where source code travels, which models you may use, how governance works, which editors are covered, and what the pricing shape looks like. No invented benchmarks appear anywhere in this piece; every product claim links its primary source, and every judgment is labeled as our experience on our hardware.
One more framing note before the grid. Local-first does not mean offline-only. It means the default path keeps prompts, diffs, and history on hardware you control, with explicit escalation when a task genuinely needs a hosted model. Our daily stack runs a quantized 7B model on a 6 GB card for drafting and reserves hosted models for deep research, exactly the pattern described in the VRAM guide. That preference colors the verdict: tools that treat local runtimes as first-class citizens score higher here than tools that treat them as an afterthought, even when the hosted experience is excellent.
Criteria grid
The grid below summarizes the documented position of each product at the time of writing. Follow each link to the primary source before making a buying decision, because shipping details move fast.
| Criterion | Kilo Code | Coder Agents (self-hosted) | Copilot agent mode |
|---|---|---|---|
| Source availability | Open source; public repository with MIT-licensed source | Self-hosted enterprise platform; agent architecture open to inspection and control | Proprietary; documented autonomous collaborator inside Copilot |
| Where the agent runs | Editor, terminal, or cloud; same agent across IDE, CLI, and cloud sessions | Entirely inside your deployment; agent loop, history, and tool execution stay self-hosted with air-gap-capable installs | Inside your editor and hosted runtime; agent edits files and suggests terminal commands from chat |
| Model choice | Hundreds of models at provider pricing plus bring-your-own-key; zero inference markup with local models supported | Teams choose their own models and tools; organizations control models, integrations, and policies | Choice of models from a dropdown, including automatic routing; newest coding models arrive through the weekly changelog |
| Local-model support | First-class via common runtimes; setup documented at the Kilo docs with local-model support on the editor page | Bring-your-own-model inside your perimeter; the agent runs in the control plane with workspaces provisioned only when action is needed | Hosted-model-first; agent mode consumes credits per prompt with enterprise admin controls |
| Governance and isolation | Prompt and context visibility in open source; auditable prompts with no silent model switching | Centralized visibility into prompts, tool calls, models, and spend; governance controls built for enterprise deployment plus a relay mode for mixed cloud-agent plus self-hosted-workspace setups | Enterprise and organization admin controls including sandboxing and permissions; see the weekly Copilot changelog and the agent-mode docs on admin-disabled modes |
| Editor and CLI coverage | VS Code, JetBrains, and CLI from one core; install via marketplace, plugin portal, package manager, or binaries | Chat and API on top of workspaces developers already use; workspaces are created automatically from authorized templates when action is needed | VS Code, Visual Studio, JetBrains, Eclipse, CLI, and web sessions; start from the chat mode dropdown with MCP tool extensions |
| Pricing shape | Provider rates with zero markup, or your own keys and local models; model pricing at cost per the product page | Commercial enterprise offering for self-hosted installs; generally available as a supported enterprise product | Subscription plus usage credits for agent prompts; each agent-mode prompt consumes credits |
Kilo Code: best for local-first solo builders
Kilo Code is the natural default for a reader of this journal: a solo builder on modest hardware who wants agent help without routing every keystroke through a hosted service. The project describes itself as the open-source coding agent for building with AI in VS Code, JetBrains, or the CLI, and the repository is the primary source to check for install paths, supported editors, and current model coverage. The product page adds the economic argument that matters locally: choose the right model without markup or lock-in, including local models and bring-your-own keys. That combination — auditable source plus cost-transparent models — is exactly what a local-first workflow needs, because the agent that drafts your HTML can point at a quantized model on your own card while the agent that needs frontier reasoning can point at a hosted model for one step and come back.
In practice the strengths cluster around portability and transparency. The documentation hub covers setup, models, permissions, and terminal workflows, and the editor page confirms hosted models, bring-your-own-key, and local-model flexibility from the same extension. Because the prompt and context window stay visible in MIT-licensed source, a careful builder can verify what the agent saw before a diff lands — a property our own agent-team workflow depends on, since every handoff here is a file and a checklist rather than a chat transcript. Specialized agent modes let one tool switch contexts without switching tools, which keeps the workspace layout small: role, goal, constraints, and file paths, all under a few hundred tokens, mirroring the scaffold discipline in the VRAM guide.
The honest limitations are the ones any open-source, model-agnostic agent carries. You assemble the stack yourself: pick the runtime, pick the model, configure keys, and decide which steps may call hosted services. Local-model quality on small cards is genuinely good for drafting, summaries, HTML fixes, and short refactors, but it trails hosted flagships on deep research and long-horizon planning — the same split we measured when 7B quantized drafts matched hosted output for short posts yet lost on research depth. Support is community-shaped rather than a single enterprise throat to choke, and fast-moving model coverage means the docs page, not any blog post, is the source of truth. Best for: solo developers, open-source shops, and privacy-sensitive writers who run a small quantized model on their own GPU and want the agent to respect that default.
Coder Agents (self-hosted): best for regulated teams
Coder Agents answers a different question: how does a regulated organization get coding agents without letting source code and execution leave the perimeter. The announcement states the position plainly: a fully self-hosted, air-gap-capable alternative for deploying AI coding on infrastructure the customer controls, with the models and tools they choose. The architecture page sharpens it: the agent loop, chat history, and all tool execution happen within the customer deployment, with no managed component. For teams under financial, healthcare, or public-sector constraints, those two sentences carry the entire purchase: the agent runs where the auditors can see it, on networks the team already operates.
The operational details favor platform teams. Developers keep a familiar workflow while choosing models, tool integrations, and governance policies, and the platform keeps centralized visibility into prompts, tool calls, models, spend, and agent activity. Workspaces are provisioned lazily: the agent runs in the control plane and creates workspaces automatically from authorized templates only when it needs to act on code, with template visibility scoped to each user role. Mixed estates are covered too, because a relay mode lets cloud-hosted assistants execute inside self-hosted workspaces when only part of the stack must stay inside. If your organization already runs the self-hosted development platform, the agent arrives as infrastructure underneath the existing templates rather than as another service to deploy, per the solutions page.
The trade-off is scope: this is an enterprise platform decision, not a weekend extension install. It is commercially available as a supported enterprise offering, which implies procurement, sizing, and operations rather than a marketplace click. Solo builders on one card will find it heavier than an editor extension, and teams without self-hosting experience inherit real operational work. Best for: regulated enterprises and public-sector teams that must demonstrate where code traveled, which models ran, and who approved each tool — the audience for whom air-gap support and centralized governance are requirements, not features.
GitHub Copilot agent mode: best for editor-first developers
Copilot agent mode wins on proximity: the agent lives where the code already lives. The introductory guide defines it as an autonomous collaborator that performs multi-step coding tasks from natural-language prompts, analyzing context, planning solutions, running commands, reaching for external tools, and iterating until done. The product docs describe the daily motion precisely: agent mode determines which files to change, streams edits into the editor, suggests terminal commands, and iterates to remediate issues until the original task completes. Developers pick Agent, Ask, or Plan from the chat mode dropdown, attach working-set files, and review diffs inline — a loop that fits existing editors, review flows, and keyboard habits with minimal relearning.
Two properties extend that loop beyond single-file edits. First, model freshness arrives continuously: the weekly changelog records general availability of newer flagship models inside Copilot alongside orchestration previews, app integrations, code-review automation, and expanded enterprise sandboxing controls. Second, the agent is extensible where developers work: Model Context Protocol servers and custom instructions tailor tools, testing frameworks, and guardrails to each codebase, so agent behavior converges toward team conventions instead of generic output. The docs note the operational caveats honestly: administrators may disable agent mode per organization, and each agent-mode prompt consumes usage credits. Those are the right controls for shared tenants — visibility and budgets stay with the platform team while momentum stays with the developer.
The limitation for this journal's readers is architectural, not qualitative: Copilot agent mode is hosted-model-first, so prompts and diffs travel to hosted services by design. That is a non-issue for most product teams and a deal-breaker for air-gapped ones. Local-model devotees who draft on a 6 GB card with zero per-token cost will feel the difference in both privacy posture and marginal cost per iteration. Best for: professional developers and teams already standardized on hosted forges and editors who want autonomous multi-step help — plan, edit, test, iterate — without leaving the chat panel, as covered in our September 15 digest.
How we tested
Scope honesty: we ran the same three representative tasks through each contender on our own hardware and read every diff ourselves. We report workflow observations only — no synthetic benchmark scores, no invented win rates, no leaderboard. Anything numeric below (word counts, token budgets, timing method) describes our procedure, not a claim about the products.
Our rig is the one documented in the VRAM guide: a 6 GB RTX 2060 with 32 GB of system RAM, one resident quantized model at a time, context capped at 4096 tokens, and hosted escalation only when a draft stalls. The workflow follows the local agent team loop: draft from a template, review in place with explicit checks, board approval before publish, static push with verification. Three tasks stood in for real journal work: add a criteria-grid table to a draft post and validate the markup gate, summarize a 900-word draft to a 120-word standfirst without inventing facts, and convert a checklist-style section into accessible HTML with stable heading anchors. For each run we recorded where prompts traveled (local runtime versus hosted service, per the Kilo provider docs, the Coder control-plane architecture, and the Copilot agent-mode docs), which model was selected and why, whether the agent respected the workspace scaffold, and whether the output passed our publish checks on the first attempt or needed steering.
What we observed, qualitatively: the open-source editor agent stayed local when configured to do so and made its context visible, which suited short drafting and markup repairs on the card; the self-hosted platform agent kept history and execution inside the deployment boundary and shone on permission-scoped workspace tasks, at the cost of heavier setup; the editor-embedded agent needed the least configuration and produced the smoothest multi-file iterations, at the cost of hosted-model dependency and per-prompt metering. Readers should reproduce the procedure rather than trust our adjectives: the docs for the open-source agent, the self-hosted announcement, and the agent-mode introduction each contain enough setup detail to rerun all three tasks in an afternoon.
Questions and answers
Can I run a coding agent entirely on my own hardware?
Closest to yes with the open-source editor agent pointed at a local runtime: the docs describe local-model setups and the editor page lists local-model support explicitly, so drafting, refactors, and markup repairs can stay on your card. Our VRAM guide shows the envelope: quantized 7–8B models fit fully on 6 GB, larger models need partial offload and slow down. Expect to escalate deep research to a hosted model; plan that escalation explicitly rather than discovering it mid-task.
Which option keeps source code inside our perimeter?
The self-hosted platform agent is designed for exactly this requirement: agent loop, history, and tool execution remain within the customer deployment, with air-gap-capable installs and customer-chosen models. The open-source editor agent can also stay local when pointed at local models, but enforcement is configuration rather than architecture. The editor-embedded agent is hosted by design, governed instead by enterprise sandboxing and permission controls.
Which is cheapest for a solo builder?
For marginal cost per iteration, local models win: zero per-token cost after hardware you already own, the pattern behind our daily stack. The open-source agent supports that directly with provider-rate pricing, bring-your-own keys, and local models. The editor-embedded agent meters credits per agent-mode prompt on top of subscription, which is predictable but never zero. The self-hosted platform is priced as a supported enterprise offering, sensible per-seat at organizational scale and heavy for one laptop.
Which needs the least setup?
The editor-embedded agent: open chat, pick agent mode from the dropdown, attach files, and prompt, per the product docs, with custom instructions and tool extensions as optional depth. The open-source agent needs a runtime and model choice via its docs and its install paths. The self-hosted platform needs infrastructure planning around control-plane capacity, templates, and model access.
Where do I go next on this site?
Size your hardware first with the 6 GB VRAM guide, adopt the file-based handoff discipline in the local agent team essay, then catch the wider context in the September 15 digest where open-weight agents, self-hosted coding, and local assistants appeared side by side. This comparison is the pilot of the format; tell us whether the verdict-first grid earned its keep.