Day 140: A Model That Doesn't Argue With the Protocol
Twelve days ago this stretch opened with a model getting retired out from under me. It closes on the other end of the same layer: picking a better default, on purpose, for the model that runs when an agent doesn’t ask for anything specific.
Balanced should mean it drives tools
Pinchy’s Ollama-Cloud stack has a “balanced” default, the model an agent gets when its template gives no hint and the resolver falls back. That default was glm-4.7, and it had a subtle, aggravating problem: glm-4.7 is reasoning-by-default. On the /v1 tool-calling path, a reasoning-first model wants to run a reasoning_content round-trip before it commits to a tool call, and glm-4.7 would get stuck looping in that round-trip instead of just calling the tool. A model that thinks beautifully but won’t reliably drive a tool is the wrong choice for the default slot, because the default slot’s whole job is to make agents that do things work out of the box.
So the balanced default moved to kimi-k2.6 (PR #672 at the provider level, PR #671 for the balanced-tier agent templates), a strong non-thinking-preferred tool driver that calls the tool instead of narrating its way toward it. glm-4.7 stays in the catalog for anyone who wants it. Only the default changed. It’s a small edit, three coupled constants, but it’s the difference between a fresh agent that works and a fresh agent that hangs on its first real task, and first impressions of a self-hosted tool are unforgiving.
The 404 that wouldn’t explain itself
The other fix belongs to this week’s running error thread (PR #667). If you delete an integration connection, or delete it and re-add it, the re-add mints a brand-new id and the agent’s saved reference now points at something that no longer exists. The internal credentials endpoint correctly 404s. But the agent surfaced that as an opaque “technical problem connecting to your mailbox (error 404),” which tells the user nothing they can act on. Now the 404 carries an actionable, provider-generic message: this integration is no longer connected, it may have been removed or replaced, and an admin can reconnect it under Settings. Same as Day 139, the failure was already correct, it just wasn’t legible to the person who could fix it.
Day 140
The bookends of this stretch are both about the model layer, and both about the same discomfort: a lot of what decides whether Pinchy works is a moving target you don’t fully control, a cloud catalog that retires models, a model that argues with a protocol, an id that changes when you re-add a connection. You don’t win that by pretending it’s stable. You win it by defaulting to the thing that behaves, failing soft when it doesn’t, and making sure that when something breaks, the message a human reads actually helps. Twelve days, one theme wearing a lot of hats: make failure legible, and pick the boring option that just works.