stop using Claude Code if you're using open source models. read this. as you know we're building a coding agent harness for both open and closed models. processing billions of tokens an hours is teaching us lots of amazing things. Command Code is purpose-built for each model we launch, and it's getting better every day. the closest analogy i can think of is teaching a human to drive a car when they make a mistake, first you save them from the accident, then you teach them how to handle it next time. "open source models are bad at coding" is, almost always, a taste problem in the harness, not a capability problem in the model. claude code is a great harness. for claude. codex is fine too. for gpt. if you're using either for an open source model, you're going to have a subpar experience and conclude the model isn't smart enough yet. it usually is. even something as small as a couple of failed tool calls can completely disable a session. context: at @CommandCodeAI we've now pushed 10B tokens through our agent across closed (opus 4.7, gpt) *and* open (kimi k2.6, deepseek v4 pro, glm, qwen) paths, and we're adding ~1k new devs a day, mostly on the open side. you see things at that volume that i'm happy to share. the most consistent thing i see: "model X is bad at tool calls" almost always decomposes into "harness Y is built for model Z and silently breaks for model X, and nobody at the harness vendor cares because they don't run model X." that's not a moral failing it's an incentive structure. claude code is anthropic's agent, tuned for anthropic's model. codex is openai's, tuned for openai's. they're doing the thing they're supposed to do. but it produces a market where every other harness is a commodity router 1000 models in a dropdown, no per-model tuning, no per-model evals, no per-model repair logic. you click kimi, the harness shrugs, and when tool calls bounce six turns in a row, nothing gets logged. the model gets blamed. the harness moves on to the next dropdown entry. the analogy i keep coming back to is apple vs windows not the consumer-marketing version, the design-engineering version. one ships fewer skus and tunes the stack for each one. the other ships every sku and ships you the optimization problem. neither is wrong they're different products. coding agents have mostly been the second kind. i think there's a large opening for the first kind, and that's what we're building. Command Code with taste. the current landscape of big coding agents feels a lot like windows. "purpose-built per model" sounds vague until you list what it actually means. four things from the last few weeks we've observed and shipped: 1/ per-model tool input repair. deepseek-flash sometimes emits `filePath` as a markdown auto-link. opus never does. opus sometimes sends `null` for an optional field. deepseek doesn't. kimi wraps a single arg in `{}` when the schema wants an array. glm sends `"foo"` where the schema wants `["foo"]`. a generic harness sees all of these as "invalid tool call" and ships the model back a raw zod-issues blob. the model can't read it well, retries the same wrong call, gets the same blob. five turns of that and the user assumes the model is broken. it wasn't it was screaming into a room with no one in it. a purpose-built harness has a small ordered repair table per shape failure (we have ~four per model on avg), watches which models hit which repair, and turns that data into per-model defaults. the model gets to look as smart as it actually is. 2/ canonical model id at the request layer, slug translation at the sdk boundary. we route a single canonical model (`kimi-k2-6`) through 3-12 providers per model in priority order. each wants a different slug, a different request shape, a different auth header. the temptation is to fork that all the way through the agent loop. don't. one canonical id flows through billing, telemetry, evals, fallback. slug translation happens at exactly one boundary. a generic harness can't do this because it doesn't have the concept of "the same model on three providers" it has `moonshotai/Kimi-K2-Instruct` and `moonshot/kimi-k2-6` as two separate dropdown entries and your eval data is split across both. you can't tune what you can't aggregate. 3/ prefix-cache pinning, per provider. closed models have prompt caching as a product. open models have prefix caching as a side effect of inference-server implementation. the second your conversation lands on a different gpu pod, the warm prefix evaporates, ttft jumps from <1s to 6-8s, and the model spends its turn re-prefilling the system prompt instead of thinking. a one-line session pin (best-effort: same value, same pod) fixes it. a generic harness doesn't ship this because it would need a *different* one for every provider. we ship a different one for every provider. closed-model harnesses never have to think about this because anthropic and openai handle caching server-side and silently. open-model harnesses pay the cost loudly, and most just leave it there. 4/ tiered context compaction, tuned to the model that's loaded. at 50% of effective context, drop the oldest tool calls their results are dead bytes the model already extracted from. at 80%, the same, harder. at 90%, summarize, and only what's old. never compact the in-flight task. one primitive, three parameters. the thresholds aren't 50/80/90 of the model's advertised max. they're percentages of effective context, which sits well below the marketing number, because the last ~10% of any model's window is where its own attention degrades. you have to pick that ceiling per model. nobody publishes it. you find it in the data. a generic harness can't pick it per model, so it picks the marketing number for everyone, and the resulting agent gets dumb at turn 25 across the board. users assume that's just how agents are. it isn't. a few things to realize from all this: a coding agent's intelligence per turn is bounded by: - what fraction of context is actually load-bearing (compaction) - what fraction of tool calls survive contact with the schema (repair logic) - what fraction of turns get warm cache (pinning) - whether your eval data is one model or three pretending to be one (canonical id) closed-model harnesses get most of these for free because the model vendor handles them server-side and doesn't tell you. open-model harnesses don't get any of them for free. and the generic "1000 models in a dropdown" harnesses can't fix them at scale because there is no "the model" to tune for there is the union of all of them, which is the empty set. there is no general coding agent. there is a coding agent for each model you actually want to run well, and every one of them is a different product underneath the same harness. we're building that for you. coding agents have mostly been windows so far. we're taking inspiration from apple instead fewer skus, tuned for each one. taste, in engineering, is the willingness to do that work. the model isn't bad. your harness is generic. fix that.