a builder's codex
codex · operators · Drew Breunig · ins_breunig-harness-lock-in-model-layer

Frontier labs are baking native harness preferences into model weights, not layering them on top

By Drew Breunig · Technology strategist and writer · 2026-05-10 · essay · Overfitting the Harness

Tier A · TL;DR
Frontier labs are baking native harness preferences into model weights, not layering them on top

Claim

Frontier labs are training first-party interface behaviors directly into model weights. Each new model version is better at its native harness and more resistant to third-party customization.

Mechanism

When harness behavior is in the weights, every model update deepens the native preference. Third-party tools route against the grain of the model itself, not just the API surface. The native interface gets richer. The gap between native and third-party performance widens with each release.

Conditions

Holds when: You are building on a frontier model with significant first-party tooling. Labs have direct incentive to optimize the native experience.

Fails when: You are building on open-weight models where training decisions are transparent and no first-party harness exists to embed.

Evidence

Breunig's May 10 essay argues that labs are not separating the interface from the model. They are merging them:

"frontier models will resemble appliances, not general platforms"

The implication: the longer you route around the native harness, the more you pay for the detour.

Signals

Counter-evidence

Open-weight model providers have no harness to embed. The pattern applies to closed frontier labs with first-party products. If the frontier shifts to open weights, this risk diminishes. Labs also have financial incentive to keep APIs open for ecosystem revenue.

Open the interactive view → View original source → Markdown source →