The February Release and What Actually Changed
Anthropic released Claude 3.7 Sonnet in February 2025 with a feature they called extended thinking mode, and if you’ve been paying attention to the AI space, you know that whenever a major lab adds significant latency to their flagship model, something genuinely different is happening under the hood. What they built here is the ability for the model to allocate up to 128,000 tokens to internal reasoning before it ever generates a response you see. Think of it as giving the model a scratchpad that works in real time, the same way you might work through a difficult architectural decision on a whiteboard before committing anything to code.
The timing matters. By early 2025, the industry had settled into a comfortable rhythm with large language models. Fast, mostly accurate enough for obvious tasks, and people had developed strong opinions about where they could and could not be trusted. Then Anthropic released this, and the conversation shifted immediately. The question stopped being “is the AI good enough” and became “what are you actually trying to do, and how much latency can you actually tolerate.”
Performance Metrics and the Real-World Scoring That Matters
On the technical benchmarks, Claude 3.7 Sonnet scored 70.3 percent on SWE-bench Verified, the highest score any AI coding assistant has achieved at launch. If you’re not familiar with SWE-bench, take a look at the SWE-bench Verified leaderboard to understand what we’re measuring here. This isn’t a synthetic coding quiz. These are real, open-source software engineering problems that require the model to understand existing codebases, reason about architectural constraints, and generate patches that actually work. A 70.3 percent success rate on that benchmark means something genuinely different than an 85 percent score on a multiple-choice test.
But here’s what the benchmarks don’t capture, and this is where six months of production use teaches you something the lab reports cannot. The difference between 70.3 percent correct and 85 percent correct on these problems isn’t statistical noise. When you’re shipping code, that gap means the difference between code review feedback that says “this looks solid, minor nit on line 47” and code review feedback that says “this fundamentally misunderstands how our error handling works.” The extended thinking tokens are doing something real in those edge cases.
The Latency Reality and When It Breaks Your Workflow
Extended thinking mode adds between 15 and 45 seconds of latency per complex query on average. That’s not a rounded-for-effect number. That’s what the production telemetry actually shows when you’re using it at scale. Sometimes it’s faster. Sometimes, on genuinely difficult reasoning problems, the model uses most of those 128,000 tokens and the latency creeps toward the upper bound. The first time you experience this, it feels slow. The fiftieth time, you stop noticing the time and start noticing the quality of what comes back.
Six months in, I’ve watched engineering teams split into two camps on this exact question. The first camp, usually teams working on internal tooling or offline batch processes, finds the latency completely acceptable. Their reasoning is straightforward: if the code I generate needs fewer revisions, and I’m not waiting for a human to review it anyway, then spending an extra 30 seconds per query saves time overall. The second camp, usually teams building user-facing features or real-time integrations, finds that extended thinking doesn’t fit their development workflow. They’d rather iterate quickly with a slightly less accurate model than wait half a minute for each response, even if that half minute gets them better code.
Both positions are defensible. This isn’t a case where one group is right and the other is wrong. It’s a case where the technology enables genuinely different tradeoffs, and you have to understand your own constraints well enough to choose the right tool for your situation.
Production Bugs and the Trust Problem
GitHub’s 2025 Developer Survey asked over 11,000 developers a simple question: have you shipped a production bug that you attributed to over-trusting AI-generated code? 62 percent of developers using AI coding assistants said yes. That number deserves to sit with you for a moment. It’s not 15 percent. It’s not 40 percent. More than six in ten developers. Some of those bugs were minor. Some were genuinely serious. The point is that the reliability concerns around AI-generated code are not theoretical.
What I’ve observed across six months of production use with extended thinking is that the mode does something unexpected to how people interact with AI-generated code. It doesn’t make them trust it more, exactly. The fact that the model is “thinking” for 30 seconds creates a weird psychological effect where people assume the output must be more reliable. Sometimes it is. Sometimes the model is just being more careful in a way that doesn’t actually address the specific blind spot in the code. The extended thinking tokens don’t protect you from architectural mistakes or domain knowledge gaps. They help with logical consistency and multi-step reasoning. Those are different problems.
The key lesson from six months of watching this play out is that extended thinking requires more discipline, not less. You need to understand what the model is actually reasoning about. You need to review the code with the same care you would apply to any code that touches production systems. The thinking tokens are a gift, but they’re not a guarantee.
The Cost Factor and Why It Matters for Real Projects
Anthropic’s pricing for Claude 3.7 Sonnet with extended thinking runs at $15 per million input tokens and $75 per million output tokens. If you’re using the extended thinking features heavily, that becomes a significant operational expense. A mid-sized engineering team running 50 complex queries a day at an average of 10,000 input tokens and 2,000 output tokens per query is looking at roughly 15 to 20 dollars per day, around 400 to 500 dollars per month just for the API calls. Scale that across an organization, and it’s real money.
The calculus changes depending on where you sit in the organization. For a startup or small team, that’s the cost of a junior developer’s coffee for a month. For an enterprise, it fits into the noise. For someone building a side project or trying to learn something new, it might be too much. Extended thinking is powerful, but it’s not free, and you need to know whether the problem you’re solving justifies the cost.
If you’re just getting started with this tooling, begin with a small, defined project. Pick something where the latency doesn’t break your workflow. Use extended thinking only on the genuinely complex parts of the problem. Learn what kinds of reasoning the model actually benefits from having the extra tokens for, and what kinds of problems you can solve just fine with faster inference. After a month or two, you’ll have enough data to make real decisions about how this fits into your development process.
What has your experience been with extended thinking models, or what questions do you have about integrating them into production systems? I’m curious what problems are pulling you toward this technology and where you’re skeptical. Reach out if you want to dig into specific use cases.