The evidence supports a clear hierarchy: Sonnet 4.5 as default workhorse (handling 70–80% of tasks), Opus for architecture-level reasoning and complex debugging, and Haiku with extended thinking as the underutilized powerhouse for high-volume operations. But the nuances matter enormously, and static rules break down without understanding failure modes.
The gap between tiers is real but narrower than most developers assume. On SWE-bench Verified (the gold standard for real-world coding), Opus 4.5 scores 80.9%, Sonnet 4.5 hits 77.2%, and Haiku 4.5 reaches 73.3% — a total spread of just 7.6 percentage points. For context, Haiku 4.5 at $1/$5 per million tokens outperforms Claude Opus 4.1 (~72%), which cost $15/$75 just months ago.
The tiers diverge sharply on tasks requiring sustained reasoning and multi-step tool use. On Terminal-Bench 2.0 (agentic terminal coding), Opus 4.6 scores 65.4% versus Sonnet 4.5’s 51.0% — a 14-point gap. On MCP Atlas (orchestrating multiple tools at scale), Opus 4.5 scores 62.3% versus Sonnet 4.5’s 43.8% — an 18.5-point chasm. On OSWorld (agentic computer use), the spread runs from Opus 4.6 at 72.7% down through Sonnet at 61.4% to Haiku at 50.7%. The pattern is unmistakable: as task complexity and agent autonomy increase, the gap between tiers widens dramatically.
| Benchmark | Opus 4.6/4.5 | Sonnet 4.5 | Haiku 4.5 | Gap (Opus–Haiku) |
|---|---|---|---|---|
| SWE-bench Verified | 80.9% | 77.2% | 73.3% | 7.6pp |
| Terminal-Bench 2.0 | 65.4% | 51.0% | — | 14.4pp+ |
| MCP Atlas (tool use) | 62.3% | 43.8% | — | 18.5pp+ |
| Aider Polyglot | 89.4% | 78.8% | — | 10.6pp+ |
| OSWorld (agentic) | 72.7% | 61.4% | 50.7% | 22.0pp |
Critically, HumanEval and MBPP are saturated — all tiers score above 90%, making these benchmarks useless for routing decisions. The real differentiators are multi-file, multi-step, and agentic benchmarks.
One surprising finding deserves emphasis: Opus 4.5 at medium effort matches Sonnet 4.5’s best SWE-bench score while using 76% fewer output tokens. At maximum effort, Opus exceeds Sonnet by 4.3 points while using 48% fewer tokens. This means Opus’s token efficiency on hard problems can make it cheaper per successful task than Sonnet when accounting for retry costs.
The economics of model routing changed fundamentally when Opus 4.5/4.6 dropped to $5/$25 per million tokens. The current tier structure:
| Model | Input/MTok | Output/MTok | Batch Input | Cache Read | Speed |
|---|---|---|---|---|---|
| Opus 4.6 | $5.00 | $25.00 | $2.50 | $0.50 | Moderate |
| Sonnet 4.5 | $3.00 | $15.00 | $1.50 | $0.30 | Fast |
| Haiku 4.5 | $1.00 | $5.00 | $0.50 | $0.10 | 3–5× faster |
The Opus-to-Sonnet ratio is now 1.67× on both input and output — compared to the previous 5× gap. The Sonnet-to-Haiku ratio remains 3×, making Haiku the clear choice when quality is sufficient. For a concrete sense of costs per task:
Real-world Claude Code usage averages $6/developer/day on Sonnet 4.5, with 90th percentile under $12/day. Prompt caching (0.1× input cost on cache hits) and batch API (50% discount) stack multiplicatively — a fully optimized pipeline can achieve up to 90–95% savings versus naive all-Opus usage.
No major coding tool implements truly intelligent task-based auto-routing. Instead, the industry has converged on a simpler, more robust pattern: phase-based splitting, where stronger models plan and weaker models execute.
Claude Code offers the most explicit routing controls. Its opusplan alias uses Opus during planning mode and auto-switches to Sonnet for execution — the closest thing to automated routing in production. Sub-agents can specify model: sonnet, model: haiku, or model: inherit in YAML frontmatter, and the CLAUDE_CODE_SUBAGENT_MODEL environment variable overrides all sub-agent models globally. Notably, sub-agents default to Sonnet even when the main session runs on Opus, and Claude Code uses Haiku behind the scenes for background functionality like commit messages and context summarization.
Aider pioneered the Architect/Editor split: the main “architect” model reasons about the problem in natural language, then a separate “editor” model translates that reasoning into file edits. This pattern delivers measurable gains — o1-preview as architect with a cheaper editor achieved 85% on Aider’s code editing benchmark, outperforming any single model.
Cursor uses a proprietary fine-tuned model for tab completions (separate from all chat models), offers an “Auto” mode that selects based on availability and reliability rather than task type, and transparently routes some background tasks to different providers. Windsurf runs a hidden planning agent alongside whatever model the user selects. Both tools demonstrate that dual-model architectures are becoming standard, even when not user-visible.
The community-reported workflow that emerges most consistently across platforms follows this pattern:
From a pure cost-efficiency perspective, the routing problem reduces to: what is the marginal quality gain per additional dollar spent? The data shows steep diminishing returns. Moving from Haiku ($1/$5) to Sonnet ($3/$15) — a 3× cost increase — buys a 3.9 percentage point improvement on SWE-bench (73.3% → 77.2%). Moving from Sonnet to Opus ($5/$25) — only 1.67× more — buys another 3.7 points (77.2% → 80.9%). The Sonnet-to-Opus upgrade is actually better value per point than the Haiku-to-Sonnet upgrade at current prices.
But this analysis changes dramatically by task type. On MCP Atlas (multi-tool orchestration), the Sonnet-to-Opus jump gains 18.5 points — extraordinary value. On simple edits, the quality difference between all three tiers is negligible, making Haiku the only rational choice. The Economist’s verdict: route by task type, not by default preference, and treat Opus’s effort parameter as a continuous cost dial rather than a binary tier decision.
The RouteLLM framework from LMSYS demonstrated that intelligent routing achieves 85% cost reduction while maintaining 95% of top-model quality. One enterprise reduced annual AI costs from $3.96M to $1.37M (65% reduction) through systematic model selection.
A well-designed routing system needs three properties: reliable escalation, graceful degradation, and observable decision-making. The critical insight from practitioners who tried auto-routing is that it fails: “I tried auto-mode and blind routing early on. Stopped using both. It led to indecision, unexpected cost spikes, and behavior I couldn’t reason about when something went wrong.”
The Architect’s recommended design follows a cascading pattern with explicit triggers:
Tier 1 — Haiku (default for sub-agents and simple tasks)
Tier 2 — Sonnet (default for interactive coding)
Tier 3 — Opus (reserved for high-complexity reasoning)
Fallback mechanisms: If any tier fails twice on the same task, escalate one tier. If Opus fails, flag for human review. Never de-escalate mid-task — complete the current task at the escalated tier, then de-escalate for the next task.
The community consensus is remarkably consistent. The most common workflow, reported independently across Reddit, Hacker News, Medium, and tool-specific forums:
Practitioners converge on Sonnet as the daily driver. A developer on the $20 plan described their approach: “I usually start with Haiku, then switch to Sonnet or Opus for harder tasks.” Continue.dev documented a workflow achieving 2× productivity using Opus for planning and Sonnet for implementation on a real data pipeline project.
The Pragmatist’s critical warning: avoid switching models mid-conversation. Switching requires re-sending the full context to the new model, consuming tokens and risking information loss. Instead, start new sessions when changing models. If you must switch, first ask the model to summarize the conversation state, then paste that summary into a fresh session with the new model.
The evidence hierarchy is important for calibrating confidence in routing decisions:
Strong evidence (benchmark-validated, multiple sources):
Moderate evidence (practitioner consensus, limited formal measurement):
Weak evidence (anecdotal, needs more research):
Models improve rapidly. Haiku 4.5 today outperforms Opus 4.1 from months ago. Any routing system built on fixed rules will degrade. The Strategist recommends:
Design for model-agnostic interfaces. Don’t hardcode “use Opus” — instead, define capability requirements (e.g., “requires multi-file reasoning,” “requires >200K context”) and map those to models dynamically. When a new model launches, update the mapping table without changing the routing logic.
Build feedback loops. Track which model-task pairings produce successful outcomes (tests pass, code review approved, no bugs in production). Use this data to continuously refine routing. Aider’s Architect/Editor pattern implicitly does this — if the editor’s output fails tests, the architect can adjust its approach.
Prepare for adaptive thinking. Opus 4.6’s adaptive thinking and effort parameter represent the future: a single model that dynamically scales reasoning depth. As this capability spreads to Sonnet and Haiku, the routing problem shifts from “which model?” to “how much thinking budget?” — a continuous optimization rather than a discrete choice.
Invest in context management. Opus 4.6’s compaction API (server-side context summarization) and thinking block preservation represent infrastructure that makes long-running, multi-model sessions viable. Teams that build their workflows around these primitives will maintain advantage as models evolve.
1. The Opus Hammer. Opus consistently overengineers simple tasks. One developer asked for email OTP login and received a 12-file authentication framework. Anthropic acknowledges this: Opus 4.6 “thinks more deeply and more carefully revisits its reasoning, which produces better results on harder problems but adds cost and latency on simpler ones.” Mitigation: use the effort parameter at medium for routine work, or simply use Sonnet.
2. The Haiku Speed Trap. Haiku’s sub-200ms responses create a false sense of progress. Developers accept lower-quality output because it arrives instantly and don’t review it as carefully. Haiku “tends to hallucinate when generating code exceeding 150 lines” and “loses track fast” in sessions beyond ~7 minutes of sustained work. Mitigation: pair Haiku with CI/linting gates and treat its output as a draft requiring validation.
3. The Mid-Conversation Switch. Switching models mid-session forces the new model to re-process the entire conversation history, consuming extra tokens and losing the nuanced “understanding” the previous model had built. Community consensus: start fresh sessions when changing models. Use external state (CLAUDE.md files, summaries, test suites) to transfer context.
4. The Thinking Token Explosion. Extended thinking tokens are billed as output tokens. One production test saw costs jump from $109 to $1,485 — a 14× increase — when reasoning-enabled modes were naively applied. Worse, extended thinking on simple tasks can hurt performance by up to 36%. Rule of thumb from practitioners: “If a human would do worse by thinking too hard, so will Claude.”
5. The “Everyone Needs Opus” Delusion. Developers on subscription plans who default to Opus for routine work hit usage limits and lose access entirely. “The best model is the one I can use, not the one I can’t afford.” Sonnet handles the vast majority of coding tasks with negligible quality loss.
The most effective multi-agent coding architectures assign models based on role requirements, not uniform capability. The evidence supports this role-to-model mapping:
| Agent Role | Recommended Model | Reasoning |
|---|---|---|
| Orchestrator / Planner | Opus 4.6 (medium effort) | Needs multi-file awareness, architecture reasoning; effort parameter controls cost |
| Implementation Agent | Sonnet 4.5 | Best quality/cost for code generation; handles 80% of coding tasks well |
| Code Reviewer | Opus 4.6 or Haiku 4.5 + thinking | Opus catches subtle bugs others miss; Haiku+thinking surprisingly strong (58% win rate vs Sonnet+thinking) |
| Explorer / Reader | Haiku 4.5 | Read-only codebase exploration; speed matters, reasoning depth doesn’t |
| Test Writer | Sonnet 4.5 | Benefits from semantic understanding; Haiku may miss edge cases |
| Formatter / Linter | Haiku 4.5 | Mechanical task; no reasoning needed |
| Commit Message / Docs | Haiku 4.5 | Simple generation; speed preferred |
| Security Reviewer | Opus 4.6 (high effort) | High cost of missed vulnerabilities justifies premium; Opus catches 50% “Important” issues vs Sonnet’s 41.5% |
Claude Code’s sub-agent architecture makes this practical. The main session runs on Opus via opusplan, while sub-agents individually specify their model tier. The CLAUDE_CODE_SUBAGENT_MODEL=haiku environment variable provides a cost-efficient default that can be overridden per-agent in YAML frontmatter.
For teams building custom multi-agent systems, the fan-out/fan-in pattern works well: an Opus orchestrator decomposes a task into independent sub-tasks, multiple Haiku or Sonnet agents execute in parallel (each touching different files), and the orchestrator aggregates and reviews results. Claude Code’s “agent teams” feature in Opus 4.6 supports exactly this — a demo showed 16 agents building a 100K-line C compiler in two weeks.
Critical implementation detail: sub-agents in Claude Code receive only their system prompt and basic environment details, not the full conversation history. This is a feature, not a bug — it reduces token usage by ~67% for multi-domain tasks and prevents context contamination between agents.
This methodology integrates evidence from benchmarks, community practice, tool architectures, and cost analysis into an immediately applicable framework.
Before sending any request, classify it along two dimensions:
Complexity dimension (determines model tier):
Error-cost dimension (adjusts tier up or down):
For Opus 4.6/4.5, set the effort parameter based on task difficulty:
For Haiku 4.5, enable extended thinking for any task beyond simple formatting — the data shows Haiku+thinking outperforms Sonnet+thinking on code review 58% of the time, making it the best value option for many tasks.
START → Haiku 4.5
├─ Syntax validation passes AND tests pass → ACCEPT
├─ Syntax fails OR tests fail → ESCALATE to Sonnet 4.5
│ ├─ Tests pass → ACCEPT
│ ├─ Circular fixes detected OR 2+ failures → ESCALATE to Opus 4.6
│ │ ├─ Success → ACCEPT
│ │ └─ Failure → FLAG for human review
│ └─ Task requires >200K context → ROUTE directly to Opus 4.6
└─ Task classified as reasoning-intensive → SKIP to Sonnet or Opus
For Claude Code specifically:
# Set main model to opusplan (Opus plans, Sonnet executes)
claude config set model opusplan
# Set sub-agents to Haiku for cost efficiency
export CLAUDE_CODE_SUBAGENT_MODEL=haiku
# Override specific sub-agents in YAML frontmatter where needed
# model: sonnet (for implementation sub-agents)
# model: opus (for security review sub-agents)
For custom multi-agent systems, follow this allocation:
This methodology rests on strong benchmark evidence for tier-level performance differences and robust community consensus on workflow patterns. However, several areas remain uncertain. The optimal effort parameter settings for specific task types have not been formally studied. Whether cross-model review consistently catches bugs that same-model review misses lacks rigorous measurement. The exact token-count thresholds that should trigger model escalation are based on heuristics, not empirical data. Quality variation during peak usage hours is reported anecdotally but unquantified. And the Haiku+thinking finding from Qodo, while striking, comes from a single benchmark on code review — its generalizability to other coding tasks is unknown.
The field is moving fast. Opus 4.6’s adaptive thinking, which dynamically scales reasoning depth per query, points toward a future where the routing problem dissolves into a single model with a continuous effort dial. Until that future arrives, explicit model routing with the methodology described here represents the evidence-based optimum.
Three insights emerge from this synthesis that go beyond conventional wisdom. First, the Haiku+thinking combination is dramatically underutilized — at $1/$5 per million tokens with extended thinking, it outperforms Sonnet+thinking on code review while costing one-third as much. Teams defaulting to Sonnet for everything are leaving significant value on the table. Second, Opus’s effort parameter has made static tier boundaries obsolete. Opus at medium effort is effectively a better Sonnet at a similar token cost, meaning the real routing decision is increasingly about effort level rather than model name. Third, phase-based splitting (plan with Opus, execute with Sonnet, utility with Haiku) has converged independently across every major coding tool — Claude Code’s opusplan, Aider’s Architect/Editor, Windsurf’s hidden planner, Cursor’s dual-model architecture — making it the one pattern with the strongest cross-validated evidence. Build your workflow around this pattern, instrument it with feedback loops, and prepare for the routing problem itself to gradually disappear as adaptive thinking capabilities propagate across model tiers.
Applications are always borns simple, with few complex codes but they always seem straightforward. But the business is here much earlier than the first sunlight hits the application code on the developer’s screen.
And business is complex, and you can’t avoid it. We can make it worse, business is always evolving and adapting. The application will carry those changes, and it’s easy to start to entangle models simply because they seem to be part of a unity. Being part of a monolith doesn’t mean you need to put concrete on top of your code and accept everything will break if you place boundaries.
Knowing the domains of your application is not an easy job, requires some day-to-day work with the codebase, conversation with other code folks, and sometimes with business folks. Not all domains will pop up in your mind (or screen), and there’s no rush to anticipate some of them just because you “started” domain segregation earlier. Domains could be explicit like “Accounts” that usually hold the application’s user data about, personal, billing, and security information. And other not so obvious like “Debt Validation” or “Umbrella Store Items” which already belong to a tangled code or another domain, but it’s so big and has too many self-references that you noticed you have a domain under a domain (or a realm inside a realm like I usually like to say).
Segregating your code into domains always is a good choice, your application usually will organize itself, and suggest to the development team a critical view of the business. We do not need to follow all fancy stuff from articles and books, our application (usually a legacy code) not always will accept it entirely without fighting against us. Sometimes simple segregation is better or at least is just a good choice to open your way for implementing a better code architecture that fits with the application (or corporate) needs in the future.
Work smart, not following recipes.
]]>With this in mind, and facing it every day, I decided to bring joy into it. Coding was always fun to me, a really creative part of my day. And to achieve it, I needed a (not really a code) pattern that will call the duty of holding the business and organizing it.
After revisiting some books like Clean Architecture by Uncle Bob, Domain Driven Design by Eric Evans, and Practical Object-Oriented Design (because I’m rubist) by Sandy Metz. A sparkle of an idea happened on how I could organize it. Implement a simple use-case definition, with a small contract to follow!
Not only the code solved the problem, but some concepts applied around the Rails architecture helped to achieve the solution. But we can leave this discussion for another time. From this idea and actions born Fluxus, a simple dependencyless library for containing the use-cases. Or just adding a set of logical steps that you and to predict what will happen.
Okay. But where is the joy? All steps to solve the problem, and having a brand new way to code and see a logical organization on it. There it is the joy! Building and bringing value to your own day!
]]>Then I have tried some languages, some tools, more than one time. I could list all techs that I’ve tried, but that not the focus of this post. And the fire was unexpected lit, after few minutes reading about Clojure. I felt the exact same feeling when I was tried Ruby by myself for the first time. That’s was a clearly match!
My study flow, is always evolving, and under strict adaptation. For Clojure studies, I’ve read a lot about language, and functional paradigm. Write few random codes on lein repl, to train some basics of language. And after this read more about language.
After 3 days, I felt really confortable with language. And I would like to go deep, and try to build things on Clojure. That’s right, I could write some codes from exercises list, but I always felt supressed when I face a list of exercises, and I subconsiously refuses to follow the exercises. (In fact, I had some problems in school classes with this kind of activities. Sometimes I was labelled “lazy student with good grades.”)
Ok, list of exercises was out of options. On Ruby I really like to write granular code, and I have several “in company” private gems, and some public gems. And in Clojure we have clojars, the idea raises up. Let’s build a clojar.
Recently I’ve a demand on Ruby code, to handle a realtime zipcode validation (we call CEP in Brazil), for boleto generation. (We’ll stop here about the demand, thats other topic, we can talk about it in other post. Who knows? :grimacing: )
That’s perfect, the idea was fresh in my brain. And the target service for consumption has a little outdated documentation. Then I will use this as point to research.
I’ve go into service sources, and tests, to learn and get new brand resources to insert into my clojar. I’ve tested all endpoints, and it’s all clear, working perfectly. (At this point, I really in debt with this project. I’m perfect able to update the documentation. I’ve put in my TODO list)
The service return the REST pattern, an 200 code with body when data cames from API. And a 404 code when API does not returns nothing. When I receives a 200, its easy to return a map with contents to user, with cheshire.
(Note: When you call parse-string, to convert the json into map, all keys cames as string too. If you want to get symbol-like in clojure. You need to fill a argument/parameter with true. I really don’t like it. Does not sound idiomatic.)
But when you get a 404 from service, clj-http raises a exception. The odds is always with us, we can perfectly handle this problem with slingshot, creating a custom catch for 404 code. I really like to throw exceptions, it’s more than a error for me. We can express unexpected behaviors, and handle with a situation without a cascade of conditionals (Let the destiny defines what you do).
And I choose to throw an custom exception for user, but more idiomatic. (:type ::nothing-returned)
Alongside this code flow, I built the tests, for sure. And I really like the clojure.test, it’s simple and get the job done. One of the points what I really like, is the use of with-redefs. I could do mock all clj-http client requests, and set responses without problem, and everything is core builted in language. And I write tests to cover all critical points of the simple “clojar”.
It’s done! Tests covering the code. And I think, it’s simple to use, and the source code is simple, and easier to maintain too.
I needed to create an account, just like rubygems. And after some few adjustments on project.clj, I was able to deploy the lib.
Just executing lein deploy clojars. It’s dead simple, like the website says. After some seconds, I get my clojar badge, and updates the README on GitHub.
After this, I built a simple Travis workflow, to test the code under openjdk-8 and openjdk-11 at every commit on master.
I found in Clojure a new way to think, and build things. I fell in my Ruby codes today, a huge influence of Clojure way to handle things. And I really like it.
If you have interest to see my “lib”, here’s url https://github.com/Rynaro/postmon-clj
Thanks for reading! :tada:
]]>One of most common ways to share files between companies is still FTP servers. And sometimes, you need to setup a FTP in-house, whether out compliance control, security, cost, or ‘cause its simple enough to do it yourself.
I’ve one FTP server in company that I work. It’s a simple FTP server, developed with Python, using pyftpdlib package, and aws S3 integration. We have a hook action, that send file into a folder mirror named bucket, to secure files, and after 15 days, we made a server FS clean, to guarantee healthy disk space level.
But recently, we get a specific trait from new partner, we need to expose an sftp server. In a quick search, pyftpdlib does not support sftp protocol. After this, I go to aws services, to see how much cost the use of AWS Transfer. It’s easy to use service, but expensive for a small startup, and I don’t think we need an entire service for this. In other situation, our monthly invoice will be affected by third-party factor, and one mistake made by our partner, could increase the invoice numbers.
Given the above factors, I decided to build a simple sftp from scratch.
First of all, you’ll need a server instance. In this case, I’ve used a DigitalOcean Droplet. My decision was driven by low-cost purposes.
I like Ubuntu server instances, and this “paper” uses the assumption the server is a Ubuntu server.
Make sure, your instance is updated.
# apt update && apt upgradeInstall vim, or use nano.
# apt install vimYou’ll need to create a user, for your third-party user. We’ll call our friend, as partner here. Say hello to Partner.
# adduser --shell /bin/false partnerYou can allow your Linux, to create home folders. But actually, I like to stay in front of situation.
If you allowed adduser to create home folders, then you don’t need to create a permitted folder space.
# mkdir -p /var/sftp/partner/filesRemember to guarantee permissions to Partner in your home sweet home.
# chown partner:partner /var/sftp/partner
# chmod 755 /var/sftp/partnerPartner is a common user inside our server. And without other (recommended) security rules, Partner will be able to make an ssh connection. And we don’t want this.
We’ll create a rule at end of file of sshd_config, for sftp only restriction.
# vim /etc/ssh/sshd_configThe content:
Match User partner
ForceCommand internal-sftp
PasswordAuthentication yes
ChrootDirectory /var/sftp/partner
PermitTunnel no
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding noAfter configure Partner restriction, you’ll need to restart SSH service to make sure changes take effect on server.
You can be disconnected after this. Just reconnect.
# systemctl restart sshCreate a password for partner if didn’t create one yet.
# passwd partnerFor sftp connection, try to connect in your server with partner credentials.
$ sftp partner@your-sftp-serverType password, and if everything is alright, you’ll enter inside partner sftp home folder.
Partner should has access only to sftp and no ssh connections should be allowed. The test is simple, just try to connect with SSH.
$ ssh partner@your-sftp-serverType password, hit enter. And you expect to receive this warning message.
This service allows sftp connections only.
Connection to your-sftp-server closed.After this, you can send the partner credentials to Partner. :joy:
This “tutorial” has the purpose to show a simple way to build an sftp server using only Linux resources. As you can see, this “tutorial” doesn’t go deep inside major security efforts. But, you can easily enforce your security, using Linux resources too, or using the service providers (aws, Digital Ocean, etc) tools.
]]>In this “notebook”, I will write (when I have a break) about my routine inside the codes, inside the books (I really like to talk about J.R.R Tolkien books), and whatever I want. :D
puts 'later! :)'
#=> prints 'later! :)' to STDOUT.