DEV Community

MT_Notes
MT_Notes

Posted on

After the Harness Went Open Source: The Agent Skeleton Is No Longer the Moat — the Model Is the Swappable Part

#ai #harness #apigateway

The setup: two skeletons dropped in one week

On August 19, OpenAI Developers published a post with an unusually blunt title: Codex as a platform: build on the open agent harness. The next day, Greg Brockman amplified it on X and resurfaced a May case study: a tax-preparation system built on Codex by Thrive Holdings and the accounting network Crete Professionals Alliance (rebranded as Current in June) processed 7,000 returns and cut accountants' preparation time by roughly a third.
The weight of this news isn't in a model. It's in the word "harness."
A harness is the layer wrapped around the model: the agent loop, context gathering, tool execution, sandboxing, approval flows, multi-turn state management. For two years, labs treated it as a core asset and kept it hidden. Now OpenAI has laid the entire Codex harness on GitHub (openai/codex) under Apache-2.0 — readable, modifiable, commercially embeddable, no copyleft obligations.
The timing is almost too neat. Six days earlier, DeepSeek open-sourced its own agent runtime, DeepSeek Harness v0.1, under MIT, built on the Cordis plugin system, which collected 23,000 GitHub stars within hours.
Two frontier labs gave away their skeletons in a single week. For developers, that's a structural shift: the hardest part of an agent system is becoming public infrastructure, and the model has been demoted to a component you can swap at will.

1. What is a harness actually worth? A benchmark answered

If your reaction is "it's just a loop with some tool calls," another OpenAI post is worth reading: How enabling two settings tripled our ARC-AGI-3 scores.
They didn't change models. They didn't retrain anything. They flipped two switches at the harness layer: preserved reasoning and context compaction. GPT-5.6 Sol's ARC-AGI-3 score went from 13.3% to 38.3%, close to a 3x jump. Output token count dropped to roughly one-sixth of the original.
That number should make anyone building agents pause. Same model, same benchmark — and purely because the outer orchestration changed, both capability and cost improved by close to an order of magnitude.
Put differently: we've been trained to attribute "results aren't good enough" to "the model isn't good enough," then reach for a more expensive model. The open harness tells you that a meaningful slice of that spend was recoverable through architecture all along.

2. Three integration surfaces: exec, SDK, app-server

What Codex opened up isn't a vague "framework" but three clearly separated surfaces. Picking the wrong one costs you a lot of pointless engineering, so it's worth getting straight:

The app-server is the headline. It is both a protocol and a long-lived process, composed internally of a stdio reader, a message processor, a thread manager, and core threads, with the thread manager spinning up one core session per thread. The protocol is bidirectional — the server can initiate requests (for instance, when it needs a human approval) and pause the turn until the client responds.
OpenAI is candid about an early wrong turn: they first tried exposing Codex as an MCP server, but found MCP's semantics hard to stretch across the rich interactions an IDE needs — diff updates, workspace exploration, streamed reasoning — which is why they built a JSON-RPC protocol instead. That's a useful lesson for anyone building an agent platform: MCP is a good fit for treating an agent as a callable tool, and a poor fit for making an agent the spine of a product.
To make the pattern concrete, OpenAI shipped a sample app called Relay: a fictional logistics operations dashboard where the agent pulls live data through the app's own MCP tools, the user clicks suggested actions like "Compare recovery options" rather than facing a blank prompt box, and any write action (rebooking a shipment) routes through human approval before it executes. GitHub and JetBrains embed Codex in their own workflows; Cisco uses it inside App Builder — all downstream of the same app-server protocol.

3. Open skeletons push all the cost pressure down to the model layer

There's a boundary worth stating plainly: the harness is free; inference is not.
OpenAI's own documentation is explicit — you can read and modify the code freely, but to run anything you still authenticate to a model. The open-source repo handles agent threads, tool execution, configuration, and approvals; model access requires a ChatGPT account or API setup.
So the landscape now looks like this:

  • Skeleton layer: commoditized, open source, zero cost, freely replaceable (Codex harness / DeepSeek Harness / Claude Agent SDK)
  • Model layer: differentiated, mostly closed, billed per token, violently volatile in price And what happened at the model layer this month? DeepSeek's V4 family moved to peak/off-peak pricing at 16:00 UTC on August 16, with peak-hour output rising from $$0.87 to $$3.96 per million tokens and cache-hit input rising more steeply still. GLM-5.3 landed on the API on August 18 at $$1.40/$$4.40. Grok 4.6 arrived on Amazon Bedrock on August 19 at $$2/$$6, with a 500K context window and four reasoning-effort settings. Stack those two facts and the conclusion is clean: once the skeleton stops being a moat, your engineering center of gravity shifts from "how do I write an agent loop" to "how do I keep the backend swappable in a violently shifting model market." Which happens to be exactly the thing harness architectures are structurally good at and operationally worst at — because every new model vendor means another API key, another invoice, another base URL, and another bet on somebody else's uptime.

4. In practice: collapse the harness's model exit into one endpoint

The Codex harness, DeepSeek Harness, and most agent frameworks share a useful engineering property: model access is injected through configuration, not hardcoded. That gives you a clean point of convergence.
The move is straightforward — point every harness instance at a single base URL and let the routing layer handle multi-model orchestration. Using wrouter.ai as the example:

from openai import OpenAI

client = OpenAI(
    api_key="wr-***",
    base_url="https://wrouter.ai/v1",
)

# One client, work assigned by task difficulty
# Cheap tier: the harness's high-frequency small steps (read a file, run grep, format a diff)
cheap = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[{"role": "user", "content": "Summarize the intent of this diff"}],
)

# Flagship tier: the one step that genuinely needs long-horizon reasoning
strong = client.chat.completions.create(
    model="claude-opus-5",
    messages=[{"role": "user", "content": "Refactor this module and propose a migration plan"}],
)
Enter fullscreen mode Exit fullscreen mode

If you're going the Codex app-server route, the idea is identical — point the harness's model provider config at the routing endpoint, and the harness's internal thread, approval, and sandbox logic stays untouched:

# ~/.codex/config.toml
[model_providers.wrouter]
name = "wrouter"
base_url = "https://wrouter.ai/v1"
env_key = "WROUTER_API_KEY"

[profiles.daily]
model_provider = "wrouter"
model = "gpt-5.6-sol"
Enter fullscreen mode Exit fullscreen mode

The payoff maps onto three things wrouter.ai is built for:
Stability. Agent failure modes are not chat failure modes. In chat, a single 429 means the user hits retry. In an agent, one timeout can send a forty-minute multi-step task back to the start. A single bad step contaminates the whole trajectory. A routing layer that presents one consistent surface while upstreams wobble is a practical way to take the edge off that long-task fragility.
Complete model coverage. This week alone produced three endpoints worth testing (GLM-5.3, Grok 4.6 on Bedrock, DeepSeek V4 Pro 0813). Registering with each vendor, clearing verification, and wiring up environment variables is enough friction to kill the evaluation before it starts. A complete catalog means A/B testing is a model-string change, not a new vendor account.
Unified billing. This matters more in the harness era than it did before. A single agent task can fire dozens of model calls spanning cheap and flagship tiers. When that spend is scattered across four or five vendor invoices, you simply cannot compute "what does one invocation of this feature cost." One bill lets you see every tier of the harness's consumption in one table, then decide which step to downgrade and which one earns the flagship.

Closing

On the surface, open-sourcing the Codex harness looks like OpenAI handing out another tool. In practice it's a public bet on where competition moves next: the next round of differentiation happens at the orchestration layer, not only at the model layer. Anthropic is betting the same way with the Claude Agent SDK and MCP.
For developers, though, the implication runs the other direction. When the orchestration layer is free and universally available, whatever differentiation you build into the skeleton gets flattened fast. What actually determines your product's cost and reliability becomes the swappable model interface underneath it — how steadily it connects, how completely it covers the field, how clearly it accounts for itself.
If you're wiring the Codex harness or DeepSeek Harness into your own product, clean up the model exit before you write a line of agent loop. Point base_url at wrouter.ai, run the whole catalog through one key and one invoice, then go back and tune your harness — that's the time this open-source release actually saves you.

Sources

Top comments (0)