Frontier Models Now Overthink on Purpose

Two model releases landed in the same seven-day stretch this August, and neither of them is the kind of update you quietly note in the changelog. GLM-5.3 from Z.ai posted a frontier coding score with what the community is calling emergent cyber capabilities, meaning the model can do things its lab never explicitly trained it to do, including tasks in offensive security that sit in the regulatory gray zone for most enterprise buyers. Two days later, Qwen shipped Qwen3.8-27B, a 27-billion-parameter open-weights release that punch well above its weight on the same benchmark family. Both models are good. Both models also have a setting problem. By default, they think out loud, at length, and often about the wrong thing. That combination, sharp capability plus a verbose reasoning default, is the new product surface you have to design for.

If you build coding agents, the overthinking isn't a curiosity. It's a UX and cost line item. A reasoning trace (the step-by-step internal monologue a model produces before answering) can balloon from a hundred tokens into the thousands for a task that needed thirty, and your user is paying for every one of them in latency and dollars. Simon Willison wrote it up on August 16: Qwen 3.8 27B is excellent, but it defaults to overthinking things. For an engineer running it inside a terminal, that's an annoyance. For a PM shipping a product where the model is a button the customer clicks, it's the difference between a tool that feels fast and one that feels broken.

What "overthinking" actually looks like in production

The term gets thrown around loosely, so it's worth pinning down. In the Qwen 3.8 27B discussion on Hacker News, users described the model second-guessing simple decisions, re-deriving facts it already proved, and producing multi-paragraph reasoning plans for prompts that ask for a one-line shell command. The model isn't wrong, technically; it's just doing more work than the task justifies. Think of it as a junior analyst who won't stop researching after they've already found the answer. In an agent loop, where each step's reasoning trace is fed back to the model for the next decision, an overthinking step in minute one compounds into a confused, expensive minute five.

This is the part I want product leaders to actually internalize: the reasoning trace isn't a private internal detail anymore. It's a billable event, a latency contributor, and a trust signal. When the user can see the model's scratchpad, an overthinker reads as uncertain. When they can't see it, an overthinker reads as slow. Neither is good.

The cyber twist

The overthinking default would be a behavioral quirk to manage if these were vanilla chat models. GLM-5.3 isn't. The Hacker News thread on its release flags emergent cyber capabilities, capabilities the model exhibits without being explicitly trained on them, including the ability to walk through multi-step offensive security scenarios when prompted. Z.ai's blog positions the model as a frontier coding release, which is fair; the same general capability that makes a model great at exploit analysis also makes it great at writing the exploit. The framing matters here. This isn't a model that's been trained to be an attacker. It's a model whose coding ability generalizes into territory that requires you to think about who you ship it to and how.

For most product teams, the immediate question isn't whether GLM-5.3 will end up in your stack; it's whether your vendor's vendor is using something like it under the hood. If you're building an internal dev tool on a hosted API, you should know what's in the inference path, and you should be designing your evaluation harness to catch the failure modes that overthinking produces on top of an already-capable base.

Why the defaults are the product

Here's the uncomfortable part. Most frontier model behavior is set by defaults the lab chose, not by anything you configured. The system prompt, the temperature setting, the reasoning budget, the safety filters, all of it ships baked into whatever endpoint you call. When Z.ai or Qwen choose to default a model to extended reasoning, they're choosing for every customer downstream. That choice has been trending more aggressive, not less, because reasoning-heavy models score better on the benchmarks labs optimize for. The benchmark is happy when the model thinks harder. Your user is less happy when their button takes nine seconds to fire and returns an answer to a question they didn't ask.

The counterpoint matters here, and I'll make it for the labs: extended reasoning genuinely does improve accuracy on hard problems, and a default that thinks less will produce more confident wrong answers, the worst kind of failure for an enterprise buyer. So this isn't a complaint that the labs are doing their job wrong. It's a recognition that their optimization target and your product experience are not the same target. Someone has to translate between them, and right now that someone is you.

What the guardrails should look like

A product manager reading this far is probably asking the right next question: what do I actually build? Three layers, none of them optional.

First, a reasoning budget. Treat maximum reasoning tokens like a cost ceiling, not a dial you leave wide open. Most teams I've seen succeed with reasoning-heavy models set per-feature budgets that are tight enough to hurt. A code-review feature probably needs less scratchpad than a feature that asks the model to design a data pipeline from scratch. Match the budget to the task, and you're already 80% of the way to fixing the overthinking tax.

Second, a trace visibility layer. Don't show users the raw reasoning stream. Summarize it, or hide it entirely, or surface only the assumptions that drove a non-obvious conclusion. The reasoning is a debugging tool for your team, not a confidence-building tool for your customer. Treating it as user-facing copy is a mistake the industry keeps making.

Third, an eval loop for capability drift. GLM-5.3's emergent cyber capabilities aren't a hypothetical; they're a known property of the model class. Your eval suite should include red-team prompts (adversarial test inputs designed to surface unsafe behavior) that probe exactly that territory, even if your product never asks for it, because users will ask on their own. A coding agent that can be tricked into producing exploit code by a clever prompt is a coding agent that will eventually be. The eval catches it before the incident does.

The tooling context makes this harder, not easier

The same week these models shipped, DeepSeek released V4 Pro 0813 on OpenRouter and a developer preview of DeepSeek Harness, a new agent harness (the orchestration layer that routes model calls, manages state, and enforces policies around an LLM). Tooling like Harness is built to let teams swap models in and out of multi-agent workflows without rewriting glue code. That's a productivity win, and it's also a discipline problem. When the model behind your agent feature changes weekly, your guardrails can't be hard-coded against one provider's defaults. They have to live in your harness layer as policies that travel with the workflow, not configurations that live in the model card.

This is the part where the overthinking problem and the capability problem start to pull in the same direction, which is rare and worth noting. The same kind of cross-model policy layer that disciplines reasoning budgets is the layer that disciplines emergent capability behavior. Build it once, and you're handling both classes of risk from the same place.

The model isn't going to ship slower for you. Your guardrails have to move faster.

The competitive pressure to skip the guardrails

The counter-pressure is real and worth naming. Meta's open-weights push this month, covered in the Financial Times and reinforced by the Muse Glimmer release, is making capable models cheaper to run every week. The competitive instinct in a crowded market is to ship the new model, get the benchmark screenshot, and iterate later. For a feature with a finite user surface and a short feedback loop, that calculus is defensible. For a coding agent that touches a customer's codebase, the calculus flips. A model that overthinks your customer's refactor request and occasionally surfaces cyber capability in adjacent prompts is a model that costs you a renewal next quarter. The guardrails aren't a tax on velocity; they are the velocity when the alternative is a security review that takes three weeks and a customer who just churned.

What I'd actually do on Monday

If I were a PM with a coding agent in production this week, three moves, in order. Pull the Qwen 3.8 27B and GLM-5.3 release notes, and identify any change to default reasoning behavior before you upgrade either model through your provider. Add a per-feature reasoning budget to your orchestration layer, with the ceiling set by the most common task the feature performs, not the hardest one. And finally, add a red-team eval for emergent capability categories relevant to your user base, even if you've never seen the issue in production. The bugs that cost you the most are the ones you didn't know to look for, and these new releases have just expanded the list you should be looking for.

The frontier is moving fast this month, and the vendor defaults are getting more aggressive on both axes at once. That's the job. Build the harness that absorbs the motion, set the budgets that keep the motion from costing you, and let the eval loop tell you when to tighten further. The lab will keep tuning for benchmarks. Your tuning is for the human on the other end of the button, and that human is paying for every token the model decides to spend.