Model Selection Inside a Harness-Agnostic Agent Stack

A multi-harness cloud coding agent platform lets a team route work across coding harnesses instead of using one model-harness pair for every task. Model selection inside that stack is an ongoing routing problem, governed by task type, execution permissions, latency, cost, and workflow integration. More reliable output comes from matching those conditions and measuring the result.

Why model selection in an agent stack is a routing problem, not a one-time choice

A team selects a model that handles one class of changes well, then finds that another class produces slow runs, failed attempts, or excessive review work. The original choice offered no systematic explanation for that difference. The task changed, but the assignment policy did not. Treating model selection as an upfront architectural decision leaves the team comparing models when it also needs to compare how those models execute work.

Frontier models have converged enough that the harness wrapper now shapes the experience more than raw model capability does. Permissions, tool access, session management, and workflow connections determine how much of that capability reaches the task. The model is only part of the purchase. As harness companies increasingly become model companies, a fixed pairing also ties the team to the vendor’s post-training and model partnerships. Routing by task class preserves room to adopt better pairings as they become available, without assuming that every new model should replace every existing assignment.

What harness-agnosticism actually means in practice, and why it changes what you are buying

Harness-agnosticism depends on how the system is built and takes more than access to a wide range of models. Its practical test is whether a team can change the underlying model mid-session, mid-sprint, or by task type without rebuilding the surrounding workflow. Claude Code currently cannot meet that full switching test, OpenCode can, and Cursor and Codex sit between them. These differences define the available routing space before performance enters the comparison.

Claude Code works in the terminal and IDE as well as on Desktop, web, and mobile. Its distinguishing feature is programmability through Dynamic Workflows and published hook events, with Claude Opus 5.5 as its default model as of late 2026. Its model coupling is tight, but not absolute. It officially supports Amazon Bedrock, Google Vertex AI, and Microsoft Foundry, plus gateway-based routing to non-Anthropic models through ANTHROPIC_BASE_URL. Those options broaden deployment choices without making provider configuration equivalent to seamless switching.

Codex spans an app, cloud delegation, an open-source CLI, IDE extensions, and connected ChatGPT workflows. Its local harness supports custom providers, compatible third-party APIs, and local models through Ollama and LM Studio. An OpenAI model is therefore not mandatory locally. But GitHub code review and Slack need the hosted path and cannot use the API-key path. Buying into a harness consequently means selecting an execution and integration architecture.

How task type should drive the first routing decision

Task type supplies the first useful routing distinction because reasoning depth, context breadth, and iteration speed vary with the work. Complex refactors, architectural decisions, and security-sensitive changes benefit from deep reasoning and changes coordinated across files. These tasks need more than rapid edits. Claude Code’s pairing of Opus 5.5 with programmable hooks fits this work, where close model-harness coupling can help with hard tasks even as it limits choice.

Bounded, testable work presents a different objective. Adding tests, upgrading dependencies, fixing lint errors, mechanical migrations, and small bug fixes place more weight on throughput and cost. The boundary is concrete when a change has a narrow target and a check that can establish completion. The Coding Agent Index gives Codex a directional advantage in lower cost and faster completion relative to Claude Code’s Opus 5.5 pairing. That makes Codex a good candidate for large amounts of work with clear acceptance criteria, though some tasks will still need deeper reasoning.

Parallelism adds a separate question about task decomposition. Cursor supports up to eight simultaneous agents using separate git worktrees, which suits work that can proceed on independent branches. Not every task will fit neatly into a category. Nevertheless, most codebases have a stable distribution of task types, so routing can operate at the policy level, assigning lint fixes differently from architectural changes. It does not require a fresh model comparison for every prompt.

How environment constraints shape which pairings are actually available

A suitable pairing can still be unavailable or unsafe in the intended execution environment. Sandboxed execution is an explicit design assumption across the major harnesses and must be considered during model selection. A task that needs network access, package installation, or service startup has to run in an environment that allows those operations. Assigning it to a read-only sandbox produces a failed run attributable to the environment.

Claude Code exposes tool allowlists through --allowedTools and permission modes. Codex’s exec defaults to a read-only sandbox, with explicit opt-up to workspace-write or danger-full-access. Its isolation uses seatbelt on macOS and bubblewrap plus seccomp on Linux, with Landlock as a legacy fallback. OpenCode distinguishes Build and Plan through permissions. Build has all tools enabled, while Plan defaults edits and bash commands to asking permission.

Cursor’s August 2026 Builds feature boots cloud agents into a pre-configured environment, with reported time to first token roughly three times faster. Failed builds do not activate, so agents can keep working while someone debugs offline. MCP configuration belongs in this same decision because tool definitions consume context, results can be long, and excessive permissions can turn a small request into a large incident. Routing should match the permissions to what the task needs and load tools on demand with least-privilege enforcement.

How latency budgets and cost profiles complete the routing decision

Once task requirements and permissions align, the pairing must meet latency and cost limits to remain useful at the required volume. These are distinct constraints. Blocking work makes the engineer’s wait especially important. When many tasks run in parallel in the background, cost per task matters more, so the routing policy should give each constraint a different weight by task class. A technically capable pairing can otherwise be too slow for interactive work or too expensive for routine execution.

Cursor’s Router implements this distinction through Cost, Balance, and Intelligence modes, while allowing team leads to set defaults and restrict model availability. Cost governance sits inside the routing layer. The same index reports a higher score, $13.00 per task, and longer per-task time for the Claude Code pairing, showing why maximizing benchmark quality differs from maximizing throughput per dollar. Neither objective alone defines the right assignment. The relevant trade-off depends on the consequences of delay and the difficulty of the work.

OpenCode’s mid-session model switching adds an escalation route when the initial task classification proves too optimistic. A task can start on a cheaper model and move to a more capable one if it proves harder than scoped. Fixed pairings cannot support that same switching pattern. Without cost tracking by task type, however, teams tend to default to the highest-capability model regardless of need. That removes the economic distinction the routing policy was meant to preserve.

Workflow integration as a routing constraint that precedes model selection

The place where a task starts and the place where its result must land can exclude a pairing before model quality becomes relevant. A Slack-triggered task that must return a pull request has an integration requirement as well as a coding requirement. A capable local harness is not enough. For Codex, the hosted-path restriction described earlier rules out the API-key path for that Slack workflow, including when the team otherwise prefers API-based execution in CI.

Linear’s agent platform makes the accountability boundary concrete by keeping the human as assignee and the agent as contributor. The distinction preserves ownership while allowing the agent to perform work that returns for review. Contribution does not transfer responsibility for the issue. Issue-to-PR routing therefore has to account for both who remains answerable for the change and which agent can generate it.

MCP adoption across Claude Code, OpenCode, and Cursor increasingly standardizes tool discovery, but discovery does not establish control. Control over an integration takes load-on-demand access, least privilege, and audited calls as well as a connection. Integration breadth is also an unstable basis for permanent standardization as harnesses add and drop connections while moving toward model ownership. An agnostic routing layer insulates the team from those changes. Its value lies in preserving the workflow while allowing the eligible model-harness pairings beneath it to change.

Context and session continuity as the hidden variable in routing reliability

Even a pairing matched to task, permissions, budget, and workflow can lose its advantage when context is poorly managed. Multi-step agents accumulate messages, tool calls, raw outputs, planner decisions, validation steps, retries, and orchestration metadata. Much of that state eventually becomes irrelevant. Stack traces, file diffs, test output, and abandoned plans can stay in the prompt after they stop helping the agent decide what to do next. Routing to a stronger reasoner does not resolve that structural failure by itself.

The architectural response is to separate persistent memory from task context. Stable conventions, approved decisions, and recurring constraints belong in persistent memory, while the goal, exclusions, acceptance criteria, and current plan define the task. Mutable facts need retrieval from their source when relevant. This separation preserves decisions that should survive without blurring the boundary of the work now assigned. It also makes continuity a criterion for choosing a harness.

Claude Code provides session mechanisms through --resume, /branch, and Remote Control, while OpenCode uses LLM-summary compaction. Shared repository skills supply another form of continuity. One engineer can write and commit a deployment procedure that every future session follows, making a useful decision available beyond its original conversation. Supermemory’s MCP server and plugins for Claude Code and OpenCode provide native memory access without custom integration, including persistence of touched files, preferences, and previous attempts. For routing, the implication is to favor stronger continuity and compaction for long-running or retry-heavy tasks, reserving ephemeral sessions for bounded work that completes in one run.

Why productivity metrics must close the routing feedback loop

Dynamic routing improves reliability only when measurement shows what each assignment actually produces. Otherwise, even a carefully designed policy can persist after its assumptions stop matching the work. Activity counts cannot establish that the policy works. Lines of AI code and tasks completed do not reveal whether changes merge sooner, fail less often, or consume less senior review time. The useful measures are issue-to-merged-PR cycle time, change-failure rate, senior-engineer review load, and the share of the test suite the agent maintains.

LinearB’s 2026 Engineering Benchmarks Report found that AI-generated PRs wait much longer for review but take less time to review once picked up. It also found substantially lower acceptance rates for AI-generated PRs than for manual PRs. This is a direct challenge to equating faster generation with better delivery. A routing policy can help an agent finish sooner even when the wait for review still takes the most time. Adoption without a feedback loop risks optimizing the process ineffectively and provides no evidence against agent use itself.

Recording source, harness, model, and credential for every agent minute gives teams the basis for comparing cost and change-failure rate by task class. Perceived speed is not sufficient evidence for reassignment. The sustainable practice is to review routing policy each sprint or monthly, using PR cycle time and change-failure rate as the primary signals. Model-harness assignments should change when a pairing consistently underperforms its expected profile.