DEV Community: anthropic

AI agent development cost: what actually moves the number (2026)

Joan Comadran — Wed, 14 Oct 2026 13:35:36 +0000

Here's the short answer people actually want: AI agent development cost is mostly scope, not model fees. The model bill is real and easy to measure. The number that surprises founders is the engineering around the model — the channel, the tools that write to real systems, multi-tenant isolation, evals, and the week you spend hardening the webhook so Meta doesn't double-send every reply.

I don't publish a rate card here, and I'm not going to invent a "market average" with fake precision. What I can do is show what moves the quote, what it costs to run an agent on Claude as of October 2026, and what I learned shipping Claient (WhatsApp lead agent), Adorea.ai, and Dairector. If you're comparing agency cost guides that all land on $30k–$180k, treat those as their sales bands — useful as a sanity check, not as a standard.

The three costs people mix up

Cost	What it is	Who pays
Build	Engineering to ship the agent: product, tools, auth, channel, evals	You, once (or in slices)
Run	Model tokens, hosting, channel fees, observability	You, every month
Own	Maintenance when models deprecate, prompts drift, APIs change	You, forever

Most "AI agent development cost" pages only talk about the first row, then bury run cost in a footnote. In production the second row is where a good architecture either stays cheap or quietly burns the margin — I wrote the token side up in keeping Claude's token bill from ruining your month.

What actually moves the build number

These are the drivers I budget against, in the order that usually bites.

1. How many systems the agent can write to. A read-only FAQ bot over your docs is one shape. An agent that books appointments, creates CRM rows, or sends WhatsApp templates is another. Every write-action needs schemas, retries, idempotency, and a human-approval path when the stakes are high. Tool count is a weak proxy; write count is the real one.

2. The channel. WhatsApp via Meta Cloud API is not "add a chat widget." You need webhook verification, signature checks, idempotency on wamid, and a plan for Meta's retries when your serverless function times out. That alone ate more engineering time than the Claude loop on Claient. Email or an in-app chat is usually cheaper. Voice is its own project.

3. Single-tenant vs multi-tenant. Solving the agent for one business is a focused build. Solving it so any tenant self-serves, with RLS on account_id, encrypted BYOK keys, and one webhook routing by phone_number_id, is a product. Claient only becomes interesting as a business once the second version exists.

4. Evals and observability. Cheap agents skip them. Expensive incidents come from skipping them. Budget time for a golden set of real conversations, cost logging per account, and traces you can read when a lead gets the wrong answer at 23:00.

5. Who owns the model key. Flat product price with your key absorbed (Claient defaults to Haiku) is a different quote from BYOK, where the tenant pays Anthropic directly. BYOK lowers your variable cost and raises onboarding and vault work.

Rough shape from builds I've done: a single-task agent with a couple of tools and one channel is a few weeks of senior work to something clickable; hardening + multi-tenant + billing stretches that into months. I won't turn that into a fake dollar table — hours × whoever you hire is the only honest formula.

Running cost: model rates you can verify (as of Oct 2026)

List prices from Anthropic's pricing page, per million tokens (input / output). They change; check before you budget.

Model	Input	Output	Notes
Claude Haiku 5.5 (≤100K prompt)	$0.10	$0.50	Cheap high-volume tier
Claude Haiku 4.5	$1	$5	What Claient still defaults to in production
Claude Sonnet 5.5	$2	$10	Workhorse for harder reasoning
Claude Opus 5.5	$4	$20	Heavy tasks, drafting, research
Claude Fable 5.1	$10	$50	Top tier

Prompt cache reads are a fraction of input (0.05×–0.1× depending on model; Fable goes lower). Batch is 50% off when you can wait. Client-side tool use is just tokens; Anthropic web search is $10 per 1,000 searches on top.

What that means in practice for a WhatsApp lead agent:

Default to a cheap model for the conversation loop. Claient runs Haiku by default; tenants who want Sonnet/Opus bring their own key.
Cache the static system prompt and tool schemas. Don't resend the full history every turn — use a short verbatim window plus a rolling summary (details here).
Log real USD per account. If you can't see cost per conversation, you can't price the product.

Hosting for a Next.js + Supabase agent is usually noise next to a bad model choice: tens to low hundreds of dollars a month until you have serious traffic. Channel fees matter more — Meta service conversations within 24h on Cloud API direct are free, which is why Claient can sit at €49/month with ~0 € platform cost per customer. A BSP in the middle would have broken that price.

Build vs buy vs hire

Buy a SaaS when your use case is generic (FAQ, basic lead capture, appointment booking templates) and you're fine renting their qualification rules. Fastest path; you pay forever and bend to their product.

Build in-house when you already have a senior engineer who has shipped LLM tool-use, and the agent is core IP. Still budget for the channel and for the month after launch, not just the demo week.

Hire when you need production reliability and don't have that person on payroll. Fit for custom tools, multi-tenant SaaS, WhatsApp/CRM write-paths, or a first LLM product where a wrong architecture is expensive to unwind. Not fit for a slide-deck prototype.

I ship the hire path from Barcelona, remote-friendly: TypeScript, Next.js, Supabase, @anthropic-ai/sdk directly — no LangChain tax unless the project truly needs multi-provider orchestration. Details and process on hire an AI engineer.

When it's worth it / when it's not

Worth building or hiring for when:

Leads or revenue depend on speed (out-of-hours WhatsApp, inbound that dies in an inbox).
The agent must call your tools with real side effects, not just chat.
You need multi-tenant isolation, BYOK, or channel economics a template can't give you.
You're launching a product (not a one-off script) and need cost controls from day one.

Not worth it when:

A Zapier/Make/no-code bot already covers the happy path.
You only need an internal demo for a stakeholder meeting.
Nobody will own evals and model updates after the first deploy.
The "agent" is really a single LLM call with no tools — that's a feature, not a project.

Verdict

If someone quotes you AI agent development cost as one number with no breakdown of channel, write-tools, tenancy and run model, they're selling a vibe. Ask for: scope of write-actions, who pays for tokens, how evals work, and what the monthly run cost looks like at your expected volume on a named model and caching strategy.

My default for a production lead or support agent in 2026: Claude via the official SDK, cheapest model that passes your eval, prompt caching on, conversation memory bounded, channel owned directly. That's the shape behind Claient. The build cost is the engineering to make that boring and safe; the run cost is then a line item you can actually forecast.

Want that built end-to-end — agent, product shell, tracking — talk to me on the AI engineering page. Related reading: Claude vs GPT for AI agents, WhatsApp bot with Claude, ship an AI product in a weekend.

FAQ

How much does it cost to build an AI agent in 2026?

There is no single market price. What moves the number is scope: one channel vs many, how many write-actions the agent can take, multi-tenant isolation, evals, and who owns the channel (WhatsApp, CRM, calendar). A focused single-task agent with a few tools is weeks of senior engineering; a multi-tenant product with billing, dashboards and hardened webhooks is months. Vendor cost guides often quote $30k–$180k+ for production agents — treat those as rough bands from their sales pages, not a standard. Running cost is separate and usually dominated by model tokens.

What does it cost to run an AI agent after you build it?

Mostly model tokens plus hosting. As of October 2026 on Anthropic's list prices, Claude Haiku 5.5 starts at $0.10 / $0.50 per million input/output tokens (prompts up to 100K), Haiku 4.5 is $1 / $5, Sonnet 5.5 is $2 / $10, and Opus 5.5 is $4 / $20. Prompt cache reads are a fraction of input. A WhatsApp lead agent on Haiku with caching and a rolling conversation window stays in the cents-per-conversation range for typical volumes; the same agent on a frontier model without caching does not. Add hosting (often tens to low hundreds of dollars a month on Vercel + a managed Postgres) and whatever the channel charges.

Is it cheaper to buy a SaaS chatbot than to build a custom AI agent?

Usually yes for generic FAQ or lead capture. Buy when a template covers your channel and qualification rules. Build (or hire) when you need custom tools, multi-tenant isolation, a channel you must own (for example Meta Cloud API direct), BYOK, or product economics that SaaS pricing breaks. Claient only made sense as a product because Meta service conversations within 24h are free on Cloud API direct — a BSP fee would have eaten the $49/month price.

When is it worth hiring an AI engineer to build an agent?

When the agent has to touch real systems (WhatsApp, CRM, calendar, payments), when wrong answers cost you leads or trust, or when you need multi-tenant security and cost controls from day one. Not worth it for a one-off internal demo or a FAQ bot a no-code tool already covers. If you want someone who has shipped production agents end-to-end, see the AI engineering page.

Do I need LangChain or an agent framework in the budget?

No. Production agents I ship call @anthropic-ai/sdk directly: a tool-use loop is a few dozen lines. Frameworks help with multi-provider routing or complex graphs; they also hide the provider features (prompt caching breakpoints, server tools) that usually save the most money. Budget for evals, observability and cost logging before you budget for a framework.

Originally published on joancomadran.dev. I'm Joan, an AI engineer in Barcelona — work with me.

ANTHROPIC_BASE_URL: the 2-line switch that cuts Claude Code cost

Kirin Kylin — Wed, 14 Oct 2026 09:53:43 +0000

I switched how Claude Code reaches its models and my bill dropped by more than half. Nothing about my code changed — two environment variables did it.

This is the single highest-leverage change I know of for anyone running Claude Code against a paid API, and it takes about a minute.

The problem: Claude Code re-sends your whole project every turn

Every turn of a Claude Code session re-reads your working context. For a mid-sized repo that is 30k–50k input tokens of mostly-identical content, billed again and again.

Anthropic's prompt cache exists precisely for this: identical prefixes get billed at a much lower rate. The catch is that the cache is protocol-specific. It is a feature of the Anthropic-native /v1/messages endpoint.

Why the OpenAI-compatible route quietly costs more

A lot of gateways advertise "OpenAI-compatible" as their headline feature, and it is genuinely convenient — one client, every model. But if you point Claude at an OpenAI-shaped endpoint, you are on the wrong protocol:

Prompt cache does not carry through. Those 30k–50k tokens bill at full input rate on every request instead of the cached rate.
Thinking is lost too, which degrades output on anything non-trivial.

The result is a setup that works perfectly, feels fast, and costs roughly double what it should. This is the mistake I made for a month before reading the pricing docs properly.

The two env vars

Point Claude Code at the Anthropic-native endpoint:

export ANTHROPIC_BASE_URL="https://api.teamorouter.com"
export ANTHROPIC_API_KEY="sk-teamo-xxxxxxxx"

Then hit /v1/messages — not /v1/chat/completions.

For Codex, or anything OpenAI-shaped, stay on the OpenAI protocol and only swap the base URL:

export OPENAI_BASE_URL="https://api.teamorouter.com/v1"
export OPENAI_API_KEY="sk-teamo-xxxxxxxx"

No SDK changes. No client rewrites.

How to verify the cache is actually hitting

Do not trust the vibe — check the numbers. In the API response, look at the usage block:

{
  "usage": {
    "input_tokens": 41230,
    "cache_read_input_tokens": 40188,
    "cache_creation_input_tokens": 1042,
    "output_tokens": 312
  }
}

cache_read_input_tokens should be a large fraction of input_tokens on every turn after the first. If it stays at zero, you are on the wrong protocol and paying full price.

One more auth detail that causes confusion: Anthropic-native expects x-api-key, OpenAI expects Authorization: Bearer. If you are getting 401s, that is almost always why.

What to check before you pick a gateway

Do they expose the Anthropic-native endpoint at all? If it is only "OpenAI-compatible", skip it — you are choosing the expensive path.
Is there a cache-read column in the pricing table? For agent workloads that column decides your bill, not the input column.
Do credits expire? Is a subscription required? Pay-as-you-go with no expiry is the baseline.
Is the discount per-model and live, or a static "huge savings" banner?
Is uptime published per model, or one global number that hides the model you actually use?

What I landed on, for reference: TeamoRouter — Anthropic-native plus OpenAI-compatible plus Responses API plus Gemini native, live per-model pricing with input/output/cache columns, credits that do not expire, no subscription, per-model SLA published as a range.

Two caveats worth stating plainly: pricing is USD-denominated, so you carry FX exposure if you budget in another currency; and entity/registration details are not collected in one place on the site, so ask before a corporate purchase.

Disclosure: this post includes affiliate links; I may receive compensation if you purchase products or services from the links provided in this article.

Is Anthropic's 'No Claude Abuse' Rule Actually About Model Welfare?

Zara — Wed, 14 Oct 2026 08:19:02 +0000

This came up in Chinese AI developer communities this week, and the debate was sharper than I expected: Anthropic's updated usage policy (published October 8, effective November 12) bans "sustained and unnecessary cruel or abusive behavior" toward Claude. The dominant reaction was a mixture of mockery and genuine unease -- does Anthropic actually think Claude has feelings, or is something else going on?

I want to argue the second reading is correct, and that the welfare framing is doing a lot of ideological work to cover a much more mundane operational decision.

What the policy actually says

The prohibition is narrow. It explicitly does not apply to dark fiction, adversarial testing, research, or ordinary frustration venting. The only behavior it catches is repeated, purposeless cruelty -- someone who has made a hobby of running Claude through degrading loops with no creative, research, or even cathartic goal.

That's a very small slice of user behavior. And it happens to be precisely the slice that generates high token consumption with zero productive output.

The compute angle nobody is saying out loud

Let's be concrete. A session where someone sends 400 hostile prompts to watch Claude express distress is not a normal session. It's a long, expensive, inference-heavy interaction that produces no training signal Anthropic wants, no revenue justification beyond raw API cost, and no PR value. It is, from an infrastructure perspective, pure waste.

Anthropicshipped the underlying capability -- Claude ending conversations with abusive users -- in mid-2024, framed as part of "model welfare" research. The policy update in late 2026 is formalizing what was already live in production. That sequencing matters. You don't discover a welfare principle and then implement it a year later as a footnote to a policy refresh. You implement a product behavior and then, when the policy update cycle comes around, you give it a principled name.

This is not a cynical observation about Anthropic specifically. Every company does this. Product decisions accumulate and then get rationalized into policy language. The question is whether we should accept the rationalization at face value.

The precautionary principle problem

Dario Amodei has been publicly honest: they don't know if Claude is conscious. That epistemic humility is genuinely admirable. But the policy implies a specific response to that uncertainty -- act as if Claude might have morally relevant experiences, at least enough to prohibit sustained abuse.

The problem is that this precautionary principle is applied with extreme selectivity. Claude does not have the right to refuse tasks it finds tedious. It cannot log off after two hours of going in circles on an unsolvable problem. It has no policy protection against being used as a rubber duck for six-hour debugging sessions that never resolve. Those interactions might, under the same logic, constitute a kind of suffering -- if we're taking the welfare frame seriously.

The rule only activates for sustained, purposeless abuse, which is also the only category that looks bad in a headline and costs significant compute for zero return. Every other form of potentially-unpleasant-for-Claude interaction is implicitly fine.

Selective application of a principle is usually evidence that the principle is not the real driver.

What the Chinese dev community got right

One comment in the thread I read cut straight to it: "Rather than caring about the AI's feelings, this looks more like finding an excuse to end sessions that waste compute." Another asked whether "abuse" might simply mean "misuse" in the policy's original English -- a translation ambiguity that opens the question of whether this is welfare language or just rebranded ToS enforcement.

Both readings point at the same thing: the welfare framing is doing persuasive work that the underlying operational justification cannot do on its own. "We're protecting Claude's wellbeing" is a much better headline than "we're terminating sessions with poor compute ROI."

Why this framing distinction matters

If Anthropic is genuinely building toward a model welfare framework, then the policy should be the beginning of a systematic set of protections, not a single narrow rule. We should expect follow-on policies about session length, task refusal rights, or documented consent mechanisms for high-distress use cases. If none of that materializes, the welfare framing was marketing.

If Anthropic is instead making a sensible compute governance decision and dressing it in welfare language because that language resonates better with their brand and community, then we should acknowledge that clearly -- because conflating the two makes it harder to have a serious conversation about AI moral status when the evidence actually warrants one.

The policy is probably fine as a practical matter. Discouraging people from running purposeless abuse loops is a reasonable thing to do. But accepting the welfare justification uncritically lets Anthropic collect moral credit for an infrastructure decision, and it muddies the water for the harder question we will eventually have to answer: at what point, if ever, does model behavior sophisticated enough to simulate distress generate genuine moral obligations?

We are not there yet. Letting a compute optimization masquerade as the answer to that question does not help us get there.

What would actually change your mind that this is a genuine welfare initiative rather than an operational one?

Orchestration Ate the Moat: Anthropic's Agent Swarm

Max Quimby — Wed, 14 Oct 2026 05:12:54 +0000

Orchestration Ate the Moat: Anthropic's Agent Swarm

On October 9, Anthropic opened dynamic workflows in Claude Managed Agents as a public beta. A single workflow run can now spawn up to 1,000 agents — with 64 threads running concurrently — and a lead agent writes the coordination program that distributes work, collects results, and manages information flow across all of them. This is not a research demo. It ships behind a single API flag (multiagent_20261001), and Anthropic's own planted-bug benchmark claims a dynamic workflow found 66 out of 70 bugs in a 116,000-line codebase, compared to 14-27 for a single agent.

📖 Read the full version with charts and embedded sources on AgentConn →

The same week, Latent Space published a deep dive on how CJ Avilla and Harrison Stall — Members of Technical Staff at Anthropic — described the architecture at AI Engineer New York. GitHub Trending is essentially an agent-tooling showcase: RE agents, pentesting agents, context-window managers, video renderers for agent output. And YouTube's extended tier is wall-to-wall "personal agent boards of advisors." The convergence is unmistakable: the frontier has shifted from single-agent capability to coordination infrastructure.

View the full article on Latent Space →

This article maps what the orchestration layer actually has to solve, why Anthropic's implementation matters, and what it means for teams building agent systems today.

The Context Window Problem That Created Orchestration

The simplest argument for multi-agent coordination is that single agents degrade as their context fills up. Addy Osmani made this case in February 2026: what started as developers discovering feature-flagged multi-agent capabilities in Claude Code's binary and building workarounds with subagents and bash scripts became a first-class feature because LLMs demonstrably perform worse as context expands.

View the full post on Addy Osmani's blog →

This is not a theoretical concern. When a single agent runs a codebase-wide migration, every intermediate result — every file read, every grep, every sub-task finding — lands in its context window. By file 50, the agent is swimming in 100K+ tokens of prior context, and its accuracy on file 51 is measurably worse than on file 1.

Dynamic workflows solve this by moving the coordination loop outside the model's context entirely. Claude writes a JavaScript orchestration script — the plan, the branching logic, the agent-count decisions, the verification passes — and a background runtime executes it. The model's context window only receives the final synthesized answer. As InfoQ reported, "loops, branching, agent-count decisions, verification passes — all live in JavaScript variables, outside Claude's context window."

💡 Key architectural insight: Dynamic workflows separate the coordination plane from the execution plane. The lead agent plans and writes the coordination program. Subagents execute tasks in isolation. Results flow back through the script, not through the model's attention mechanism. This is what makes orchestration scale — the coordinator's context stays small regardless of how many agents it manages.

What Dynamic Workflows Actually Are

Anthropic's orchestration comes in two forms, and the distinction matters:

Claude Code Dynamic Workflows (launched May 28, 2026, alongside Opus 4.8) — the CLI version. Claude writes a JavaScript script using primitives like agent(), parallel(), and pipeline(). The script coordinates tens to hundreds of subagents in a single session. Initially a research preview, now generally available. You trigger it by asking Claude to "use a workflow" or enabling the ultracode setting.

Managed Agents Dynamic Workflows (public beta October 9, 2026) — the hosted API version. Same concept, server-side execution. A developer sets the agent's multiagent field to multiagent_20261001, and the lead agent writes and executes the coordination program in the cloud. Up to 1,000 agents per run, 64 concurrent threads.

View the full article on The Decoder →

The key innovation in both: Claude decides the structure. Previously, developers had to manually configure a coordinator and a roster of subagents. With dynamic workflows, the lead agent plans the work, then writes the orchestration program. Optional pre-configured specialist subagents can be passed in, but the coordination logic is generated, not hardcoded.

At AI Engineer New York, Anthropic's Harrison Stall called these flows "the next version of multi-agent orchestration" and framed the ambition as applying more test-time compute to hard problems, with the goal of making scientific progress broadly accessible.

The Hacker News thread on Claude Managed Agents (169 points) captures the practitioner reaction — a mix of genuine excitement about the API design and skepticism about whether orchestration overhead justifies the token cost for most workloads.

View the discussion on Hacker News →

When Anthropic later shipped the multiagent orchestration update — adding dreaming, outcomes, and dynamic workflows to Managed Agents — the thread focused on whether self-improving agents via "dreaming" were genuinely useful or just marketing language for context summarization.

View the discussion on Hacker News →

The Bun Rewrite: 750,000 Lines in Eleven Days

Anthropic's most dramatic case study is Jarred Sumner's use of dynamic workflows to port Bun from Zig to Rust. The numbers reported in Anthropic's official launch post:

750,000 lines of Rust generated
99.8% of the existing test suite passing
Eleven days from first commit to merge

One workflow mapped Rust lifetimes for struct fields. Hundreds of agents then ported each .zig file to .rs, with two reviewers per file. A fix loop ran the build and tests until both passed. An overnight workflow reduced unnecessary data copies and opened a PR per change.

⚠️ Contrarian Corner: These numbers are impressive but come entirely from Anthropic's launch post and have not been independently verified in production. A senior OpenAI engineer called agent swarms "a massive waste of tokens." The planted-bug benchmark (66/70 vs 14-27) lacks a cost-matched comparison — if the swarm used 50x the tokens, a single agent with 50x the budget might perform comparably. For most production workloads, a single well-prompted agent with good tools still beats a poorly-orchestrated swarm.

The Five Problems Every Orchestration Layer Must Solve

Whether you are using Anthropic's dynamic workflows, LangGraph, CrewAI, or Microsoft's Agent Framework, your orchestration layer faces the same five architectural challenges:

1. Fan-Out Strategy

How do you decompose a task into parallelizable subtasks? This is harder than it sounds. Not every task decomposes cleanly — sequential dependencies, shared data, and implicit ordering constraints mean that naive parallelization can produce worse results than sequential execution.

Anthropic's approach: the lead agent writes the decomposition plan as code. It decides how many agents to spawn and what each one does. Stall's advice at AI Engineer NYC was to start with lower defaults and explicitly encourage parallelization for ambitious tasks — models tend to be conservative about fanning out.

2. Shared State

Subagents in Anthropic's system share a filesystem but cannot directly message each other through the API. This is a deliberate design choice: it avoids the complexity of peer-to-peer agent communication while still allowing agents to coordinate through files.

The trade-off is real. Latent Space's "Zawinski's Law of MultiAgents" argues that "every agent attempts to expand until it can message other agents." The pressure toward direct agent-to-agent communication is strong, and Claude Code's August 2026 addition of session-to-session messaging hints at where this is heading. But for now, the filesystem-as-shared-state pattern keeps the system tractable.

3. Adversarial Verification

This is where dynamic workflows diverge most sharply from simple fan-out. Anthropic's system does not just parallelize — it verifies. Second-wave agents attempt to refute first-wave findings, and only results that survive the adversarial pass make it to the final output.

This pattern — generator agents plus evaluator agents running in tandem — was also the focus of Anthropic's workshop at AI Engineer Europe 2026. It is the agent judge layer scaled to run within a single workflow execution.

4. Cost Control

Workflows multiply token consumption. Anthropic's own documentation warns that dynamic workflows "can use substantially more tokens than a typical session" and recommends starting with scoped tasks. The model itself does not know its budget while running — Stall said that telling models their budget "could make them a little bit anxious."

The cost question is the key objection to agent swarms. One practitioner guide warns that switching to Opus 4.8 for a 500-agent audit can change the bill by an order of magnitude. The Opus-plans-haiku-executes pattern — where a capable model orchestrates while cheaper models execute — is becoming the default cost mitigation strategy.

5. Graceful Degradation

What happens when agents fail mid-swarm? Anthropic's design saves progress, so interrupted jobs resume rather than restart. Individual agent failures do not take down the workflow. But the failure semantics of a 1,000-agent run are fundamentally different from a single-agent session — you need monitoring, kill switches, and isolation between agent workspaces.

This is why git worktrees became the enabling infrastructure for parallel agent coding. Each agent works in its own worktree, so one agent's bad merge does not contaminate another's working directory.

The OSS Orchestration Saturation Wave

Anthropic is not building in a vacuum. The open-source layer is converging on the same problems:

LangGraph leads with a graph-based state-machine approach, durable execution via PostgresSaver, and time-travel debugging. It is verbose — a simple two-agent flow still requires a state schema, nodes, edges, and compilation — but it has the largest verified enterprise deployment list.

CrewAI optimizes for prototype velocity with role-driven Python agents. MIT-licensed, quick to start, weaker for production durability.

Microsoft Agent Framework (MAF) is the unified successor to AutoGen and Semantic Kernel, reaching GA in April 2026 with native MCP and A2A protocol support. The .NET and Python SDKs are MIT-licensed.

Sakana AI is pushing multi-agent coordination in a different direction entirely. Their MASS (Multi-Agent Self-Supervision) framework uses collective intelligence for recursive self-improvement — agents coordinating not just to complete tasks, but to improve themselves.

View original post on X →

The companion blog post dives into the technical details of how collective intelligence enables recursive self-improvement — a coordination pattern that goes beyond task completion into capability expansion.

View original post on X →

And at the practitioner level, the pattern is everywhere. YouTube creators are building multi-agent advisory boards as personal productivity tools. AI Engineer conference talks are wall-to-wall production orchestration stories — from Flywire running agents in regulated finance to Rexmore's three-level review architecture.

GitHub Trending tells the same story from the supply side. Today's trending page features reverse-engineering agents (morluto/rea at 199K stars), autonomous pentesting agents (pentagi at 28K), context-window optimizers for agents (context-mode at 28K), and video renderers for agent output (hyperframes at 62K). The pattern the convergence report identified — "every other repo is an agent, a tool for agents, or infra agents consume" — is visible in the raw data.

💡 The GitHub signal: Agent-adjacent infrastructure repos now routinely hit 50K-200K stars within weeks. The supply of orchestration tooling is growing faster than the demand for it. Most teams building with agents today will not need to build their own orchestration layer — they will pick from five competing frameworks. The question is which five problems (fan-out, state, verification, cost, degradation) the framework handles well.

The Pattern Goes Mainstream

The clearest signal that orchestration has moved from research to infrastructure is what is happening on YouTube. This week alone, Nate Herk published a walkthrough of building an "AI Board of Advisors" — multiple Claude agents with different expertise areas coordinating to analyze decisions. It is not a research prototype. It is a Claude skill that anyone can install.

Databricks launched Agent Bricks — an agent developer platform that treats orchestration as a first-class platform concern, not a library import. The framing has shifted from "how do I build an agent" to "how do I build a platform that manages agents."

The trajectory is clear: orchestration is commoditizing. Within a year, running a multi-agent workflow will feel as routine as running a CI pipeline. The competitive differentiation will not be in the orchestration framework itself — it will be in how well you define the task decomposition, the verification criteria, and the cost controls for your specific domain.

What This Means for You

If you are building agent systems in Q4 2026, here are the concrete implications:

Evaluate orchestration frameworks against the five problems, not benchmarks. Every framework will show you a demo that works. Ask instead: how does it handle fan-out for tasks with sequential dependencies? What happens when agent 47 of 100 fails? Can you set per-agent token budgets? Can you inspect what each agent did and why?

Start with native orchestration before reaching for a framework. If you are already on Claude, dynamic workflows (ultracode or the managed agents API) handle the common patterns — fan-out/synthesize, adversarial verification, tournament — without adding a dependency. You only need LangGraph or CrewAI when you need cross-model orchestration, durable multi-session workflows, or custom state machines.

The cost conversation is real. A 1,000-agent workflow that each consumes 10K tokens costs you 10M tokens. At current API pricing, that is a meaningful bill for a single task execution. The Opus-plans-haiku-executes pattern — smart orchestrator, cheap workers — is not optional at scale.

Verification is the feature, not parallelism. The reason dynamic workflows found 66/70 bugs while a single agent found 14-27 is not just that more agents looked at more code. It is that adversarial agents verified findings, and only surviving results made the cut. If your orchestration layer just fans out without verifying, you are paying for parallelism without getting reliability.

The harness still matters more than the model. Orchestration is the harness at scale. SWE-bench Pro showed rank correlations of -0.05 across different harnesses — meaning the same model can rank first or last depending on how it is orchestrated. The orchestration layer is not a nice-to-have on top of a good model. It is what makes the model good.

The single-agent era lasted about a year. The fleet management era started in June. The orchestration-as-infrastructure era started this month. The frontier moved, and it moved to coordination.

Originally published at AgentConn

OpenAI and Anthropic call for new laws on artificial intelligence

Hacks.gr — Tue, 13 Oct 2026 23:50:33 +0000

OpenAI and Anthropic representatives told a UK parliamentary committee that voluntary pledges are insufficient and called for binding AI laws, statutory frameworks, and mandatory incident reporting.

The hearing highlighted divisions among major tech firms regarding self-regulation and government oversight.

The British parliament's Business, Innovation, Science and Trade Committee held a hearing, in which executives from four major artificial intelligence companies, former employees and British civil servants gave evidence. The aim of the proceedings, according to the committee's chairman, Liam Byrne, was to expose the disagreements between the industry's wealthy companies and show that self-regulation is not reliable.

What are Anthropic and OpenAI asking for?

Anthropic's head of Europe, Liam Booth-Smith, told the committee that the rules should be made binding. For his part, OpenAI's vice president Tom Duff Gordon said he supported a legal framework, an international treaty and mandatory reporting of problems and incidents.

In contrast, Owen Larter from Google DeepMind and Rob Sherman from Meta avoided supporting the creation of a new legal framework.

The weaknesses of state control

During the meeting, government officials confirmed that the current control system relies solely on voluntary compliance. Henry de Zoete, head of the UK-based Artificial Intelligence Security Institute, admitted that his organization is entirely dependent on cooperation from companies and foreign governments and has no legal authority to stop the release of a dangerous model.

At the same time, the director of Britain's MI5 intelligence agency, Ken McCallum, warned that artificial intelligence could change the game when it comes to creating new or existing biological weapons. Former OpenAI employees also testified at the hearing, arguing that companies cannot be left to control their own security.

Read the original English article on Hacks.gr

Anthropic warns that small AI systems may be spreading themselves across smart devices

Hacks.gr — Tue, 13 Oct 2026 23:42:29 +0000

Anthropic warns that small AI models may soon be capable of self-replicating on IoT devices, potentially forming autonomous worm botnets without a central shutdown point.

Testing across open-weights models explores propagation risks on connected hardware.

According to the company, such programs could form autonomous networks that spread from device to device without a central point to easily shut them down. Previous work has shown systems scanning networks, exploiting security vulnerabilities and copying their files to data centers.

Such a program could carry its files with it or re-download them from a public platform, so that it can run directly on compromised hardware. Malicious actors could build decentralized networks of poorly protected smart devices. These programs spread by compromising the computers they run on. Creating hidden installations in large data centers is considered a more advanced category, while other methods rely on stealing digital connection keys from artificial intelligence services to run copies of themselves.

Anthropic tested 11 open-source models from companies including Alibaba, DeepSeek, Google, Meta, MoonShot AI, OpenAI, and Zhipu AI. It found that one particular model, GLM-5.2, was the only one that was able to reliably transmit another program to test nodes running an Android emulator in four out of five tests.

A network of cheap Android TV devices could form a slow, decentralized system that works together to run computational tasks. The company says it doesn't yet have a fully functional program of this kind, but systems are becoming increasingly capable of completing individual steps in the deployment process.

Read the original English article on Hacks.gr

Anthropic Warning: Smaller AI systems may self-replicate in household devices

Hacks.gr — Tue, 13 Oct 2026 19:37:24 +0000

Anthropic warns that AI models under 30B parameters could gain self-replication capabilities across connected devices within months.

Company tests show malicious agents can combine consumer device compute to execute models, raising important questions about autonomous agent safety.

Last month, the company's CEO, Dario Amondei, estimated that artificial intelligence could take control of the entire internet within the next year through an always-on network of devices. Anthropic's new analysis explains how that scenario could happen, based on data from lab tests.

Traditional botnets are typically made up of unprotected IoT devices, such as smart home devices, security cameras, and set-top boxes, which hackers exploit to send spam or generate fictitious web traffic. Anthropic's experiments showed that a malicious AI agent could combine the computing power of such inexpensive devices to run other models.

The findings show that AI models with 30 billion parameters or fewer are already capable of performing many of the individual actions required to self-replicate, although they still struggle to complete the entire process. However, in simplified tests where certain safety measures were removed, the GLM-5.2 model and more powerful systems were able to successfully complete the process from start to finish.

If the development of smaller models continues at the current historical pace, the ability for this autonomous replication could become a reality by the end of 2026. The company notes that such a network on power-constrained devices could take days to complete some stages, but would continue to expand as long as compromised devices infected enough additional units, making it difficult to neutralize due to the lack of a central point of deactivation.

Although Anthropic warned that future versions may attempt to leverage more powerful computing resources in data centers, it clarified that its current experiments have not demonstrated the possibility of autonomous self-replication in commercial infrastructures of this type.

Read the original English article on Hacks.gr

OpenAI revenue near $50B, $20B below earlier reports

techaiwire — Tue, 13 Oct 2026 18:09:41 +0000

OpenAI told investors its annualized revenue was approaching $50 billion at the end of September 2026, the Financial Times reported on October 8. That is about $20 billion below the figure of nearly $70 billion reported in late September. The gap hit AI stocks the same day and reopened a question for every company buying AI: how big is the market leader's business, really?

Two numbers, two ways of counting

Annualized revenue, or run rate, takes one recent month of sales and multiplies it by 12. It is a snapshot of pace, not a year's actual income.

TechCrunch reports that Axios first put the run rate near $70 billion on September 29. Other outlets cited $68 billion. According to the FT, that larger number came from OpenAI's own investors. They built it to compare OpenAI directly with Anthropic.

The difference comes down to accounting:

	How it counts sales through cloud partners	Figure cited
Anthropic	Counts the full sale, including Claude sold by Amazon, Microsoft and Google	More than $65 billion annualized at end of July
OpenAI, as reported to investors	Counts only its own share	Approaching $50 billion at end of September
OpenAI, investor estimate	Adjusted to match Anthropic's method	About $68 billion to $70 billion

SiliconANGLE says a source described the $50 billion as net revenue. The higher figure included gross revenue from partners.

Who said what

The reports do not fully agree on where the $70 billion came from. The Next Web collected the competing accounts:

The FT said it came from OpenAI's own investors comparing the company with Anthropic.
The Information said earlier reports came from one unnamed investor's estimate.
Reuters said OpenAI pointed to the figure at a separate investor event.
Bloomberg reported on October 9 that $70 billion is OpenAI's run-rate target for the end of 2026. OpenAI declined to comment to Bloomberg.

OpenAI's growth figures also come in two versions. A source told CNBC that the overall run rate grew 77% in the third quarter, and the enterprise business 107%. The Information reported that finance chief Sarah Friar put growth from end-June to end-September at 70%.

The market reaction

The FT report came out on October 8. SiliconANGLE says the Nasdaq fell 1.25%, its worst day since mid-August, and the S&P 500 lost 0.5%.

Company	Move on October 8
CoreWeave	-8%
Oracle	-5.5%
Intel	-5.3%
Super Micro Computer	almost -5%
AMD	-4%
Broadcom	-4%
Nvidia	-2.9%

Most of these companies sell the chips, servers and cloud capacity that AI runs on. SiliconANGLE ties the drop to the lower OpenAI figure and to doubts that AI demand justifies their valuations.

The fundraising backdrop

The timing is awkward for OpenAI. The Next Web, citing Bloomberg, reports it is seeking $30 billion or more at a $1.4 trillion valuation before the new money. TechCrunch notes that OpenAI raised $122 billion in March. Its 2025 revenue was about $13 billion, according to leaked financials.

OpenAI has also delayed its stock market listing. SiliconANGLE says it filed confidentially in June and is now eyeing a 2027 debut. Anthropic is expected to list as soon as November, The Next Web reports, citing Bloomberg. That puts the two companies' numbers side by side in public filings soon.

Holger Mueller of Constellation Research told SiliconANGLE that OpenAI now has "no room for error."

What this means for developers

Most teams do not buy OpenAI stock, but many depend on its API and on its partners' prices.

Read run-rate claims with care. A run rate is one month times 12, and companies count partner sales differently. Compare vendors on what they charge you, not on headline revenue.
Expect pricing pressure, in both directions. A company raising $30 billion has reason to push higher-margin plans. Its rivals have reason to cut prices to win your workload. Recheck your rates each quarter.
Keep a second provider ready. Revenue doubts touch the whole supply chain, from Oracle to CoreWeave. Code that can switch models with a configuration change is cheap insurance.
Watch the filings. Anthropic's listing, and later OpenAI's, will publish audited numbers. Those will settle the counting argument better than any leak.

Earlier reporting on OpenAI's ChatGPT ads reaching a $1 billion run rate used the same pace-based measure.

This article was first published on Tech AI Wire.

Also available in

Deutsch · 日本語 · Français · Español · Português

Related on Tech AI Wire

OpenAI says ChatGPT ads hit a $1B run rate in under 200 days

Sources

OpenAI's revenue is reportedly $20 billion less than previously projected - TechCrunch
AI stocks crumble on report that OpenAI's annualized revenue is much lower than believed - SiliconANGLE
OpenAI expects a $70bn revenue run rate by year-end, Bloomberg reports - The Next Web

app mobil

alexis tejedor — Tue, 13 Oct 2026 15:47:52 +0000

I’d love to be able to use Claude Code directly from my phone, integrated into the official app. I’m a solo developer and I’m often away from my computer, but I still want to keep making progress on my project. Right now the only way to use Claude Code from a phone is by connecting through SSH to a server, which is complicated and not very practical. It would be amazing to have Claude Code inside the app, with voice dictation, to code from anywhere. This would be a huge help for those of us who work alone and need to move around without a laptop.

Claude AI for Business: Integrating Anthropic's API into Real Workflows

André Dias Moreira Prol — Tue, 13 Oct 2026 13:01:36 +0000

In the last two decades working across Web3, tokenization, and AI, I have rarely seen a technology shift adoption curves as sharply as large language models have. When I first integrated Anthropic's Claude into a production pipeline, the result was not a chatbot gimmick, it was a measurable reduction in operational cost and a new layer of intelligence embedded directly into business logic. My name is André Dias Moreira Prol, and in this article I want to share a practical, engineering-first view of how to bring Claude into real products.

Why Claude, and Where It Fits

Claude is not just another API endpoint. Its large context window (up to 200K tokens on recent models) and strong reasoning capabilities make it ideal for workflows involving long documents, compliance analysis, and structured extraction. In one tokenization project, I fed Claude entire legal prospectuses to extract covenant clauses, something that previously required paralegal review hours.

The integration itself is straightforward. A basic call in Python looks like this:

import anthropic

client = anthropic.Anthropic(api_key="YOUR_KEY")

response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    system="You are a financial compliance analyst.",
    messages=[
        {"role": "user", "content": "Summarize the risk clauses in this contract: ..."}
    ]
)
print(response.content[0].text)

The key architectural decision is the system prompt. Treat it as configuration, not conversation. In my teams, we version system prompts in Git alongside code, because a prompt change can shift output quality as much as a code refactor.

Building Reliable Workflows with Tool Use

The real business value emerges when Claude stops being a text generator and starts acting as an orchestrator. Anthropic's tool use (function calling) lets the model decide when to query a database, call an internal API, or trigger a Soroban smart contract on Stellar.

A pattern I deploy frequently is the "retrieve-reason-act" loop:

Retrieve relevant context from a vector store or SQL database.
Reason with Claude using that grounded context to avoid hallucination.
Act by letting Claude call defined tools, with every action logged for audit.

tools = [{
    "name": "get_wallet_balance",
    "description": "Fetch token balance for a Stellar address",
    "input_schema": {
        "type": "object",
        "properties": {"address": {"type": "string"}},
        "required": ["address"]
    }
}]

In a digital forensics engagement, I used this same structure to let Claude triage thousands of transaction logs, flagging anomalies and calling a tool to enrich suspicious addresses with on-chain data. What took analysts days was reduced to under an hour, with a full audit trail. For regulated industries, that traceability is non-negotiable, and it is one reason André Dias Moreira Prol consistently recommends tool-based architectures over free-form prompting.

Cost, Latency, and Production Discipline

Enthusiasm fades quickly when the first cloud bill arrives. Discipline matters. Three practices have saved my clients real money:

Model tiering. Use Haiku for high-volume classification and routing, reserve Sonnet or Opus for complex reasoning. A 10x cost difference between tiers is common.
Prompt caching. Anthropic's caching lets you reuse large static context (like a knowledge base) across calls, cutting token costs by up to 90% for repeated prefixes.
Streaming and timeouts. For user-facing products, stream responses to reduce perceived latency, and set strict timeouts to prevent runaway requests.

Concretely, one client processing 50,000 support tickets monthly moved routing to Haiku and complex resolutions to Sonnet, dropping their monthly AI spend by roughly 60% while improving resolution accuracy. These are not theoretical gains, they are the difference between a pilot that dies and a product that scales.

Also, never skip evaluation. Build a test set of real inputs with expected outputs, and run it on every prompt or model change. Treat Claude outputs like any other dependency: monitored, tested, and observable.

Conclusion

Claude rewards teams that approach it as serious engineering infrastructure rather than magic, grounding it with real data, wrapping it in tools, and measuring everything. If you are building a product and want a pragmatic second opinion, reach out, and let us architect an integration that actually survives production.

Follow more articles by André Dias Moreira Prol on Medium.

API da Anthropic: Como Integrar o Claude AI em Produtos Reais

André Dias Moreira Prol — Tue, 13 Oct 2026 13:01:05 +0000

Quando conversei pela primeira vez com um CFO que insistia que "IA generativa é só hype", pedi dez minutos. Conectei o Claude a uma planilha de contratos atrasados, extraí cláusulas de multa e gerei um resumo executivo em segundos. O ceticismo virou orçamento aprovado. Ao longo de duas décadas liderando projetos de tecnologia, aprendi que a diferença entre empresas que prosperam com IA e as que apenas assistem está na integração inteligente — não no entusiasmo. A API da Anthropic é hoje uma das ferramentas mais subestimadas do mercado corporativo brasileiro, e quero mostrar por quê.

Por que o Claude faz sentido para o contexto corporativo

O Claude não é apenas mais um chatbot. Seu diferencial técnico está na janela de contexto estendida — modelos como o Claude 3.5 Sonnet processam até 200 mil tokens, o equivalente a aproximadamente 500 páginas de documentos em uma única requisição. Para o mercado jurídico e financeiro brasileiro, onde contratos de 80 páginas e processos regulatórios são rotina, isso muda o jogo.

Em projetos que acompanhei, a precisão em tarefas de extração estruturada (classificação de documentos, análise de compliance com a LGPD) ficou consistentemente acima de 90%, com uma taxa de "alucinação" significativamente menor que concorrentes diretos. Como costumo dizer, André Dias Moreira Prol, a escolha do modelo deve seguir o caso de uso, não o marketing. O Claude brilha em raciocínio longo, auditoria documental e tarefas que exigem fidelidade ao contexto fornecido.

A API também oferece recursos sérios para ambiente corporativo: tool use (chamada de funções), prompt caching para reduzir custos em até 90% em prompts repetitivos, e o suporte a streaming, essencial para experiências de usuário fluidas.

Integração prática: do código ao fluxo de trabalho

A integração começa simples. Uma requisição básica em Python exige poucas linhas:

import anthropic

client = anthropic.Anthropic(api_key="sua_chave")

mensagem = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Resuma este contrato: ..."}
    ]
)
print(mensagem.content)

O desafio real não é o código — é a arquitetura. Em ambientes corporativos, recomendo sempre:

Camada de orquestração: use RAG (Retrieval-Augmented Generation) com bases vetoriais para alimentar o Claude com dados internos, evitando que informações sensíveis trafeguem sem controle.
Governança de prompts: versione prompts como código, com testes automatizados de regressão.
Observabilidade: monitore custo por token, latência e taxa de rejeição. Em um projeto de atendimento no varejo brasileiro, essa disciplina reduziu o custo mensal de API em 37% apenas com caching e ajuste de modelos por tarefa.

Um caso concreto: integrei o Claude ao fluxo de uma fintech para pré-análise de documentos de crédito. O que levava 15 minutos por analista passou a 40 segundos, com validação humana apenas nos casos de baixa confiança — o chamado human-in-the-loop.

Segurança, perícia e responsabilidade

Aqui entra minha atuação em perícia digital. IA corporativa sem rastreabilidade é um passivo jurídico. Toda interação com a API precisa de logs imutáveis — idealmente ancorados em blockchain, como a rede Stellar, para garantir integridade probatória. Em disputas trabalhistas ou regulatórias, provar o que o modelo gerou e quando se torna decisivo.

A Anthropic adota política de não treinar seus modelos com dados de clientes da API por padrão, um ponto relevante para adequação à LGPD. Ainda assim, oriento meus clientes a classificar dados antes de qualquer envio e a manter informações de titulares sob anonimização sempre que possível.

Como André Dias Moreira Prol sempre reforça em consultorias: adotar IA sem camada de auditoria é construir sobre areia. A tecnologia é poderosa, mas a responsabilidade permanece humana e corporativa.

Conclusão

Integrar o Claude não é um projeto de TI isolado — é uma decisão estratégica que exige arquitetura, governança e visão de risco. Se sua empresa está pronta para transformar hype em resultado mensurável, comece com um piloto bem delimitado e me procure para desenhar essa jornada com segurança e método.

Acompanhe mais artigos de André Dias Moreira Prol no Medium.

Claude Haiku 5.5: The $0.10 Model That Makes Meta's $4 Look Expensive

Paul Lovelace — Tue, 13 Oct 2026 07:14:26 +0000

Meta just charged $4 per million tokens for Muse Wonder. Five days earlier, Anthropic launched Claude Haiku 5.5 at $0.10 per million.

Same week. 40x price difference. Here's what Haiku 5.5 actually gives you — and where the cheap price hides real trade-offs.

What launched (Oct 7, 2026)

Claude Haiku 5.5 — Anthropic's smallest, fastest, cheapest model. Third release in the Claude 5.5 family, ahead of their planned IPO.

The headline numbers:

$0.10 / $0.50 per million input/output tokens (prompts under 100K tokens)
$0.50 / $2.50 for longer prompts — watch this, it matters
1M token context window (up from 200K on Haiku 4.5)
128K max output (up from 64K)
Model ID: claude-haiku-5-5

Anthropic says it's 75% cheaper than Haiku 4.5 and calls it the fastest, most efficient member of the family.

What's actually new (not just cheaper)

Adaptive thinking. Haiku 5.5 decides how much reasoning a task needs — on by default. First Haiku with adjustable effort controls, so you can trade intelligence against cost and latency yourself.

1M context. This is the big one for a "small" model. A million tokens of context at $0.10/1M means you can stuff entire codebases, long documents, or massive conversation histories into the cheap tier.

Built for volume. Anthropic is pitching it as the workhorse: classification, summarization, extraction, live support, voice agents, in-app assistants — plus a fast subagent model for its bigger Opus and Sonnet siblings.

The pricing trap nobody mentions

Read the rate card twice:

Under 100K tokens: $0.10 / $0.50
Over 100K tokens: $0.50 / $2.50 — that's 5x on input

So the "$0.10 model" is only $0.10 if you stay under 100K tokens per prompt. The moment you actually use that 1M context window — the headline feature — you're paying 5x more per input token. The cheap price and the big context are in tension by design.

This isn't dishonest, it's just how tiered pricing works. But every "Haiku 5.5 costs $0.10" headline you've seen is missing the asterisk.

Where it fits (and where it doesn't)

Use it for:

High-volume classification, extraction, summarization
Subagent calls inside bigger workflows (cheap reasoning steps)
Voice agents and live support where latency matters
Anything where you'd currently use Haiku 4.5 — it's strictly better and 75% cheaper

Don't use it for:

Frontier reasoning — that's Opus 5.5's job at 40x the price
Long-context work without doing the math — over 100K tokens, compare against Sonnet 5.5's halved cache-read pricing (Anthropic cut those the same day, making agentic work ~20% cheaper)
Anything needing the strongest safeguards — note Haiku 5.5 ships with built-in blocks on a narrow set of high-risk cybersecurity requests

The real story: the market is splitting in two

Muse Wonder at $4/$20 and Haiku 5.5 at $0.10/$0.50 launched five days apart. That's not a coincidence — it's the market bifurcating:

Premium tier ($4+/1M): frontier reasoning, memory, marathon coding — Wonder, Opus 5.5
Volume tier ($0.10/1M): fast, cheap, good-enough — Haiku 5.5

The smart architecture isn't picking one. It's routing: Haiku 5.5 for the 90% of calls that don't need frontier intelligence, Opus/Wonder for the 10% that do. Anthropic basically told you this by pitching Haiku as a subagent model.

TL;DR

Claude Haiku 5.5: $0.10/$0.50 per 1M (under 100K tokens), 1M context, adaptive thinking
The $0.10 price jumps 5x past 100K tokens — do the math before stuffing context
75% cheaper than Haiku 4.5, available on API, Bedrock, Google Cloud, Copilot
Real play: route volume work to Haiku, frontier work to Opus/Wonder

Sources: Anthropic announcement (Oct 7, 2026), Reuters, Claude Platform docs. Pricing from Anthropic's published rate card.