OpenCode

OpenCode is best understood as an open agent harness for software work: a terminal-native coding agent that separates the orchestration layer from any single model vendor. Its strategic bet is that coding agents should converge around open extension surfaces — Model-Agnostic AI Systems, Model Context Protocol, AGENTS.md, plugins, and provider routing — rather than around closed, model-bundled products such as Claude Code or Codex CLI. The evidence so far supports OpenCode as a serious open-source alternative, but not yet as the uncontested benchmark leader or ecosystem standard.

Coverage note: verified through May 18, 2026.

Core claim

OpenCode is not primarily interesting because it is “another coding chatbot in a terminal.” It is interesting because it tries to make the Agent Harness — the layer that reads repositories, calls tools, runs shell commands, manages context, switches modes, invokes subagents, and talks to model providers — into an open, portable, model-agnostic system.

That distinction matters. In modern coding agents, the user-facing product is no longer just the underlying LLM. The product is the compound system: model, context manager, tool registry, permission policy, shell executor, editor integration, memory files, subagents, benchmark harness, and distribution channel. Recent agent-harness analyses define coding harnesses as systems that manage repository context, tools, execution, iteration, and feedback around an LLM; the OpenDev terminal-agent paper similarly treats terminal-native coding agents as compound AI systems rather than simple wrappers around chat completion APIs. Sebastian Raschka

OpenCode’s bet is that this compound system should be open enough to survive model churn. A Claude Code user is buying into Anthropic’s model and product surface. A Codex CLI user is buying into OpenAI’s model and platform surface, even though the CLI itself is open source. An OpenCode user is buying into an open harness that can dispatch work to Anthropic, OpenAI, Google, local models, open models, or curated provider bundles, depending on configuration and availability. OpenCode’s own documentation describes it as an open-source AI coding agent available as a terminal interface, desktop app, or IDE extension, and says it can use any LLM provider by configuring API keys. OpenCode

What OpenCode is

OpenCode is an open-source terminal-native AI coding agent designed to operate inside a developer’s working tree. Its public documentation presents three surfaces: terminal TUI, desktop app, and IDE extension. The terminal remains the conceptual center: users install the CLI, authenticate with one or more model providers, initialize the project, and then ask OpenCode to inspect files, plan changes, edit code, run commands, and use tools. OpenCode

The project’s differentiator is provider optionality. OpenCode’s homepage advertises support for Claude, GPT, Gemini, and other models, including local models; the model documentation says OpenCode uses the Vercel AI SDK and Models.dev to support more than 75 providers. OpenCode This is the central contrast with vendor-tied coding agents. Claude Code is a first-party Anthropic product centered on Claude models and Anthropic’s extension ecosystem. Codex CLI is OpenAI’s local terminal coding agent; it is open-source and can switch among available OpenAI models, but it is still an OpenAI-platform agent rather than a provider-agnostic harness. Claude

OpenCode also adopts the emerging convention that coding agents need durable project instructions. Its /init command analyzes a project and creates an AGENTS.md file in the project root, which the docs recommend committing to Git. OpenCode That aligns OpenCode with the broader AGENTS.md ecosystem, where agent-readable repository instructions are becoming a cross-tool convention rather than a single-vendor feature. The AGENTS.md project describes the file as a simple open format for agent instructions and notes adoption across tools including Codex, Amp, Jules, Cursor, and Factory. Agents

The architectural shape: thin harness, rich extension surface

Calling OpenCode a “thin harness” does not mean it is trivial. A useful coding agent has to solve difficult runtime problems: context selection, repository navigation, permissions, command execution, edit application, memory, tool schemas, provider differences, and recovery from failed plans. “Thin” means something narrower: OpenCode does not try to make the model layer proprietary. It keeps the harness open and lets the user choose the model backend.

A technical deep dive into OpenCode describes a client/server architecture in which running opencode launches a JavaScript HTTP server and a Go TUI client, allowing other clients to create sessions over HTTP. The same analysis describes OpenCode’s use of the AI SDK to normalize tool calls across providers, with MCP tools fetched at startup and plugin hooks available around tool execution. Moncef Abboud

Architectural choice	How OpenCode implements it	Why it matters	Main risk
Thin open harness	Open-source agent runtime around terminal sessions, tools, files, shell commands, provider calls, and UI clients	Keeps the orchestration layer inspectable and portable	Harness quality still matters; openness does not guarantee good results
Multi-model dispatcher	Provider/model IDs, Models.dev provider metadata, AI SDK integration, `/models`, default `model`, `small_model`, and per-agent model overrides	Lets users route work across Claude, GPT, Gemini, open models, local models, and cheaper models	Routing is hard; many models are weak at tool calling or long-horizon coding
MCP-first design	Local and remote Model Context Protocol servers can expose external tools to the agent	Makes OpenCode compatible with a larger tool ecosystem rather than bespoke integrations only	MCP servers add context load and security surface
Agent and subagent system	Built-in Build, Plan, General, Explore, Scout, and hidden compaction/title/summary agents	Gives the harness task-specialized behaviors and isolated contexts	Subagent quality depends on prompts, model choice, and context management
Plugin system	Local and npm-distributed plugins hook into events such as tool calls, permissions, sessions, files, LSP, and messages	Allows community and team-specific workflow extensions	Plugin maturity and supply-chain trust become part of the agent’s reliability
Permission policy	Configurable permissions for edit, bash, and tool usage; Plan mode restricts modification	Lets teams tune autonomy versus safety	Defaults and team policies must be understood before broad adoption
LSP and project context	LSP support starts language servers by file extension; AGENTS.md and instruction globs provide project conventions	Improves code-awareness beyond raw text search	Language-server behavior and context selection vary by stack
SDK and automation surface	Type-safe JavaScript SDK and server/client model; GitHub Action support for issue and PR workflows	Makes OpenCode usable beyond an interactive terminal	Automation increases blast radius if permissions and model behavior are poorly constrained

OpenCode’s model layer is configurable at several levels. The config supports a default model, a small_model for lightweight tasks, provider allow/deny lists, and per-agent model overrides using provider/model IDs. OpenCode The model docs are unusually direct about a key practical issue: OpenCode can connect to many models, but only some models are strong at coding and tool calling, and the recommended list is not exhaustive or guaranteed to stay current. OpenCode

That caveat is central. Model-agnosticism is not the same as model equivalence. An open harness can dispatch to many models, but the user still has to choose among cost, latency, context window, tool-calling reliability, coding competence, rate limits, privacy constraints, and provider availability.

MCP-first, but not MCP-only

OpenCode’s Model Context Protocol support is one of its most important architectural choices. MCP gives agents a common way to connect to external tools, data sources, and services. Anthropic introduced MCP in November 2024 as an open standard for connecting AI assistants to data sources; the MCP project later described the protocol as a “USB-C” style standard used across clients including Claude, ChatGPT, VS Code, and Cursor. anthropic.com

OpenCode’s docs say MCP servers can be local or remote, and that tools exposed by MCP become available to the LLM alongside OpenCode’s built-in tools. They also warn that MCP servers can add significant context load, especially when many tools are enabled. OpenCode This is the correct warning. Tool ecosystems are not free: each tool description competes for context, increases the action space, and introduces new failure modes. A GitHub MCP server, a browser MCP server, a database MCP server, and a design-file MCP server may all be useful, but together they can make the model’s planning problem worse.

OpenCode’s plugin system is the second extension layer. Plugins can be loaded from project and user config, from local plugin directories, or from npm packages; plugin modules receive context and can hook into command, file, LSP, message, permission, session, tool, and TUI events. OpenCode+2OpenCode+2 This gives OpenCode an extensibility story closer to a developer platform than to a fixed CLI.

The trade-off is that an extensible agent harness inherits software-platform risks: plugin versioning, supply-chain trust, team policy, reproducibility, and interoperability. Claude Code and Codex CLI can ship more integrated first-party experiences; OpenCode can expose more of the surface to users and community maintainers.

Agents, subagents, and mode design

OpenCode’s agent system is not merely a UI label. The docs define agents as specialized assistants with custom prompts, models, and tool access. They distinguish primary agents from subagents: built-in primary agents include Build and Plan, while subagents include General, Explore, and Scout. OpenCode

The distinction encodes a practical division of labor:

Agent	Role	Tool posture	Strategic function
Build	Default implementation agent	Broad tool access	Make changes, run commands, implement features
Plan	Planning and analysis agent	Restricted modification powers	Produce plans before edits; reduce accidental changes
General	Multi-step helper	Broad but task-scoped	Search, investigate, or perform complex subtasks
Explore	Codebase exploration	Read-oriented	Inspect repository structure without making changes
Scout	Documentation and dependency research	Read-oriented	Investigate external docs and dependencies
Hidden agents	Compaction, titles, summaries	Internal	Maintain session usability and context management

OpenCode also supports hidden agents for compaction, title generation, and summaries. OpenCode This matters because long-running coding sessions are memory-management problems. The model may be stateless, but the harness must maintain a useful working state across edits, shell output, tool calls, and plan revisions. The OpenDev terminal-agent paper argues that context observations can consume 70–80% of a session’s context budget and describes staged context compaction strategies; this is the same class of problem OpenCode’s compaction and agent modes are trying to manage. arXiv

Deployment patterns

OpenCode is likely to be adopted in several different ways rather than one canonical workflow.

Deployment pattern	What it looks like	Why OpenCode fits	Constraint
Individual terminal copilot	Developer runs `opencode` inside a repository, connects one or more providers, uses Build and Plan modes	Low friction, terminal-native, project-local	User must understand permissions and provider costs
Multi-provider team harness	Team standardizes on OpenCode but allows different models by task, cost, or policy	Model-agnostic config and provider controls	Requires governance around provider access and data handling
Local/open-model workflow	Developer routes some tasks to local or open models	OpenCode supports local models through its provider layer	Local models may underperform on tool-heavy coding
MCP-heavy workflow	Agent connects to GitHub, databases, browsers, docs, design assets, or internal systems through MCP	MCP support is built into the tool model	Tool overload and secret exposure require discipline
Plugin-driven internal platform	Team writes local or npm plugins for logging, policy, review, notifications, or custom commands	Plugin hooks cover sessions, files, permissions, tools, and commands	Plugins become production software
GitHub automation	Users mention `/opencode` or `/oc` in GitHub issues or PRs, and the agent runs in GitHub Actions	OpenCode supports issue and pull-request workflows in GitHub runners	CI permissions, branch policies, and review gates matter
Low-cost managed access	Users buy curated access to selected models through OpenCode Go or Zen-style provider bundles	Reduces the setup burden of many provider accounts	Curated access may not match every enterprise or privacy requirement

OpenCode’s GitHub integration is especially important because coding agents are moving from interactive chat to asynchronous software-workflow participants. The docs say OpenCode can be invoked in GitHub issues and pull requests with /opencode or /oc, runs inside GitHub Actions, and can triage issues, create branches, and open PRs. OpenCode

The project also lists community plugins and integrations for notifications, browser UI, background agents, workspace orchestration, and agent collections. OpenCode This does not prove ecosystem maturity, but it does show the intended shape: OpenCode wants to be a substrate that others build on.

Empirical evidence on coding benchmarks

The evidence on OpenCode’s benchmark performance is meaningful but still thin. There is no single authoritative, widely accepted OpenCode leaderboard that proves it has surpassed Claude Code, Codex CLI, or Aider across real-world coding tasks. The best available evidence comes from public benchmark suites that include OpenCode in some configurations, plus broader analyses showing that harness design and model choice both materially affect outcomes.

Terminal-Bench

Terminal-Bench evaluates whether AI agents can complete end-to-end tasks in real terminal environments. Its leaderboard includes both model and harness configurations, which is important because coding-agent performance is no longer reducible to the base model alone. Terminal-Bench describes itself as a benchmark for terminal mastery, with tasks executed in realistic terminal environments. Terminal-Bench+1

On the Terminal-Bench leaderboard data available here, Codex CLI with GPT-5.2 scored 62.9 ± 3.0, Codex CLI with GPT-5.1-Codex-Max scored 60.4 ± 2.7, Claude Code with Claude Opus 4.6 scored 58.0 ± 2.9, Claude Code with Claude Opus 4.5 scored 52.1 ± 2.5, and OpenCode with Claude Opus 4.5 scored 51.7. Terminal-Bench

The narrow OpenCode-versus-Claude-Code result with the same Opus 4.5 model is suggestive: OpenCode was close to Claude Code on that listed configuration. But the broader leaderboard still showed top Codex CLI configurations ahead. The honest conclusion is not “OpenCode is better” or “OpenCode is worse”; it is that an open harness can be competitive in some terminal-benchmark settings, but benchmark leadership remains configuration-dependent.

SWE-Bench and SWE-Bench Verified

SWE-Bench evaluates agents on real software-engineering issues from GitHub repositories. SWE-Bench Verified is a 500-task human-filtered subset designed to improve task clarity and solvability. SWE-bench+1 Public leaderboard analysis has found that reporting and comparability are difficult because submissions often do not document harness architecture in enough detail; the same analysis found that open-source systems became increasingly competitive, while closed-source systems had higher median performance on some cuts. arXiv

That matters for OpenCode because absence from a headline leaderboard should not be overinterpreted, but neither should openness be treated as evidence of superior performance. SWE-Bench-style results are shaped by model, harness, scaffolding, test-time repair, retrieval, command execution, and evaluation protocol. A thin open harness still has to compete with heavily optimized private scaffolds.

SWE-Bench Mobile

The most concrete OpenCode-specific negative evidence comes from SWE-Bench Mobile, a benchmark of 50 multimodal iOS tasks with 449 tests and frequent visual/Figma references. arXiv In the paper’s reported results, commercial agents reached a best task success rate of 12%, while OpenCode’s best configuration reached 8% with GLM-4.6. arXiv

The same benchmark shows that the harness can matter dramatically even when the model is held constant. With Claude Opus 4.5, Cursor reached 12%, Claude Code reached 8%, Codex reached 4%, and OpenCode reached 2%; with Claude Sonnet, Cursor reached 12%, Codex and Claude Code reached 10%, and OpenCode reached 4%. arXiv OpenCode’s best GLM-4.6 run was cheap — reported at $0.13 per task — but slow at 32.5 minutes per task, while some commercial-agent GLM runs were around $1.30 per task and faster. arXiv

This is the strongest caution against simplistic model-agnostic optimism. OpenCode can route to many models, but routing is not enough. The harness, UI affordances, tool design, vision integration, planning loop, and retry behavior affect results.

OpenCode Bench and harness-specific evaluation

OpenCode Bench exists as a benchmarking framework for coding agents on real GitHub repositories, with scoring categories such as API signature compliance, logic equivalence, integration correctness, test coverage, and project checks. GitHub That is directionally healthy: open agents need open evaluation. But a framework is not the same as a mature public evidence base. OpenCode still needs repeated, third-party, apples-to-apples evaluations across common repositories, tasks, models, and cost budgets.

The broader evaluation trend is favorable to OpenCode’s framing, even if not always to OpenCode’s current scores. Artificial Analysis’s Coding Agent Index measures coding agents as harnessed systems across software-engineering tasks, cost, token usage, and execution behavior rather than treating models alone as the unit of comparison. Artificial Analysis Vals.ai’s SWE-Bench Verified evaluation deliberately used a minimal bash-tool-only harness to reduce scaffold effects, which underscores the same point from the opposite direction: harness choice can obscure or amplify model capability. Vals AI

Comparison: OpenCode, Claude Code, Codex CLI, and Aider

The most useful comparison is not “which one is best?” but “which layer is each tool trying to own?”

Tool	Ownership model	Model strategy	Harness style	Strongest fit	Main critique
OpenCode	Open-source harness and extension surface	Provider/model-agnostic via AI SDK, Models.dev, local models, and provider config	Terminal-first agent with desktop/IDE surfaces, MCP, plugins, agents, subagents, SDK, GitHub automation	Teams or developers who want model choice, open extensibility, and less vendor dependence	Less polished than first-party vendor agents; routing and plugin maturity remain hard
Claude Code	Anthropic first-party product	Claude-centered	Mature agent loop with built-in tools plus CLAUDE.md, Skills, MCP, subagents, hooks, plugins, and agent teams	Users who want the strongest Anthropic-integrated coding experience	Vendor/model lock-in and Anthropic access constraints
Codex CLI	Open-source CLI inside OpenAI platform	OpenAI models; `/model` switches among available OpenAI models	Local Rust terminal agent with TUI, subagents, web search, MCP, approval modes, cloud tasks, and ChatGPT/API authentication	Users already in the OpenAI/ChatGPT/Codex ecosystem	Open-source CLI does not equal provider-agnostic agent
Aider	Open-source terminal pair-programming tool	Cloud and local LLMs; nearly any LLM	Git-native pair programmer with repo map, automatic commits, lint/test loops, IDE support, image/web context	Developers who want reviewable diffs, Git commits, and incremental pair programming	Less centered on multi-agent orchestration and platform-style plugin ecosystems
Broader IDE/cloud agents	Usually vendor or platform controlled	Often bundled with one model family or marketplace	IDE-native, cloud PR agents, background tasks, agent sessions	Enterprise integration, task queues, cloud execution, IDE workflow	Fragmented standards and unclear portability

Claude Code’s extension documentation is a useful comparison point. Anthropic describes Claude Code as combining a model that reasons about code with built-in tools for file operations, search, execution, and web access, plus an extension layer including CLAUDE.md, Skills, MCP, subagents, hooks, plugins, and agent teams. Claude Codex CLI’s official docs describe it as OpenAI’s local terminal coding agent, open-source and built in Rust, with ChatGPT/API authentication, model switching among available OpenAI models, image inputs, subagents, web search, Codex Cloud tasks, MCP, and approval modes. OpenAI Developers Aider’s own site emphasizes terminal pair programming, broad LLM compatibility including local models, repository maps, automatic Git commits, and lint/test self-repair. Aider

Aider is the most important open-source comparison because it is not merely “older OpenCode.” It optimizes a different axis: Git-native pair programming. Aider’s automatic commits and repo map make it especially strong when the desired workflow is “small, reviewable changes with Git history.” OpenCode is closer to a general-purpose terminal agent harness: more attention to MCP, plugins, subagents, provider routing, and automation surfaces.

Claude Code and Codex CLI are the opposite comparison. They may be more polished because their vendors control both model and product loop. That vertical integration is a strength. It means the model, tool schemas, permission modes, context conventions, cloud features, and UI can be co-designed. But it is also the lock-in OpenCode is designed to resist.

Broader ecosystem position

OpenCode sits inside a fast-fragmenting coding-agent ecosystem. There are terminal agents, IDE agents, cloud PR agents, issue triage bots, browser-using agents, local open-source harnesses, model-provider CLIs, and enterprise platforms. VS Code’s own agent-session direction reflects this fragmentation: Microsoft describes Agent Sessions as a way to manage local and remote agents, including integrations with Codex and other agentic workflows. code.visualstudio.com

Two standards reduce this fragmentation:

Model Context Protocol provides a shared way to connect agents to tools and external systems.
AGENTS.md provides a shared way to put agent-readable project instructions inside repositories.

OpenCode’s adoption of both is strategically important. If agents are going to fragment at the product level, then shared protocols and repo conventions are the next-best outcome. OpenCode does not have to become the only coding agent to matter; it can become valuable by making the open parts of the ecosystem easier to compose.

Active critiques

1. OpenCode is less polished than vendor-tied options

The strongest critique is straightforward: OpenCode is more configurable, but first-party agents can be smoother. Claude Code and Codex CLI can optimize their harnesses around their own model families, release features in lockstep with model behavior, and integrate deeply with their subscription, cloud, and enterprise systems. OpenCode has to support many providers, many model behaviors, and many user environments.

This is not merely aesthetic. Polished agents often fail less because their tool schemas, permission prompts, retry loops, UI states, and model-specific prompts are tuned together. OpenCode’s openness means more surface area is delegated to the user or community.

2. Model routing is powerful but difficult

OpenCode exposes provider/model selection, small_model, and per-agent model overrides. OpenCode This is architecturally elegant but operationally hard. Most developers do not want to benchmark ten models across planning, refactoring, shell execution, frontend implementation, long-context debugging, and test repair. The OpenCode docs themselves warn that only a subset of models are good at coding and tool calling. OpenCode

The likely mature pattern is not “users manually choose everything.” It is policy-driven routing: cheap model for summarization, strong model for code edits, long-context model for repository exploration, vision-capable model for design tasks, and local model for sensitive files. OpenCode has primitives for that direction, but the ecosystem still needs better shared routing recipes.

3. MCP can overload context and expand risk

MCP is a strong standard, but every tool increases the model’s action space. OpenCode’s MCP docs explicitly warn that too many MCP tools can add significant context and even exceed context limits. OpenCode The security issue is equally serious. An MCP-enabled agent may be able to touch databases, browsers, cloud services, GitHub repositories, or internal documentation. The protocol makes integration easier; it does not remove the need for permission design.

4. Plugin ecosystems mature slowly

OpenCode’s plugin hooks are broad, which is good for experimentation. But plugin ecosystems require time: stable APIs, documentation, version compatibility, trusted maintainers, review practices, examples, and norms around what plugins should or should not do. A first-party product can ship a blessed feature. An open plugin ecosystem has to earn reliability.

5. Benchmark evidence is incomplete

Terminal-Bench shows OpenCode can be competitive in some configurations; SWE-Bench Mobile shows OpenCode can lag commercial agents on multimodal mobile tasks. Terminal-Bench+1 Both can be true. The evidence is not strong enough to declare OpenCode the open-source standard by performance alone. Its case is architectural and ecosystemic first, empirical second.

6. Default autonomy must be governed

OpenCode’s config docs say defaults allow operations without explicit approval, while configuration can require approval for edit and bash actions. OpenCode This is not inherently wrong; autonomous agents need to act. But teams adopting OpenCode should treat permissions as a first-class security and workflow policy, not as a cosmetic preference.

7. Privacy is conditional on the whole stack

OpenCode’s homepage says it does not store code or context data. OpenCode That is an important project-level privacy claim, but it is not the whole data story. Once a user connects external model providers, MCP servers, plugins, GitHub Actions, or custom tools, data may flow through those systems. OpenCode can reduce central platform lock-in; it cannot make every provider or plugin private by default.

Does OpenCode become the open-source standard?

There are two plausible futures.

In the first, OpenCode becomes the de facto open-source standard for terminal-native coding agents. This happens if its model-agnostic provider layer, MCP integration, AGENTS.md support, plugin system, SDK, GitHub automation, and community ecosystem converge faster than rival open harnesses. Its repository already shows substantial public activity, with the GitHub page reporting a large star count, many forks, and a recent release cadence at the time checked. GitHub In this future, OpenCode is not necessarily the best-scoring agent on every benchmark; it is the common open substrate that many developers and teams can adapt.

In the second future, OpenCode remains one important project among many. Aider keeps the Git-native pair-programming niche. OpenHands-style systems occupy autonomous software-engineering research and web/cloud execution. Claude Code and Codex CLI continue to dominate users who want the best first-party model integration. IDEs consolidate agents through “agent session” managers rather than one universal CLI. MCP and AGENTS.md become the standards, while individual harnesses stay fragmented.

The second future is more likely in the near term. The first is possible only if OpenCode’s community turns its architectural openness into repeatable quality: better routing defaults, stronger benchmark results, safer permission presets, higher-quality plugins, reproducible evaluation, and compelling team deployment stories.

The deepest question is not whether OpenCode beats Claude Code or Codex CLI this month. The question is whether the agent harness becomes a proprietary extension of a model vendor, or a portable layer that developers can inspect, configure, and replace. OpenCode is one of the clearest attempts to make the second path viable.

Practical evaluation checklist

Use OpenCode when the goal is model optionality, open extensibility, terminal-native control, MCP composition, or reduced dependence on a single AI vendor. It is especially attractive for teams that want to experiment with Claude, GPT, Gemini, local models, and open models without changing the whole coding-agent workflow.

Prefer Claude Code when the priority is the most polished Anthropic-native coding experience, especially if the team already trusts Claude models and Anthropic’s product surface. Prefer Codex CLI when the team is already standardized on OpenAI or ChatGPT and wants a first-party OpenAI terminal agent with cloud and local workflow integration. Prefer Aider when the desired interaction model is incremental, Git-native pair programming with automatic commits and reviewable diffs.

Evaluate OpenCode on four dimensions before standardizing:

Dimension	Question
Model routing	Which model handles planning, editing, shell execution, summarization, long-context exploration, and visual tasks?
Permissions	When may the agent edit files, run shell commands, access secrets, call MCP tools, or open PRs?
Reproducibility	Can the same task be rerun with the same model, prompt, tool set, and repository state?
Ecosystem fit	Are required integrations available through MCP, plugins, custom tools, or SDK automation?

The best near-term use of OpenCode is not blind replacement of every coding agent. It is controlled adoption where openness matters: internal tools, multi-provider experimentation, model-cost arbitrage, local-model workflows, MCP-heavy engineering environments, and teams that want to own their agent harness instead of renting it wholesale from a model vendor.