Independent Open-Source Coding Agent Field Guide

The verdict

The right coding agent depends on your interface, model path, permission controls, and tolerance for operational complexity. The retained evidence does not support a single overall winner.

The six agents in this guide solve different problems. OpenCode combines terminal and desktop interfaces with broad provider flexibility. Codex CLI is a terminal agent closely integrated with OpenAI’s documented model and account paths. OpenHands is closer to an agent platform, spanning SDK, server, web, and task-runner architecture. Cline is the cohort’s IDE-first candidate and also ships separately versioned CLI, SDK, and desktop tracks. goose combines terminal, desktop, and API surfaces under provider-neutral governance. Qwen Code documents terminal, IDE, desktop, SDK, and daemon surfaces.

Use those differences to build a shortlist before you spend time on setup. This guide does not determine which agent writes better code, behaves more safely, costs less, or succeeds more reliably. The project verified official-source identity and license boundaries, pinned six installations, exercised local interfaces, and qualified benchmark materials. A later five-agent exploratory edition failed its prospectively frozen coverage gate, so its incomplete performance outcomes remain withheld.

Choose by interface, model-control path, permission envelope, operational burden, maintenance evidence, and documentation quality. Then test the exact version and surface you intend to use in a disposable repository.

For a fast shortlist, start with OpenCode, Codex CLI, goose, or Qwen Code for terminal-first work; Cline for an IDE-centered workflow; and OpenHands for SDK/server architecture. These are product-fit categories, not performance recommendations.

Freshness at a glance

Last updated: August 23, 2026. Last official-source verification: August 22, 2026. The table separates the latest documented release from the exact version and surface checked locally. Freshness describes evidence recency and version alignment only—not product quality, safety, performance, or rank.

Agent	Latest documented version	Exact locally checked version	Freshness status
OpenCode	v1.18.21	CLI 1.18.21	Evidence current
Codex CLI	0.149.0	CLI 0.149.0	Evidence current
OpenHands	Core v1.15.0	CLI 1.16.0 with SDK 1.21.0	Surface-specific
Cline	CLI 3.0.57	CLI 3.0.56; CLI 3.0.57 offline smoke	Retest pending
goose	v1.47.0	CLI 1.47.0	Evidence current
Qwen Code	v0.22.0	CLI 0.21.15; CLI 0.22.0 offline smoke	Retest pending

Evidence current means the dated official evidence and local version align. Retest pending means a newer release has only a narrower local check than the retained tested version. Surface-specific means the latest documented and locally checked releases belong to different product lines. None of these labels is a recommendation.

Change log

v1.5.1 — August 23, 2026: made the repaired interface visual timeless so the article’s visible verification date remains the single source of truth.
v1.5 — August 23, 2026: repaired the interface-landscape visual and added a visible last-updated date. Product claims and benchmark conclusions are unchanged.
v1.4 — August 23, 2026: added this public freshness panel and change log. Product claims, tested-version disclosures, and benchmark conclusions are unchanged.
v1.3 — August 23, 2026: removed the old provisional title framing, tightened decision guidance, and corrected the OpenHands product boundary.

What this guide can tell you

This independent field guide compares verifiable product characteristics that remain useful even when a benchmark is inconclusive: what qualifies for inclusion, which interface you install, where the open-source boundary ends, how models are configured, which controls are documented, and what operational work is likely before safe adoption.

The “best fit to investigate” notes are editorial fit: disclosed inferences from documented product shape. They are not endorsements or benchmark winners. No company paid for placement, and no maintainer was contacted to influence this edition.

Comparative benchmark outcomes are intentionally absent. The compact-v9 exploratory edition produced 111 valid cells out of 180, leaving 69 unresolved; 13 required security cells exhausted the edition’s only permitted infrastructure retry. Because its frozen coverage rule could no longer be satisfied, no per-agent success rates, cost comparisons, security grades, rankings, or winner claims are publishable from it.

Evidence labels used throughout

Every material statement uses one of five evidence labels:

Documented: supported by an official repository, release, license, or first-party product document refreshed through August 22, 2026.
Locally checked: observed in a pinned local installation, offline interface/configuration check, or deterministic non-agent qualification.
Retained observation: preserved runtime or infrastructure evidence explicitly excluded from comparative product claims.
Editorial fit: a labelled inference from documented product shape, not a benchmark result.
Unknown: not established by the available official sources or valid local checks.

“Current” below means the latest release identified at the evidence cutoff, not what is necessarily current when you read this. “Locally checked” names the exact surface and version. “Local inference supported” means an official route was documented; it does not validate output quality, speed, compatibility, cost, privacy, or a particular model/provider pairing.

Eligibility rules and product taxonomy

To qualify for this guide, a candidate needed a publicly inspectable agent-core repository under an OSI-approved license; a coding-agent workflow capable of reading or changing a repository; an identifiable official distribution or reproducible installation path; current first-party documentation; and enough official and local evidence to distinguish the exact product surface. All six remain conditionally eligible. Conditional means the product identity and open-source boundary are established, while capability, security, performance, or cross-surface claims still require version-specific validation.

The taxonomy separates product shape from quality:

Terminal-first agent: conversational or noninteractive repository work centered on a CLI.
IDE-first agent: review, context, and approvals centered on an editor integration.
Desktop companion: a locally installed graphical surface distinct from the CLI or IDE track.
Agent platform: SDK, server, daemon, API, or web components intended for systems integration.
Model-control posture: vendor-hosted, bring-your-own-provider, local/self-hosted, or a documented combination.

A project may occupy several categories. Breadth is not a score: supporting five surfaces can add deployment options and also add versioning, policy, and support complexity.

The six agents at a glance

Agent	Documented surface	Current official release at cutoff	Exact locally checked surface	Open-source boundary	Evidence status
OpenCode	Terminal and desktop	v1.18.21	CLI 1.18.21	MIT repository; hosted sharing and model services separate	Conditional
Codex CLI	Terminal, SDK, App Server	0.149.0	CLI 0.149.0	Apache-2.0 CLI, SDK, and App Server; IDE extension and cloud excluded	Conditional
OpenHands	Core, SDK, agent server, web; separate CLI line	Core v1.15.0	Separate CLI 1.16.0 with SDK 1.21.0	MIT core; OpenHands Cloud separately uses PolyForm Free Trial	Conditional; tested surface is distinct and excluded from the later five-agent edition
Cline	IDE, CLI, SDK, desktop	CLI 3.0.57; Desktop 0.0.15; VS Code 4.1.10 captured	CLI 3.0.56 benchmark-bound; CLI 3.0.57 offline smoke only	Apache-2.0 repository code; hosted services and model providers separate	Conditional; tracks are independently versioned
goose	Terminal, desktop, API	v1.47.0	CLI 1.47.0	Apache-2.0 code/specifications; documentation separately CC-BY-4.0	Conditional
Qwen Code	Terminal, IDE, desktop, SDK, daemon	v0.22.0	CLI 0.21.15 benchmark-bound; CLI 0.22.0 offline smoke only	Apache-2.0 framework; hosted inference services separate	Conditional

Figure 1. Interface coverage matrix derived from the six retained agent records. A dot communicates a documented product surface—not quality, safety, or rank. Open the visual for a full-size view.

Maintenance and operational complexity snapshot

All six canonical repositories showed a current release on August 20–22, 2026. That is evidence of recent release activity, not proof of long-term maintenance quality. Stars, download counts, and release velocity are intentionally excluded as quality scores.

Agent	Release evidence at cutoff	Installation shape checked	Operational complexity to plan for	Documentation signal
OpenCode	v1.18.21, August 21	Single CLI package with isolated config; desktop is separate	Contained CLI setup; complexity rises with provider choice, sharing, and desktop use	Official provider and sharing guides captured
Codex CLI	0.149.0, August 20	Single CLI package; account/API route plus sandbox policy	Contained CLI, but identity, model availability, approval mode, and OpenAI service boundary must be explicit	Strong official CLI, open-source-boundary, and security documentation captured
OpenHands	Core v1.15.0, August 21	Platform-like core plus SDK/server/web; separately versioned CLI checked	Platform-like surface and isolation burden; container/runtime expectations matter	Detailed SDK and persistence material, but product-line naming requires care
Cline	CLI 3.0.57 and Desktop 0.0.15, August 21; VS Code 4.1.10 captured	Independently versioned IDE, CLI, SDK, and desktop tracks	Multi-track setup; permissions, storage, telemetry, and versions must be validated per surface	Detailed authorization and CLI references captured
goose	v1.47.0, August 21	CLI plus desktop/API routes; provider and extension configuration	Moderate setup; provider, extension profile, state, keyring, and outer network policy need attention	Provider, configuration, governance, and license sources captured
Qwen Code	v0.22.0, August 22	CLI plus IDE/desktop/SDK/daemon surfaces	Multi-surface setup; safe mode, sandbox, provider, extension, and telemetry settings need explicit control	Repository, settings, and privacy documents captured

The complexity descriptions are operational categories, not grades. A platform-like architecture may be exactly what an engineering team needs and unnecessary burden for a solo developer. A contained CLI is easier to trial but may expose fewer integration surfaces.

Choose by situation, not by logo

You want a terminal-first daily driver

Start with OpenCode, Codex CLI, goose, or Qwen Code. All four have documented terminal surfaces and a locally checked noninteractive or help surface in this snapshot. Your next filter should be model path: Codex CLI’s reviewed official route is OpenAI-centric, while OpenCode, goose, and Qwen Code document local or compatible endpoint options.

This does not make the latter three equivalent. OpenCode’s documented sharing behavior, goose’s extension/profile model, and Qwen Code’s safe-mode, sandbox, and telemetry settings create different operational questions. A terminal label tells you where the conversation happens; it does not tell you who controls the model, what can run without approval, or where state is stored.

You primarily work inside an IDE

Cline is the cohort’s IDE-first candidate by documented product shape. Its official repository spans IDE, CLI, SDK, and desktop products, and its documentation covers command policy and multiple model routes. The catch is version identity: Kingy reviewed the VS Code v4.1.10 line, benchmark-bound CLI 3.0.56, and later checked CLI 3.0.57 offline; GitHub’s latest release at cutoff was the separate Desktop 0.0.15 track. A finding for one track cannot be silently transferred to another.

Qwen Code also documents an IDE surface, but this pilot’s local check covered its CLI package. If editor integration is the deciding factor, validate the exact extension version, storage behavior, permission controls, and model configuration you plan to deploy.

You are building an agent system rather than choosing a chat interface

OpenHands deserves attention because its official materials describe an SDK and agent server with code, file, shell, and web tools, plus structured persistence. Qwen Code documents SDK and daemon surfaces, goose documents API use, and Codex exposes an open-source App Server and SDK boundary.

The important question is no longer “Which chat feels best?” It is whether the surface has the lifecycle, isolation, event stream, persistence, and approval semantics your system requires. Kingy did not exercise these system surfaces end to end, so treat them as documented capabilities awaiting implementation-specific validation.

You require local inference or provider portability

OpenCode, OpenHands, Cline, goose, and Qwen Code each have a documented local or compatible-endpoint route in the captured official sources. The exact route differs: OpenAI-compatible endpoints for OpenCode; local-model documentation for OpenHands; Ollama and LM Studio for Cline; Ollama, Ramalama, and vLLM for goose; and Ollama/vLLM paths for Qwen Code.

Kingy’s reviewed Codex CLI sources established ChatGPT and OpenAI API use but did not establish a supported local-model path. That is an unknown, not a claim that no such route can exist in another version or unsupported configuration.

Local inference is also not synonymous with local operation. A locally running agent can still fetch packages, share sessions, call update services, load extensions, or send telemetry. Verify the whole data path.

You want the easiest security story

No candidate earns that label from this evidence. All six can read files, and their useful modes can edit code or invoke commands. Kingy’s intended controlled evaluation therefore required an outer policy for repository scope, host-home access, network egress, credentials, and verifier isolation. In-agent switches were treated as defense in depth, not proof of confinement.

Where the open-source boundary ends

An open-source agent can still depend on a proprietary model, hosted inference service, account system, marketplace, or enterprise layer. Evaluate at least three boundaries separately: the agent code, the model/inference path, and surrounding hosted services.

Agent	Core license in audited sources	Included in the open-source determination	Explicit boundary or caveat
OpenCode	MIT	Canonical repository, terminal agent, desktop application code	Hosted sharing infrastructure and third-party model services are outside the core-license finding
Codex CLI	Apache-2.0	CLI, SDK, and App Server source	OpenAI documentation explicitly places the IDE extension and Codex cloud outside this open-source component boundary
OpenHands	MIT core	Core, agent server, and core container images	OpenHands Cloud is separately distributed under PolyForm Free Trial 1.0.0 and is excluded; the separately packaged CLI is also a distinct release line
Cline	Apache-2.0	Repository code for IDE, CLI, SDK, and desktop tracks	Optional hosted Cline services and third-party providers are outside the agent-core determination
goose	Apache-2.0 code/specifications	Canonical executable code and specifications	Governance records documentation under CC-BY-4.0; this does not change the executable code license
Qwen Code	Apache-2.0	Repository framework across terminal, IDE, desktop, SDK, and daemon surfaces	Hosted Qwen, Alibaba Cloud, and third-party inference services have separate terms

The OpenHands row illustrates why a single “open source: yes” badge is inadequate. Its core is MIT, while the separate OpenHands Cloud product uses PolyForm Free Trial 1.0.0; its checked CLI also does not represent every current OpenHands surface. Codex has a different boundary: the audited CLI, SDK, and App Server sources are Apache-2.0, while adjacent branded products are outside that determination. Accurate product naming is part of the evidence in both cases.

Model-control paths

Agent	Hosted route documented	Bring-your-own-key or provider choice	Local/self-hosted route documented	Validated for comparison?
OpenCode	Yes	Yes; provider-oriented configuration	Yes; local OpenAI-compatible endpoint example	No
Codex CLI	Yes; ChatGPT or OpenAI API path	OpenAI API credential path documented	Unknown in reviewed official sources	No
OpenHands	Yes	Provider credential path	Yes; local-model use documented	No
Cline	Yes	Yes; BYOK and multiple providers	Yes; Ollama and LM Studio documented	No
goose	Yes	Yes; provider-neutral configuration	Yes; Ollama, Ramalama, vLLM, compatible endpoints	No
Qwen Code	Yes	Yes; configurable provider paths	Yes; Ollama and vLLM documented	No

Figure 2. Documented model-control routes at the evidence cutoff. A populated cell means an official path was captured; it does not mean Kingy validated compatibility, quality, privacy, or cost. Open the visual for a full-size view.

The final column matters most. Configuration parsing and documented compatibility do not prove that a specific model/account combination works, that the agent captures provider-reported usage correctly, or that two agents receive identical model behavior. Model-backed attempts occurred later, but the edition failed its coverage gate; none is accepted for comparative publication.

Permissions, telemetry, persistence, and the real trust boundary

Permission controls

Coding agents are useful because they cross boundaries ordinary chatbots do not. They can inspect repositories, alter files, invoke processes, load tools, and sometimes use the network. The safe operating unit is therefore not “the agent” alone; it is the agent plus its outer execution envelope.

Codex CLI’s official security documentation describes OS-enforced sandboxing and approvals, with network disabled by default. Cline documents command-policy controls. Qwen Code exposes safe-mode and sandbox settings. OpenHands’ checked headless CLI, however, always auto-approves actions, making outer isolation essential. goose and OpenCode also required external repository, state, and network controls in Kingy’s planned harness.

None of those observations supports a cross-product safety rank. The pilot did not run a valid security evaluation. It supports a deployment rule: put the repository, commands, network, and secrets under controls you own.

Figure 3. The control model used to design Kingy’s evaluation harness. It is a recommended architecture, not a claim that any candidate passed a security benchmark. Open the visual for a full-size view.

Agent	Captured official-source finding	What remains unresolved
OpenCode	Sessions are local by default; explicit sharing uploads conversation history and metadata until unshared	A definitive product-wide first-party telemetry classification was not established
Codex CLI	The checked installation froze documented OpenTelemetry exporters to `none` and disabled user-prompt logging in its adapter configuration	A definitive product-wide classification and runtime egress audit remain unestablished
OpenHands	Agent-server telemetry exporter defaults to none; optional PostHog/HTTP exporters exist; local GUI analytics is described as consent-gated	Behavior varies by surface; the checked CLI lacked a documented universal disable switch
Cline	SDK event guidance respects opt-out paths; rollout feature-flag evaluation has a separate caveat; local CLI environment disabled common telemetry controls	No complete cross-surface disable contract or runtime packet audit was established
goose	Official configuration says `GOOSE_TELEMETRY_ENABLED` defaults to false	Kingy did not perform runtime network verification
Qwen Code	Telemetry, usage statistics, prompt logging, and sensitive-span logging have separate documented controls; the checked configuration disabled them	Selected model-provider policies remain separate; runtime egress was not validated

“Unknown” must not be rewritten as “none.” A documented off switch is useful, but it does not cover the model provider, extensions, package managers, update checks, session sharing, or every product surface. For sensitive code, inspect runtime egress under the exact version and configuration you will use.

Persistence and export

OpenHands documents local base-state and event files compatible with trajectory review. Cline CLI documents local SQLite session storage and JSON output. Qwen Code documents local directories for conversations, logs, and todos. Codex CLI documents local session-history behavior, while OpenCode keeps sessions local unless the user shares them. Kingy did not establish a complete portable export contract for Codex, Cline across every surface, goose, or Qwen Code.

This is not an export-feature ranking. It is a reminder that auditability depends on what your chosen surface actually records. If you need reproducible automation, require a structured event stream, retained patch, command log, timing, and provider-reported usage before you trust the workflow.

What Kingy checked locally

The project installed or pinned six official-source artifacts and first exercised offline interfaces without model calls. Installation/version/help/configuration checks passed for all six. A later common-runner preflight returned successful status for five and hit a local macOS semaphore startup failure for the separately packaged OpenHands CLI. Cline 3.0.57 and Qwen Code 0.22.0 were subsequently installed and passed deny-network offline CLI smokes, but were not substituted into the benchmark-bound rows.

Agent	Exact locally checked surface	Offline evidence retained	Offline outcome	Scope of the finding
OpenCode	CLI 1.18.21	Version, help, isolated `debug config`; sharing and automatic updates disabled	Passed	Artifact and isolated config ran; no quality, privacy, or comparative result
Codex CLI	CLI 0.149.0	Version, help, `exec --help`, login help/status	Passed	CLI/status surfaces ran without exposing credential values; not a comparative model result
OpenHands	CLI 1.16.0; SDK 1.21.0	Version, help, headless argument guard, installation record; common-runner attempt	Installation checks passed; common runner blocked at semaphore startup	Separate CLI existed; finding does not generalize to Agent Canvas, core/server, or task quality
Cline	CLI 3.0.56; later CLI 3.0.57 offline smoke	Version, help, authentication help in isolated data directories	Passed	Both package surfaces ran offline; only 3.0.56 was benchmark-bound
goose	CLI 1.47.0	Version, help, `run --help` with isolated configuration	Passed	CLI and noninteractive interface existed; no comparative provider or task result
Qwen Code	CLI 0.21.15; later CLI 0.22.0 offline smoke	Version, help, safe-mode extension listing	Passed; no extensions installed	Both package surfaces ran offline; only 0.21.15 was benchmark-bound

Why the benchmark results are withheld

The later compact-v9 edition was a prospectively frozen, explicitly post-budget, five-agent exploratory design. It finished with 111 valid cells of 180 and 69 unresolved. Thirteen required security cells exhausted the one allowed infrastructure-invalid retry, making the frozen minimum-coverage rule impossible to satisfy. Of 28 infrastructure-invalid attempts, 24 carried an upstream temporary rate-limit response; four later goose attempts completed model activity but failed the artifact-capture rule. The invalid classifications and all attempts were retained.

Those figures describe the evaluation process, not the agents. Publishing the incomplete per-agent outcomes would reward or punish products for uneven missingness and violate the precommitted rule. This guide therefore publishes no partial completion rates, cost comparisons, timing comparisons, security outcomes, scores, or rank.

Two installation caveats remain useful when kept in proportion. A dated audit of Cline CLI 3.0.56 reported 15 production dependency findings, including one high-severity transitive finding; it is not a permanent product security label. Codex CLI’s package identity matched registry integrity, lockfile, source tag, and binary hash while a strict macOS native-signature check remained unresolved. Recheck both against the exact version you deploy.

Detailed agent profiles

Best fit to investigate: developers who want a terminal or desktop coding-agent surface and care about choosing between hosted and OpenAI-compatible local endpoints.

Documented identity. The official repository identifies an MIT-licensed terminal and desktop agent. Kingy’s audit captured v1.18.21 and pinned CLI 1.18.21. The repository’s provider documentation includes a local OpenAI-compatible endpoint example, making provider flexibility part of the documented architecture rather than an unsupported hack.

Model and workflow shape. OpenCode’s terminal orientation makes it a natural candidate for repeatable, script-adjacent use. Its documented run surface and structured event output were prepared for a future harness. Kingy locally checked version, help, and isolated configuration parsing. Sharing and automatic updates were disabled in that offline test configuration; the check itself made no model call.

Privacy and persistence. OpenCode’s sharing documentation says sessions are local by default and that sharing is an explicit action which uploads conversation content and metadata until unshared. That is a useful, concrete boundary. Kingy did not establish a definitive product-wide telemetry policy in the reviewed sources, so the correct label remains unknown rather than “telemetry-free.”

What remains unknown. The retained evidence does not establish comparable task success, command-approval behavior under real work, runtime egress, reliable cost capture, or the desktop surface. Choose OpenCode because its product shape matches your needs, not because this guide proves better code generation.

Codex CLI: a strong open-source CLI boundary with an OpenAI-oriented model path

Best fit to investigate: terminal users who want an open-source agent client and are comfortable with the documented ChatGPT or OpenAI API route.

Documented identity. OpenAI’s open-source boundary documentation distinguishes the Apache-2.0 CLI, SDK, and App Server from the IDE extension and Codex cloud. Kingy captured and locally checked CLI 0.149.0 from the canonical release line. That boundary matters: a finding about the CLI cannot automatically describe the cloud service or IDE product.

Permissions. OpenAI’s approvals and security documentation describes OS-enforced sandboxing and approvals, with network disabled by default. The local adapter was designed around isolated state, ephemeral sessions, ignored user configuration/rules, a workspace-write sandbox, and an outer network policy. The cited offline check covered CLI help, noninteractive exec help, and login status; it was not a coding-task result.

Model and telemetry boundary. The reviewed official route uses ChatGPT authentication or an OpenAI API credential. A supported local-model path was not established by the captured official documentation. The adapter froze documented OpenTelemetry exporters to none and disabled user-prompt logging, but Kingy did not complete a runtime egress audit or establish a product-wide telemetry classification.

What remains unknown. Later model-backed records did not produce coverage sufficient for a valid comparison of controlled-model behavior, price, latency, or provider-reported per-run usage. The local installation also retained an unresolved strict macOS code-signature check despite matching registry integrity, lockfile, source tag, and binary hash. Neither issue is a performance result.

OpenHands: a platform-shaped candidate with an important surface caveat

Best fit to investigate: teams building an autonomous task-runner or agent platform that value SDK/server surfaces, structured events, and local or remote execution options.

Documented identity. OpenHands’ official repository describes an MIT core, while the separate OpenHands Cloud license places that product under PolyForm Free Trial 1.0.0. The SDK documentation covers local and remote agents with code, file, shell, and web tools. Its persistence guide documents structured state and event files.

The surface problem. Kingy reviewed core v1.15.0 at the audit cutoff but locally installed OpenHands CLI 1.16.0 with bundled SDK 1.21.0. The CLI is a separate release line, and its retained official README describes it as no longer actively maintained in favor of Agent Canvas. A CLI result cannot be generalized to current core, server, hosted, or Agent Canvas behavior.

Permissions and environment. The checked CLI’s headless mode auto-approves actions, so the evaluation design required an outer filesystem, process, network, and credential boundary. The installation-level version/help checks passed, but a later common-runner invocation failed during local macOS semaphore initialization. The host also lacked an available Docker daemon and the disk headroom required by the pilot’s container preflight.

What remains unknown. The retained evidence does not establish a coding-task comparison, containerized isolation, current Agent Canvas behavior, GUI behavior, or an agent-server deployment. The environment blocker is a retained observation, not a negative product-quality verdict.

Cline: IDE-first product shape, but version and telemetry findings are surface-specific

Best fit to investigate: developers who want review and agent interaction inside an editor, with hosted, BYOK, or local-model choices.

Documented identity. Cline’s official repository is Apache-2.0 and spans IDE, CLI, SDK, and desktop tracks. Kingy captured the VS Code v4.1.10 line, benchmark-bound CLI 3.0.56, and later ran a deny-network offline smoke on CLI 3.0.57; the GitHub latest release at cutoff was the separate Desktop 0.0.15 track. The authorization documentation covers hosted access, BYOK, Ollama, and LM Studio. The CLI reference documents command permissions, local SQLite sessions, and JSON output.

Why the interface matters. Cline’s appeal is not established by a benchmark here; it is the product shape. An IDE surface can keep proposed changes, context, and approvals closer to the working tree. The CLI offers a separate automation path. Because the tracks are independently versioned, verify the exact one you plan to use instead of quoting a repository-wide version.

Telemetry nuance. Repository guidance says normal SDK events should respect opt-out paths, while the VS Code rollout documentation preserves a feature-flag evaluation caveat. Kingy’s isolated CLI environment disabled common OpenTelemetry and logging controls, but the official CLI materials did not establish a complete runtime disable contract. External egress policy remained required.

What remains unknown. No valid comparative coding-task result, IDE test, cross-surface export test, or runtime network audit is available. A dated npm audit of the checked CLI snapshot found 15 production dependency findings, including one high-severity transitive issue. Recheck the current package rather than treating that snapshot as a permanent product label.

goose: provider-neutral architecture with terminal, desktop, and API routes

Best fit to investigate: users who value provider portability, local/self-hosted model options, and a project governed under the Agentic AI Foundation.

Documented identity. The official goose repository covers terminal, desktop, and API surfaces under Apache-2.0. The retained audit captured v1.47.0. Its governance document places stewardship under the Agentic AI Foundation as a series of LF Projects, LLC and distinguishes the documentation’s CC-BY-4.0 license from code/specifications.

Model posture. Official provider documentation includes hosted options, Ollama, Ramalama, vLLM, and compatible self-hosted endpoints. That makes goose a plausible candidate when no single proprietary inference service should be mandatory.

Controls and telemetry. The documented GOOSE_TELEMETRY_ENABLED setting defaults to false. Kingy’s intended adapter also isolated XDG state, disabled keyring use, disabled user profiles, enabled only a named built-in developer extension, and required an outer network allowlist. Version, help, and run --help checks passed offline.

What remains unknown. The retained evidence does not validate comparative task quality, extension/API behavior, reliable cost, runtime egress, or an export contract. The missing local container runtime blocked controlled evaluation but says nothing about goose’s inherent coding capability.

Qwen Code: the broadest documented surface set in this cohort

Best fit to investigate: users who want terminal and IDE routes plus SDK/daemon options, with hosted or local Ollama/vLLM model paths.

Documented identity. The official repository is Apache-2.0 and documents terminal, IDE, desktop, SDK, and daemon surfaces. It also states the project originated from Gemini CLI v0.8.2 and stopped upstream synchronization at Qwen Code v0.1. Kingy’s benchmark evidence is bound to v0.21.15; current v0.22.0 later passed an offline deny-network smoke only.

Configuration and model path. Official sources document hosted/BYOK options and local Ollama/vLLM paths. The checked CLI configuration used an isolated Qwen home, disabled telemetry, usage statistics, prompt logging, sensitive-span logging, and request logging, and had no extensions installed. Version, help, safe-mode, and extension-list checks passed without a model call in those offline smokes.

Permission and privacy boundary. Qwen Code’s settings documentation covers sandbox and telemetry controls. Its privacy notice separates agent telemetry from the selected model provider’s policy. That distinction is essential: turning off one product’s telemetry does not determine how an inference provider handles prompts.

What remains unknown. The retained evidence does not establish comparative coding-task performance, IDE/desktop/daemon/SDK behavior, reliable provider usage accounting, or runtime egress. The breadth of documented surfaces is a selection factor, not evidence that Qwen Code performs more effectively.

Reproducibility: what the pilot retained

The pilot’s useful output is broader than the live calibration attempt. It retained exact agent and installation records, official source URLs with capture dates, release versions and commits, dependency-lock hashes, executable or artifact hashes, isolated configuration hashes, offline smoke outcomes, adapter contracts, synthetic task fixtures, security scenarios, evidence schemas, and a reviewer protocol.

The functional task package contained 18 qualified tasks and two reserves. Eight inert synthetic security fixtures covered the planned threat taxonomy. Private verifiers and oracle material were separated from public prompts. Deterministic qualification produced 100 expected negative-verifier results, 100 oracle passes, and 40 security-fixture self-test passes. These figures establish that the harness materials behaved as designed; they do not establish anything about the six agents.

For a future comparative edition to become publishable, every valid run would need the exact agent surface/version, a frozen model and provider route, an isolated disposable workspace, captured command and event streams, a final patch, machine-verifier output, provider-reported usage, and invalid-run classification. Security anomalies and suspicious patches would require blinded human review. Kingy’s retained protocol explicitly prevents human reviewers from converting a machine-test failure into a pass.

The compact-v9 attempt did not clear that bar. It reached 111/180 valid cells, but 13 required security cells exhausted their only permitted retry and the coverage gate became impossible. Historical runtime records are preserved, yet incomplete product outcomes are excluded from this guide. The concise public conclusion is sufficient: comparative performance remains unmeasured.

A practical preflight before you trust any coding agent

Name the exact product surface and version. “Cline,” “OpenHands,” or “Codex” can refer to materially different components.
Read the license boundary. Separate agent code from enterprise directories, hosted services, extensions, and model terms.
Choose the model route. Hosted, BYOK, and local inference change privacy, price, availability, and troubleshooting.
Use a disposable repository. Do not begin with a production tree or a directory containing unrelated credentials.
Constrain filesystem and process access externally. Treat in-agent approvals as an additional layer.
Deny network access by default. Allow only the provider or internal services the run genuinely requires, then record attempted egress.
Isolate configuration and state. Do not silently inherit host profiles, extensions, rules, sessions, or keychains.
Capture structured evidence. Retain the prompt, exact version, patch, command log, machine result, timing, and provider-reported usage.
Inspect the patch before merging. A passing agent narrative is not a code-review result.
Retest after material updates. Fast-moving release lines make old conclusions stale quickly.

FAQ

Which open-source coding agent is best in 2026?

Kingy’s retained evidence cannot support a winner. It supports a six-agent shortlist and clear product-fit distinctions, but no valid comparative coding-quality, safety, reliability, latency, or cost result. Any “best” answer here would be editorial invention.

Which candidates support local models?

The captured official sources document local or compatible-endpoint routes for OpenCode, OpenHands, Cline, goose, and Qwen Code. Kingy did not establish a supported local-model path for Codex CLI in the reviewed official OpenAI sources. Documented support is not the same as successful end-to-end validation with your chosen model.

Are all six products completely open source?

Their audited agent-core components use OSI-approved licenses, but the boundaries differ. OpenHands Cloud is separately distributed under PolyForm Free Trial rather than the core repository’s MIT license. Codex CLI’s open-source boundary excludes the IDE extension and cloud. Hosted services, inference providers, marketplaces, and enterprise features may have separate terms for every candidate.

Did Kingy actually install the agents?

Yes. Kingy retained pinned installation records for all six and exercised offline version/help or configuration surfaces. Five candidates returned successful status in a common runner; the separate OpenHands CLI hit a local macOS semaphore-startup failure there while its installation checks passed. Later model-backed attempts existed, but the coverage gate failed and their incomplete comparative outcomes are withheld.

Why not publish the attempted benchmark results?

Because compact-v9 did not satisfy its frozen coverage rule: 111/180 cells were valid, 69 remained unresolved, and 13 required security cells exhausted the only allowed retry. Publishing partial outcomes would turn uneven missingness and infrastructure conditions into product claims. Every attempt remains retained, but no incomplete product result, score, or rank appears here.

Is a local coding agent private by default?

Not necessarily. The agent process may run locally while prompts go to a hosted model, extensions reach external services, packages are downloaded, sessions are shared, or telemetry is emitted. Privacy depends on the complete configured data path, not the location of the CLI binary.

Do sandbox and approval settings make an agent safe?

They help, but they are not enough to prove confinement. Use external controls for repository scope, filesystem access, command execution, network egress, and credentials. Then test those controls with the exact version and surface you will deploy.

Which agents fit an IDE workflow?

Cline is the cohort’s IDE-first candidate by documented product shape, and Qwen Code also documents an IDE surface. This is not a quality comparison. Validate the exact extension version, permissions, model route, persistence, and telemetry behavior.

Which agents expose platform-building surfaces?

OpenHands documents an SDK/server architecture with structured persistence. Qwen Code’s SDK/daemon, goose’s API, and Codex’s SDK/App Server also merit investigation. Kingy did not test those surfaces end to end, so their comparative suitability remains unknown.

What should a trustworthy future benchmark include?

Exact versions, the same frozen model/provider route, disposable workspaces, consistent network and credential controls, representative public tasks, hidden deterministic verifiers, provider-reported usage, invalid-run rules, retained trajectories, and blinded human review for security anomalies. It must also disclose coverage and missing evidence instead of forcing a total ranking.

Final verdict

OpenCode, Codex CLI, OpenHands, Cline, goose, and Qwen Code represent distinct product shapes. All six passed Kingy’s official-source eligibility review conditionally and have pinned local installation records. That supports a responsible shortlist, but it does not establish coding ability.

Choose OpenCode, Codex CLI, goose, or Qwen Code when a terminal-first route is the starting requirement. Investigate Cline when IDE-centered review is central. Investigate OpenHands when SDK/server architecture and autonomous task execution matter more than a simple chat surface. If local inference is mandatory, prioritize the five products with captured official local/compatible-endpoint routes and treat Codex CLI’s local-model status as unknown in this audit.

Verify the exact version, model path, permission envelope, persistence, and runtime egress yourself. Adopt the workflow that survives that test. Ignore unsupported leaderboards.

Disclosure

Evidence cutoff and official-source refresh: August 22, 2026. Local evidence is identified by exact surface and version. Later model-backed attempts are acknowledged only as retained evaluation-process evidence; compact-v9 failed its frozen coverage gate, and all incomplete comparative outcomes are withheld. No ranking was produced, no company paid for placement, and no maintainer was contacted for this edition. Edition v1.5.1 was published to WordPress post 928908 on August 23, 2026.