Every Harness Has Its Quirks

You don’t use Claude, or GPT, or Gemini. You use a harness wrapped around them, and the harness is a different animal than the model inside.

Everyone keeps a private list

Run more than one agentic CLI and you start keeping a list, whether in a scratch file or just in your head. It isn’t a list of the model’s reasoning failures; those are loud and endlessly benchmarked. It’s the small stuff that makes you mutter at the terminal but never quite bothers you enough to file an issue.

Mine reads like a field journal from four expeditions. In Kimi Code CLI, exiting the session can make the input box vanish, leaving you to type blind into a smear of overlapping characters until you kill the pane. It crashes on loops, too. In headless mode it crawls, and you can’t tell whether it’s slow per token, slow per call, or just thinking three times as hard because nobody told it to stop. Even @ can’t reliably find a file that’s sitting right there in the repo.

Codex barely belongs on a grievance list. It’s a good harness, fast and stable. The one thing that bites me is the lack of per-project slash commands, which means I can’t build the repo-specific shortcuts I use in every other tool. When I pick Claude over Codex, that’s the model talking, not the wrapper: Opus 4.8 edges GPT-5.5 for the work I do. It’s the one place in this whole essay where the model, not the harness, decides it for me.

Gemini’s the strange one. The model is brilliant, one of the smartest things I can put in a terminal, and I still won’t let it drive my code. I love it as a chat tool and open it every day. As a copilot it isn’t there yet, so it rides in the passenger seat. Claude I trust in the loop, and even Claude has its grievances: -p feels throttled, slower than the interactive session for reasons that never make the label, and every few weeks the nagging sense that it went dumb overnight.

Four tools produce four catalogs of the same kind of pain. Apart from the Opus exception, none of it comes from the intelligence. It comes from input handling, file search, default flags, and headless plumbing: the wrapper around the model.

You touch the model a few times a session: an answer you read and accept or reject. You touch the harness on every keystroke.

The year the harness got a name

To its credit, 2026 is the year the industry stopped pretending the model was the whole story. “Harness engineering” got conference talks and a formula people actually repeat: Agent = Model + Harness. The model is the relatively fixed part, while the harness determines whether it does anything useful through its memory, tools, permissions, hooks, and the rest of the runtime around the weights. The prevailing view is that much of an agent’s real-world performance lives outside the model.

The cleanest proof is happening at Google right now. Gemini isn’t a weak model; by the numbers it’s one of the strongest there is. But its coding experience lagged so far behind its IQ that Google’s fix wasn’t a smarter model. At I/O, the company retired the Gemini CLI and started moving everyone onto Antigravity: same weights, different harness. Google didn’t decide Gemini needed a higher IQ. It decided the model needed a better wrapper. That’s the whole argument in a single product decision, and it’s why I keep the model in the passenger seat while waiting impatiently for its replacement harness.

Here’s the part the whitepapers skip, though. They sell the harness as architecture: memory systems, tool contracts, observability, the stuff you design and put your name on. That’s real, but it’s only half the story. The other half has no diagram; it’s where the input box disappears and the default flag betrays you. The harness you build and the harness you suffer are the same harness. The industry only fell in love with the first one.

The day Claude “got dumber”

For about six weeks, threads kept asking the same question: Is it just me, or is Claude Code getting dumber? People floated theories about secret quantization and accused Anthropic of a quiet bait-and-switch. They were right that something had changed, but most took the wrong lesson from it.

Then Anthropic posted the postmortem, and the cause was almost boring: three changes, none of them to the model. On March 4, the default reasoning effort dropped from high to medium to reduce latency, so it was simply thinking less. On March 26, a caching change meant to clear stale thinking once instead cleared it every turn, making the tool forgetful and repetitive. On April 16, a verbosity instruction in the system prompt quietly hurt coding. In Anthropic’s words, “We never intentionally degrade our models… our API and inference layer were unaffected.” What users experienced as a nerfed model came down to a default, a caching bug, and a prompt tweak.

Don’t mock the people who cried nerf. Their gut was right; something had degraded. They just blamed the wrong layer, and it’s the easy layer to blame. The model has a name, a version number, a vendor to be mad at. The harness is invisible: undocumented defaults, prompt changes you’ll never see. When something feels off, you reach for the named suspect and walk straight past the silent one.

I do it too. I wrote above that -p “feels throttled,” but that’s only a hypothesis I haven’t tested. More likely, a default or context path behaves differently when no human is watching. Debug the tool the way you’d debug production: find out what shipped instead of immediately posting that the vendor nerfed it this week.

Telling a genuinely worse model apart from a harness that moved is its own skill now. The most demanding users of the most-watched tool in the business spent six weeks certain they were watching the model rot. They were watching a flag flip.

Nobody benchmarks the papercuts

We measure models to death with SWE-bench, Terminal-Bench, and dashboards that track quality drift by the hour. It’s impressive work aimed at the wrong target.

Gemini is the indictment. By the numbers, it’s a triumph, with SWE-bench Verified above eighty percent and top placements on nearly every chart it enters. Yet it still isn’t a copilot I trust. The benchmarks call it the best tool on my machine; my working week puts it in the passenger seat. Those charts do not measure Kimi’s disappearing input box, @ failing to find an obvious file, or the need to run /effort max after a Claude default regresses. There is no evaluation for “the loop crashed and I lost my place.” That entire category of friction goes unmeasured because it doesn’t live in the model.

And it’s the friction that sets your pace. A model two points higher whose harness eats your input and can’t resolve a path makes you slower, not faster. The leaderboard grades the engine. You’re bottlenecked by the transmission.

Harness fluency is concrete even when it’s tacit: knowing which loops crash, how to lay out a repository so @ resolves, which defaults to override on day one, and what belongs in AGENTS.md versus CLAUDE.md. Much of that knowledge does not carry over; your Claude fluency buys you almost nothing on your first day with Kimi. That limited portability is exactly why the skill is valuable. Everyone gets access to the same converging weights, but not everyone has put in the hours with the tool.

”That’s not real engineering”

The objection comes from good engineers: I shouldn’t have to memorize one vendor’s papercuts. Knowing that Kimi’s TUI breaks on exit isn’t a skill; it’s unpaid QA for a company that should fix its own tools. That’s fair, but it misses the practical value in the same way similar objections have before.

Typing code is commoditized; that’s the premise the whole industry now operates on. As the typing disappears, leverage moves up a layer to how well you direct the system doing it. There was a wave of engineers who wouldn’t learn git because it was “just plumbing,” and another who wouldn’t touch the shell because it was “just glue.” The plumbing turned out to be the floor everything else stood on. Those engineers didn’t stay above it; they simply got slower.

Harness fluency is this decade’s version of that skill, with an even bigger payoff because the harness sits between you and every line you ship. Friction there becomes a tax on every task rather than a handicap on only one.

From the CTO chair

Everything above is “you” at the terminal. I also run an org, and from that seat the story gets bigger. The quirk isn’t one person’s tax, it’s that tax times every engineer who hits the same papercut alone.

The procurement instinct is to pick the winner, standardize on whatever model tops the chart, sign the deal, and call it strategy. It feels responsible, but it can be the expensive move because it spends all your attention on the variable that is converging and none on the one that compounds: how fluent your team is in the harness it uses every day.

Treat that fluency like infrastructure or watch it die with whoever holds it. The team whose CLAUDE.md, slash commands, hooks, and quirk-workarounds are checked into the repo and reviewed like code ships faster than the team where all of it is locked in three seniors’ heads. Same model, same tool, completely different pace.

Which makes constant tool-churn the org-level version of the nerf reflex: motion that feels like progress while resetting everyone to zero. Swap to the shinier CLI for a few benchmark points and you wipe months of accumulated fluency and re-bill onboarding from scratch.

So the job isn’t picking the smartest model; a spreadsheet can do that. It’s making fluency a shared asset that outlives any one engineer, and hiring for the part that survives a tool dying. Not “which model do you like,” but “can you tell a dumb model from a changed harness.” Ask anyone who’d gone deep on the Gemini CLI the week before Google retired it: the muscle memory evaporated, but the engineer who understood why a harness behaves the way it does was useful in the new one by lunch.

The model is what every competitor also gets to buy. Your team’s fluency in its harness is the thing they can’t.

The way out is the one we already built for the cloud

Fluency is the right answer for now, but it can’t be the whole answer. If you stop there, you’ve accepted the quirk tax as permanent, even though we’ve solved a problem with this exact shape before.

Rewind ten years. Every cloud had its own console, CLI, and lock-in, and “AWS fluency” was a real but stubbornly nonportable skill much like harness fluency today. We didn’t solve that problem by making everyone master three clouds; we built Terraform. Declare what you want once and target whichever provider you need, and the skill moves up a level from memorizing a vendor’s console to describing intent. Lock-in stopped being fate.

The same move is open for harnesses, and it’s overdue. Be harness-agnostic the way you learned to be cloud-agnostic. It won’t be perfect; Terraform still leaks provider-specific resources to this day. It only needs to make swapping the tool underneath your work a configuration change instead of a re-education.

It can work because the quirks split into two kinds. The mechanical ones are interface friction: claude -p versus codex exec, the flag differences, CLAUDE.md versus AGENTS.md, whether your skill packs port to the next tool. Interface friction is precisely what an abstraction layer dissolves. The behavioral ones don’t abstract away: the TUI eating your input, the flipped default, whether the model is sharp this week. So agnosticism doesn’t replace fluency. It splits the work: abstract the mechanical, stay fluent on the behavioral.

I’ll put money where my mouth is, because pointing in a direction is cheap. I built a small router called par that gives my scripts one stable prompt interface, forwards each request to the selected local harness, and translates the call into that tool’s native command. It is nowhere near a Terraform; it is an early and deliberately small bet that a script should say what it wants rather than which CLI happens to be fashionable this quarter. When the Gemini CLI shuts off in favor of Antigravity, the wager is that I can rewrite one adapter instead of every pipeline I own.

That’s the actual exit: fluency helps you survive the harness today, and abstraction keeps you from becoming its hostage tomorrow.

What to actually do

Keep the journal, because that scratch file of grievances may be the most useful document in your workflow. Write down each quirk the moment it bites, along with the loop that crashed or the flag that fixed it. You’re building the manual the vendor didn’t ship.

Then do the boring work. Pin your versions so the ground stops moving without your consent. Read the changelogs and postmortems; Anthropic told everyone exactly what broke and when, but many people raging in the threads never read the explanation. Override defaults that are tuned for latency demos instead of your work. Go deep enough in one harness to be fast today, but don’t integrate it so tightly that its retirement costs you a re-education instead of an adapter.

The next time the tool “gets dumb,” investigate your own setup first. Ask what changed, which version you’re running, which defaults moved, and what shipped recently. The urge to broadcast a nerf is a sign that you’ve stopped treating the harness as something you can reason about.

The teams pulling ahead in 2026 aren’t necessarily on the highest-benchmark model. They know their harness cold. They reach past the broken input box without thinking, feel a regression in a day instead of a month, and quietly build the abstractions that will let them walk away when they need to. Every harness has its quirks; learning them is the craft, and avoiding dependence on them is the next one.