DEV Community: galian

Claude Sonnet 5 Just Made Running Agents Cheap — What Builders Actually Need to Know

galian — Tue, 30 Jun 2026 22:06:37 +0000

Anthropic shipped Claude Sonnet 5 on June 30, 2026, and the framing in the announcement is unusually blunt for a model launch: it's pitched as the most agentic Sonnet yet — a model built to make plans, drive tools like browsers and terminals, and run autonomously at a level that, a few months ago, took something bigger and more expensive.

For anyone building on top of these models — agents, pipelines, coding tools — that's the headline that matters. Not "it's smarter," but "near-frontier capability just got cheaper to run in a loop." I write and teach about agentic engineering at Cursuri-AI.ro, Eastern Europe's AI education platform, so I'll keep this grounded in what changes for people who actually ship on these APIs — not the launch-day benchmark theater.

One disclaimer up front: model pricing and availability in this space change almost monthly, and this is a day-one snapshot. Verify the current numbers on Anthropic's official pages before you wire anything to a budget. I'm deliberately not quoting benchmark scores here — the launch materials presented them in a way that's easy to misread, so for hard numbers go straight to the Sonnet 5 System Card.

The one-sentence version

Sonnet 5 moves "good enough to run agents autonomously" down a price tier — and ships a new tokenizer that can quietly inflate your token counts by up to 35%.

Both halves of that sentence matter, and the second one is the part nobody puts on a launch slide. Let's take them in order.

What's actually new

Stripping the marketing down to verifiable claims from Anthropic's own announcement, here's what Sonnet 5 is:

The most agentic Sonnet so far. It's described as able to "make plans, use tools like browsers and terminals, and run autonomously," with improvements specifically in multi-step tool use — the exact workload that defines an agent rather than a chatbot.
Close to Opus 4.8 — at a lower price. Anthropic's own phrasing is that its "performance is close to that of Opus 4.8, but at lower prices." That's the whole pitch: most of the capability, a fraction of the cost.
A real step up from Sonnet 4.6. Called a "substantial improvement over its predecessor, Sonnet 4.6, on important aspects of agentic performance like reasoning, tool use, coding, and knowledge work."
Safer in agentic contexts. Anthropic reports an "overall lower rate of undesirable behaviors than Sonnet 4.6," plus lower rates of hallucination and sycophancy — which matters more than it sounds when a model is acting in a loop without a human reading every step.
Deliberately weaker at offensive cyber. It shows "substantially poorer performance than models such as Opus 4.8" on dangerous cyber tasks and was "never able to develop a full working exploit." That's a safety design choice, not an oversight — worth knowing if security tooling is your domain.

Two things Anthropic did not publish that I'm not going to invent for you: an official context window and max output token figure for Sonnet 5 weren't stated in the launch materials at the time of writing. If you need those for capacity planning, pull them from the official API docs rather than trusting a blog (including this one). Guessing is how teams ship broken truncation logic.

The economics shift is the real story

Here's why builders should care more than end users.

When you chat with a model, price-per-token is almost noise — you send a few thousand tokens and read the answer. When you run an agent, the model is in a loop: read context, call a tool, read the result, reason, call another tool, repeat. A single "task" can burn hundreds of thousands of tokens across dozens of turns. At that volume, the price-per-million-tokens line is your unit economics.

So a model that lands near Opus-4.8 quality at Sonnet pricing doesn't just make chat cheaper — it changes which agent designs are economically viable at all. Workflows you'd previously gate behind Opus (multi-step research, autonomous refactors, long tool-using runs) become defensible on a Sonnet budget. That's the unlock.

Here's the day-one pricing picture, with the rest of the current Anthropic lineup for context:

Model	Input / 1M tokens	Output / 1M tokens	Notes
Sonnet 5 (intro, through Aug 31 2026)	$2	$10	Promotional launch pricing
Sonnet 5 (standard, from Sep 1 2026)	$3	$15	Same as Sonnet 4.6's tier
Opus 4.8	$5	$25	Top accuracy; default in Claude Code
Haiku 4.5	$1	$5	Cheapest / fastest tier

A few honest notes:

The introductory $2 / $10 runs through August 31, 2026, then settles to $3 / $15 — the same standard tier Sonnet has occupied. So the long-run story isn't "Sonnet got cheaper"; it's "the Sonnet tier got dramatically more capable for the same price."
Sonnet 5 is the default model on Free and Pro plans, and is available to Max, Team, and Enterprise users — in Claude Code, the Claude platform, and the API. So if you're on Claude Code, you may already be one model-switch away from it.
Against Opus 4.8 the price ratio is roughly 1.7× (output $25 vs $15). When you're running agents at scale, that multiple compounds fast — which is exactly why the "close to Opus" claim is worth pressure-testing on your workload, not taking on faith.

The tokenizer gotcha that will mess up your cost math

This is the part I most want builders to internalize, because it's the easiest way to get a nasty surprise on your next invoice.

Sonnet 5 ships with an updated tokenizer. Anthropic states that the same input text now maps to roughly 1.0–1.35× as many tokens as before, depending on content type. Read that again: identical prompts can cost up to 35% more tokens on Sonnet 5 than the token count you measured on an older model — before any change in per-token price.

Why it bites:

Your cost dashboards, budget alerts, and per-request estimates were calibrated on the old tokenizer. Swap the model without re-measuring and your "same" workload silently costs more.
Code, structured data (JSON/XML), and non-English text tend to sit at the higher end of that multiplier — and those are precisely the inputs agentic and coding workloads are made of.
It interacts with context windows and truncation: more tokens for the same text means you hit limits sooner than your old math predicts.

The fix is boring and non-negotiable: re-baseline. Before you flip production traffic to Sonnet 5, measure real token counts on a representative sample of your prompts with the new tokenizer, recompute cost per task, and update your budgets and alerts. The headline price drop is real — but the effective saving is (price delta) × (token inflation), and you can't know the second factor without measuring. Anyone who tells you "it's 33% cheaper" did half the arithmetic.

This is also where good evals earn their keep. A model swap isn't just a cost change; it's a behavior change. Run your task suite on Sonnet 5 against the model you're replacing before you commit — quality, tool-call success rate, and cost together. If you don't have an eval harness yet, this is the launch that should convince you to build one; it's a discipline we treat as core, not optional, in our course on building LLM evals for production.

When to still reach for Opus 4.8

"Close to Opus" is not "Opus." The honest read on where Sonnet 5 fits:

Reach for Sonnet 5 as your default agent workhorse: high-volume tool-using loops, coding assistance, research and summarization, anything where you're paying per turn and the marginal quality of Opus isn't worth ~1.7× the output cost.
Stay on Opus 4.8 for the hardest reasoning, the highest-stakes accuracy, and security-sensitive work where Sonnet 5 is intentionally weaker (offensive-cyber tasks). When a wrong answer is expensive, the price gap is cheap insurance.

The pattern most production teams land on isn't "pick one." It's a router: Sonnet 5 handles the bulk of turns, and you escalate to Opus 4.8 for the steps that genuinely need it — with a human in the loop on the consequential ones. Getting that routing logic right (and knowing which task belongs in which tier) is a real engineering skill, and it's the through-line of our model-comparison course, which treats "which model for which job" as a decision you make with data rather than vibes.

A pragmatic migration checklist

If you're considering moving an agent or pipeline to Sonnet 5, here's the order I'd do it in:

Re-baseline tokens. Run a representative sample through the new tokenizer. Recompute cost per task. Update budget alerts.
Run your evals. Quality, tool-call success, latency, and cost, head-to-head against the model you're replacing. No eval suite? Build a small one first — even 30 representative tasks beats a gut call.
Shadow, then canary. Route a slice of real traffic to Sonnet 5, compare outputs, then scale gradually. Don't flip 100% on day one.
Keep an escalation path. Wire Opus 4.8 as the fallback for tasks that fail Sonnet 5's quality bar. Routing beats an all-or-nothing bet.
Re-read your safety posture. Lower hallucination and sycophancy is good news for autonomous runs, but "safer" isn't "supervise nothing." Keep guardrails and human checkpoints where consequences are real.

None of this is exotic. It's the same discipline that separates teams who run agents in production from teams who demo them — and it's exactly the muscle we build in our hands-on track on AI agents and automation, taught around real repositories rather than toy notebooks.

Frequently asked questions

Is Claude Sonnet 5 better than Opus 4.8?

Not across the board. Anthropic positions Sonnet 5's performance as close to Opus 4.8 at a lower price — so for high-volume agentic and coding work it's often the better value, but Opus 4.8 still leads on the hardest reasoning, top-end accuracy, and (deliberately) on offensive-cyber capability. Match the tier to the task instead of picking a favorite.

How much does Claude Sonnet 5 cost?

It launched with introductory pricing of $2 per million input tokens and $10 per million output tokens through August 31, 2026, then moves to a standard $3 / $15 — the same tier Sonnet 4.6 occupied. Your effective cost also depends on the new tokenizer (see below), so measure before you budget.

Does the new tokenizer really change my costs?

Yes. Anthropic states the same input can map to roughly 1.0–1.35× as many tokens under Sonnet 5's updated tokenizer, depending on content type — code and structured data sit at the higher end. Re-measure your real prompts before assuming the headline price drop equals your actual saving.

Can I use Sonnet 5 in Claude Code?

Yes. It's available in Claude Code, the Claude platform, and the API, and it's the default model on Free and Pro plans (and available to Max, Team, and Enterprise). If you're already in Claude Code, switching is a model selection, not a migration.

Should I migrate my agents to Sonnet 5 immediately?

Don't flip production on day one. Re-baseline token counts, run your eval suite head-to-head against your current model, then canary a slice of traffic before scaling — and keep an escalation path to Opus 4.8 for tasks that need it.

The skill underneath the model

Here's the part the launch posts skip: a cheaper, more agentic model doesn't make anyone a better builder. It just makes the consequences of your design bigger — cheaper to be right at scale, and cheaper to be confidently wrong at scale. Point Sonnet 5's autonomy at a vague spec and you get a fast, plausible wall of actions you didn't design and can't fully audit.

The developers getting real leverage from this launch aren't the ones who memorized the new price-per-token. They're the ones who understand agent architecture, context engineering, evals, and cost modeling well enough to know when the cheap-and-autonomous option is the right call and when it's a trap. That foundation — taught around real repositories with an interactive AI instructor, not slide decks — is what we build at our Eastern European AI education platform, including a dedicated, hands-on track on agentic coding with Claude Code.

Conclusion

Claude Sonnet 5 is a genuinely significant release for builders, but not for the reason most coverage leads with. The story isn't a benchmark number — it's that near-frontier agentic capability just moved down a price tier, which changes which agent designs are economically worth shipping. The catch is the new tokenizer: the real saving is the price drop minus token inflation, and you only learn the second number by measuring.

So don't migrate on the headline. Re-baseline your tokens, run your evals, canary your traffic, and keep Opus 4.8 one route away for the work that needs it. Do that, and Sonnet 5 is one of the better deals in the 2026 model lineup. Skip it, and you'll find out the hard way — on your invoice.

Written by the team at Cursuri-AI.ro — practical, hands-on AI engineering courses for developers and professionals across Eastern Europe, from agentic coding and AI agents to evals, context engineering, and the modern AI-native workflow.

Sources: Introducing Claude Sonnet 5 — Anthropic · Claude Sonnet 5 System Card · Claude Platform — Pricing · Claude Pricing

Cursor vs GitHub Copilot vs Claude Code: Which AI Coding Tool in 2026?

galian — Mon, 29 Jun 2026 14:59:29 +0000

If you write code for a living in 2026, you're not asking whether to use an AI coding tool — you're asking which one. And the three names that dominate every team's Slack debate are Cursor, GitHub Copilot, and Claude Code. They look similar from a distance (type intent, get code) but they're built on three genuinely different bets about how software gets written.

I've spent serious time in all three on real, multi-file, multi-repo work — not toy demos — and this is the comparison I wish someone had handed me before I burned a month figuring it out. I write and teach about agentic engineering at Cursuri-AI.ro, Eastern Europe's AI education platform, so I'll keep this grounded in how these tools actually behave in production, not in launch-day marketing.

A note before we start: pricing and features in this category change almost monthly. Everything below is a mid-2026 snapshot — verify the current numbers on each tool's official page before you budget for a team.

TL;DR — three different philosophies

Here's the one-sentence version of each, before we go deep:

Cursor is an AI-native editor — it rebuilt the IDE around the agent. Best for developers who want fast, fluid, in-the-flow generation with deep editor integration.
GitHub Copilot is the ecosystem play — it lives where your code, issues, and PRs already are. Best for teams standardized on GitHub who want AI woven through the whole SDLC.
Claude Code is the terminal-first agent — it treats the command line as the primary surface and excels at autonomous, multi-step, multi-file work. Best for engineers comfortable orchestrating agents rather than babysitting autocomplete.

None of them is "the best." They optimize for different moments, and the real skill is knowing which to reach for. Let's break down why.

What is Cursor?

Cursor is an AI-native IDE built as a fork of VS Code, so the editor feels instantly familiar — your extensions, keybindings, and themes mostly carry over. What's different is that the AI isn't bolted on as a plugin; the whole editing experience is designed around it.

Its signature features:

Tab completion — a multi-line, context-aware autocomplete that predicts your next edit, not just the next token. It's the feature people miss most when they switch away.
Composer — Cursor's agentic, multi-file editing mode. You describe a change in natural language and it edits across files, runs commands, and iterates. Cursor now ships Composer 2.5, its own model trained specifically for agentic coding, alongside routing to frontier models from Anthropic, OpenAI, and Google.
Cloud Agents — introduced in the Cursor 3.5 release (May 20, 2026), these run in isolated cloud VMs with terminal and browser access, can work across multiple repos in parallel, and report results back to your IDE asynchronously. It's Cursor's answer to "I want the agent working while I do something else."

Cursor's center of gravity is in-the-flow coding: you stay in the editor, you see every diff, and the AI keeps pace with your thinking. It rewards developers who want speed without giving up granular control over the code.

What is GitHub Copilot?

Copilot is the most widely deployed of the three, and its biggest advantage is gravitational: it lives inside the tools and platform most teams already use. It runs in VS Code, JetBrains IDEs, Visual Studio, and on GitHub itself.

By 2026 Copilot has grown well past autocomplete:

Agent mode became generally available across both VS Code and JetBrains in March 2026 (previously VS Code only) — a multi-step agent that plans, edits across files, and runs commands inside your editor.
The autonomous coding agent is the standout. You assign a GitHub issue to Copilot, and it works asynchronously in the background — analyzing the repo, making changes, and opening a ready-to-review pull request. Assign, walk away, come back to a PR. It's the closest any mainstream tool comes to "fire-and-forget" feature work.
Agentic code review gathers full project context before suggesting changes and can hand fixes straight to the coding agent.
GitHub Spark lets you describe an app in plain English and get generated code with a live preview.

The strategic point: Copilot's value isn't any single feature — it's that AI is now threaded through the entire GitHub-centric SDLC, from issue to PR to review. If your team lives on GitHub, that integration is hard to beat.

One billing change worth flagging: as of June 1, 2026, GitHub moved to GitHub AI Credits (token-based billing) in place of the older Premium Request Units. You're now billed by tokens processed at published model rates, which makes heavy agent usage more transparent — and easier to accidentally overspend if you're not watching.

What is Claude Code?

Claude Code, from Anthropic, takes the opposite stance from Cursor: instead of building an editor, it makes the terminal the primary surface (with IDE extensions available on top). That sounds minimalist until you see what it does with full shell access.

Its defining strengths:

Agentic, multi-file, repo-aware work from the command line — it reads your codebase, makes coordinated changes across many files, runs your tests, and handles git operations and CI-aware workflows natively.
Subagents — reusable agent configurations with their own custom prompts and tool access, so you can define a "reviewer," a "test-writer," or a "migration" agent and invoke it on demand.
Agent teams and multi-agent orchestration — coordinate multiple agent sessions working in parallel, with an agent view dashboard to manage them.

Claude Code runs on Anthropic's models — currently Claude Opus 4.8 as the default, with the newer Claude Fable 5 as the most capable tier — and it's deliberately model-opinionated rather than a router. The tradeoff is real: it's the most powerful for autonomous, complex tasks, and the least hand-holdy. It assumes you're comfortable thinking like an orchestrator of agents rather than a writer of lines.

A word of caution that applies to every agent platform but bites hardest here: parallel agents multiply your token spend. Running ten agents at once consumes your quota roughly ten times faster. The autonomy is exhilarating; the bill is real. Set limits before you scale up.

Head-to-head: the dimensions that actually matter

The editing model

Cursor wins on in-editor flow. Tab completion and inline diffs keep you in control of every change.
Copilot wins on breadth of surface — it's good everywhere your code already is.
Claude Code wins on autonomous depth — it goes furthest without supervision, but you give up the inline, line-by-line feel.

Agents and autonomy

All three now have agents, but the philosophy differs. Cursor's Cloud Agents and Copilot's coding agent are both "assign work, get a result later." Claude Code goes further with explicit multi-agent orchestration and reusable subagents. If your work is increasingly delegating rather than typing, this is the dimension to weigh most — and it's exactly the shift that makes understanding AI agent architecture and automation a genuine career edge rather than a nice-to-have.

Ecosystem and integration

This is Copilot's home turf. The issue-to-PR loop, native code review, and presence across every major IDE make it the path of least resistance for GitHub-standardized teams. Cursor integrates deeply but inside its editor; Claude Code integrates deeply with your shell and git, which is either liberating or intimidating depending on your comfort with the command line.

Models

Cursor routes across many frontier models and adds its own Composer model. Copilot offers a model picker. Claude Code is Anthropic-only by design. If model choice matters to you (and for some workloads it genuinely does), Cursor and Copilot give you more knobs; Claude Code bets that a tightly-integrated, top-tier model beats a buffet.

Pricing, side by side (mid-2026 snapshot)

Tool	Entry	Mid tier	Power / team
Cursor	Hobby (free)	Pro — $20/user/mo	Teams — $40/user/mo (Standard), $120/user/mo (Premium)
GitHub Copilot	Free	Pro — $10/mo · Pro+ — $39/mo	Max — $100/mo · Business / Enterprise seats
Claude Code	Pro — $20/mo	Max 5× — $100/mo	Max 20× — $200/mo · API pay-per-token

A few honest caveats on cost:

Copilot has the cheapest entry paid tier ($10), but token-based AI Credits mean heavy agent use can climb fast beyond the included allotment.
Cursor's $20 Pro includes a fixed amount of frontier-model usage; power users hit the ceiling and either upgrade or switch to its cheaper Auto/Composer routing.
Claude Code's Max tiers are priced for sustained, agent-heavy sessions — and again, parallel agents are a multiplier, not an add.

Prices and tiers shift constantly in this category. Treat the table as a snapshot, not a quote, and confirm before committing a team budget.

So which one should you choose?

Here's the honest, persona-based answer:

Choose Cursor if you want the best in-editor experience, you value fast inline generation and tight control over every diff, and you're happy living inside a (very good) VS Code fork. It's the most natural upgrade for a developer who loves their editor and wants AI to keep pace with their flow.

Choose GitHub Copilot if your team is standardized on GitHub and you want AI woven through the entire lifecycle — issues, PRs, reviews — across whatever IDEs your team already uses. The issue-to-PR autonomous agent alone can change how a team ships. It's the safest institutional bet.

Choose Claude Code if you're comfortable in the terminal, your work skews toward complex multi-file refactors and autonomous tasks, and you want to orchestrate agents rather than supervise autocomplete. It has the highest ceiling for autonomy — and asks the most of you in return.

And the answer most senior engineers actually land on? More than one. Plenty of us keep Cursor open for flow-state editing, lean on Copilot inside the GitHub workflow, and fire up Claude Code for the gnarly autonomous jobs. The tools overlap, but they're not redundant — they're a toolkit. The real meta-skill isn't loyalty to one editor; it's fluency across the category so you instinctively reach for the right one per task.

The skill underneath the tools

Here's the uncomfortable truth that the demos hide: these tools amplify the engineer you already are. Point a powerful agent at a vague intent and you get a fast, confident wall of code you didn't design and can't fully maintain. The developers getting outsized leverage from Cursor, Copilot, and Claude Code aren't the ones who learned the keyboard shortcuts — they're the ones who understand agent architecture, context engineering, and how to specify intent precisely enough that autonomy becomes an asset instead of a liability.

That foundation is exactly what we build at our AI education platform for Eastern Europe — practical, project-based courses taught around real repositories with an interactive AI instructor, not slide decks. If you want to go from "I use these tools" to "I get serious leverage from them," we maintain dedicated, hands-on tracks for using Cursor as a pro and for agentic coding with Claude Code — both built around real multi-file, real-repo workflows rather than toy examples.

Conclusion

In 2026, "AI coding tool" isn't one product category — it's three philosophies wearing similar clothes. Cursor bet on the editor, Copilot bet on the ecosystem, and Claude Code bet on the terminal-native agent. Each is genuinely excellent at the thing it optimized for, and genuinely compromised at the things it didn't.

So don't ask "which is best." Ask "best at what, for whom, doing which task" — and then build the judgment to switch fluently between them. That judgment, not the tool, is what compounds over a career. Try each one on a real feature, not a demo, and you'll feel the differences fast.

Written by the team at Cursuri-AI.ro — practical, hands-on AI engineering courses for developers and professionals across Eastern Europe, from agentic coding and AI agents to context engineering and the modern AI-native IDE workflow.

Sources: Cursor Models & Pricing · GitHub Copilot Plans & Pricing · GitHub Copilot Plans (Docs) · Claude Pricing · Claude Platform Docs — Pricing

Kiro: A Practical Guide to AWS's Spec-Driven Agentic IDE"

galian — Fri, 26 Jun 2026 21:45:36 +0000

If you've spent any time with AI coding assistants, you know the failure mode: you write a vague prompt, the agent generates a wall of plausible-looking code, and twenty minutes later you're debugging something you didn't design and don't fully understand. Kiro, the agentic IDE from AWS, is a bet that the fix isn't a smarter autocomplete — it's making a specification the unit of work instead of a prompt.

I've been digging into how Kiro actually works, and this is the practical guide I wish I'd had on day one: what spec-driven development really means, how agent hooks and steering files change your workflow, where Kiro fits next to tools like Cursor and Claude Code, and when it's worth it. I write and teach about agentic engineering at Cursuri-AI.ro, Eastern Europe's AI education platform, so I'll keep this grounded in how these tools behave in real projects rather than in launch-day hype.

What is Kiro?

Kiro is an agentic IDE built on the Code OSS platform — the same open-source foundation behind VS Code — which means the editor itself feels immediately familiar. What's different is the engine. Instead of treating each request as a one-off chat turn, Kiro is designed to turn a high-level prompt into a structured spec, then drive implementation, tests, and documentation from that spec.

The headline idea, in Kiro's own framing, is "moving beyond AI coding to agentic engineering." That sounds like marketing until you see the artifacts it produces. A feature request doesn't become a blob of code — it becomes three reviewable files: requirements, design, and tasks. You stay in the loop at each stage. The agent does the typing; you keep the judgment.

It's worth being precise about what Kiro is not: it isn't an AWS cloud service you provision in a console, and it doesn't lock you into AWS infrastructure to write code. It's a desktop IDE. You can point it at any project.

Spec-driven development: the core idea

Most AI coding tools optimize for speed-to-first-keystroke. Spec-driven development optimizes for correctness-to-intent — does the code match what you actually meant? Kiro does this by formalizing the part of engineering we usually skip when we're moving fast: writing down what we're building before we build it.

When you describe a feature, Kiro generates a spec in three phases:

1. Requirements

Kiro turns your prompt into user stories with explicit acceptance criteria, written in EARS notation (Easy Approach to Requirements Syntax). EARS is a lightweight, real technique for writing testable requirements — patterns like "When [trigger], the system shall [response]". The value is that ambiguity gets surfaced before code exists. If your one-line prompt was underspecified, you'll see it in the requirements draft and can correct it in seconds, not after a debugging session.

2. Design

Next, Kiro produces a technical design: the architecture, the components, the data flow, and the implementation approach. This is the document a senior engineer would normally write (or wish a junior had written) before touching the codebase. You review it, push back, and refine.

3. Tasks

Finally, the design becomes a sequenced task list — discrete, trackable units of work the agent implements in order. Because tasks are explicit, you get accountability: you can see what's done, what's in progress, and what's left, instead of trusting a black box.

The payoff is maintainability. A spec that lives in your repo is documentation that doesn't rot, because it is the thing the agent built from. Six months later, the requirements and design files explain why the code looks the way it does.

Agent hooks: automation that runs itself

The second pillar is agent hooks — automated triggers that fire agent prompts or shell commands when something happens in your IDE. Instead of remembering to run the linter, regenerate tests, or scan for secrets, you wire those actions to events once and forget about them.

Hooks can be triggered by:

File events — a file is created, saved, or deleted
Prompt and agent lifecycle events — prompt submit, agent stop, pre/post tool use
Spec task events — before or after a task executes
Manual triggers — a button you press on demand

Under the hood, hooks are just JSON files. Workspace-level hooks live in .kiro/hooks/, and user-level hooks in ~/.kiro/hooks/. You can create them three ways: describe what you want in plain English and let Kiro generate the JSON, fill out a form, or write the JSON by hand. The practical version of this: every time you save a file, a hook can run your tests and a security scan automatically, so problems surface the moment they're introduced — not in CI an hour later.

Steering files: stop repeating yourself

If you've ever pasted "remember, we use tabs not spaces, we use Vitest not Jest, and never import from the legacy module" into chat for the hundredth time, steering files are the fix. Steering gives Kiro persistent knowledge about your project through markdown files, so your conventions, libraries, and standards are applied consistently without re-explaining them every session.

Steering files can be scoped two ways:

Workspace steering lives in .kiro/steering/ and applies only to that project
Global steering applies across everything you build

This is essentially context engineering applied to a coding agent — encoding the durable knowledge an agent needs so it behaves like a teammate who's read your style guide, not a contractor seeing the repo for the first time. If you want to go deep on the discipline behind this, persistent memory and context strategy for agents is exactly what our context engineering and agent memory course covers end to end.

MCP and agentic chat

Beyond specs, hooks, and steering, Kiro ships the features you'd expect from a modern AI editor. It supports the Model Context Protocol (MCP) for connecting external tools and data sources to the agent, and it includes an agentic chat with context providers for files, URLs, and docs for the ad-hoc work that doesn't justify a full spec.

MCP support matters more than it sounds. It's the open standard that lets an agent reach your database, your ticketing system, your internal docs — without bespoke glue for each one. If MCP is new to you, building and integrating MCP servers is its own skill set; our MCP course walks through standing up real servers and wiring them into agentic workflows.

Your first hour with Kiro

The fastest way to understand the workflow is to feel the loop once on a real, small feature. In practice it looks like this:

Describe the feature in plain language. Not "build an app" — something concrete like "add an endpoint that returns a user's last five orders, paginated."
Review the requirements. Kiro drafts user stories and acceptance criteria. This is where you catch the ambiguity: did you mean five orders total, or five per page? Fix it in the spec, where it costs nothing.
Review the design. Check that the proposed architecture matches your codebase's conventions — and if it doesn't, that's a sign your steering files need to capture those conventions.
Let it work the task list. The agent implements tasks in sequence; you watch and intervene where judgment is needed.
Wire one hook. Even a single "run tests on save" hook changes how the session feels — feedback becomes immediate instead of deferred.

Do that once and the abstract pitch — "specs as the unit of work" — turns concrete. The discipline isn't heavy; it's front-loaded, and the front-loading is where the bugs you didn't ship were quietly avoided.

Kiro vs. vibe coding

"Vibe coding" — prompting your way to an app on feel, accepting whatever the model produces — is genuinely useful for prototypes, throwaway scripts, and learning. It's also where a lot of teams get burned when that "prototype" quietly becomes production.

Kiro is, in a sense, the structured opposite. The spec phase forces the requirements-and-design thinking that vibe coding skips. That doesn't make vibe coding wrong — it makes them tools for different moments. Reaching for a spec to build a one-off script is overkill; vibe-coding a payment flow is asking for trouble. Knowing which mode fits which task is the actual skill, and it's the through-line of our vibe coding course, which treats prompt-to-app speed and structured engineering as complementary, not rival, philosophies.

How Kiro compares to other agentic tools

Kiro isn't alone — the agentic IDE space is crowded, and the tools overlap. A few honest distinctions:

Cursor is an AI-native editor built around fast in-editor generation, multi-file edits, and an agent mode. Its center of gravity is fluid, in-the-flow coding.
Claude Code is a terminal-first agentic tool that excels at multi-file changes, git operations, and CI-aware work from the command line.
Kiro distinguishes itself by making the spec the artifact — front-loading requirements and design before implementation.

These aren't mutually exclusive; plenty of engineers use more than one and switch by task. The meta-skill is fluency across the category rather than loyalty to one editor. If you want a structured path through these tools, we maintain dedicated, hands-on courses on agentic coding with Claude Code and on Cursor as a pro — both built around real multi-file, real-repo workflows rather than toy demos.

Pricing

At the time of writing, Kiro uses a credit-based model measured in agent interactions, with no daily or weekly rate limits and pre-paid overages so you don't hit a hard wall mid-task:

Free — 50 agent interactions per user per month (fine for experimentation, not serious daily work)
Pro — $19 per user per month for 1,000 agent interactions
Pro+ — $39 per user per month for 3,000 interactions

Pricing and tiers for tools in this category change often, so verify the current numbers on Kiro's official pricing page before you budget for a team. Treat the figures above as a snapshot, not a contract.

When Kiro is worth it — and when it isn't

Spec-driven development has a cost: the spec phase is overhead. That overhead pays off when the work is durable and shared, and it's pure friction when the work is disposable.

Kiro shines when:

You're building features meant to live and be maintained, not prototypes you'll throw away
More than one person (or one agent) touches the codebase and conventions matter
You want an auditable trail of why the code is the way it is
You're tired of re-explaining your standards every session

Reach for something lighter when:

You're exploring, prototyping, or scripting something you'll delete tomorrow
The task is small enough that writing the spec costs more than writing the code
You just need a quick answer or a one-file change

The honest take: spec-driven development is a discipline, and Kiro is tooling that makes the discipline cheaper to follow. The tool won't supply the engineering judgment — it removes the excuse not to apply it.

Want to go deeper?

Tools like Kiro lower the cost of doing engineering properly, but they reward people who already understand specs, agent architecture, context management, and the MCP ecosystem underneath. That foundation is what turns an agentic IDE from a faster autocomplete into genuine leverage.

At Cursuri-AI.ro, Eastern Europe's AI education platform, we build practical, project-based courses on exactly this stack — agentic coding, MCP, context engineering, and the modern AI-native IDE workflow — taught around real repositories with an interactive AI instructor, not slide decks. If Kiro made you curious about agentic engineering as a craft rather than a buzzword, that's the rabbit hole our catalog is built for.

Conclusion

Kiro's core bet is simple and, I think, correct: the bottleneck in AI-assisted development was never typing speed — it was the gap between what you meant and what the model built. By making specs the unit of work, adding agent hooks for automation and steering files for persistent context, Kiro turns "AI coding" into something closer to engineering with an agent.

It won't replace judgment, and it isn't the right tool for every task. But for durable, maintainable software built with an AI in the loop, spec-driven development is a genuinely different — and more accountable — way to work. Try it on a real feature, not a toy, and you'll feel the difference fast.

Written by the team at Cursuri-AI.ro — practical, hands-on AI engineering courses for developers and professionals across Eastern Europe, from agentic coding and MCP to context engineering and AI-native IDE workflows.

Sources: kiro.dev · Kiro Specs docs · Kiro Hooks docs · Kiro Steering docs

Stop Vibe-Checking Your LLM: A Developer's Guide to Evals

galian — Mon, 22 Jun 2026 08:24:22 +0000

You tweaked the system prompt, ran the same two test questions you always run, the answers looked good, and you shipped. A week later support is forwarding you screenshots of the model confidently doing the exact thing your prompt was supposed to stop. You never saw it, because "did it get better?" was answered by vibes.

This is the single most common failure mode in shipping LLM features, and it has nothing to do with which model you picked. If your only quality gate is reading a handful of outputs and nodding, every change you make is a coin flip. You can't tell whether a prompt edit helped, hurt, or just moved the failures somewhere you didn't look. Evals are how you replace the nod with a number.

This is a practical guide to building that number — from a 30-row eval set you can write this afternoon, through code-based checks and LLM-as-judge scoring, to wiring the whole thing into CI so regressions get blocked instead of discovered by users. No new framework to adopt; just the discipline that separates a demo from a system.

Why you can't just `assert output == expected`

Traditional tests work because the output space is small and exact. add(2, 2) is 4 or it's a bug. LLM output breaks all three assumptions that make assertEqual work:

It's non-deterministic. The same prompt can produce different text on two calls. Even at temperature 0 you are not guaranteed byte-identical output across runs or model versions.
It's open-ended. "Summarize this ticket" has thousands of correct answers. None of them are string-equal to your reference, and that's fine — a good summary isn't the summary.
It fails softly. A wrong answer isn't a stack trace. It's a fluent, plausible, well-formatted paragraph that happens to be incorrect. Nothing crashes. Nothing logs an error.

So the goal of an eval isn't "is the output identical to the expected string." It's "does the output satisfy the properties I care about" — is it grounded in the provided context, does it stay on policy, does it actually answer the question, is it valid JSON. You're testing behavior against criteria, not bytes against bytes. Once that clicks, the rest is mechanics.

Start with the eval set, not the metric

The instinct is to reach for a fancy metric first. Wrong order. The asset that makes everything else work is a small, representative eval set: a fixed collection of inputs paired with what a good output looks like (or the criteria a good output must meet). This is your golden dataset, your regression suite, your source of truth.

You do not need thousands of examples to start. Thirty to fifty well-chosen pairs turn LLM tuning from vibes into engineering, because now every change is measured against the same fixed bar. Build the set like this:

Mine real failures. Every time the system gets something wrong in dev or prod, that exact input goes into the eval set with a note on what the right behavior is. Your bug reports are your test cases. This is the highest-signal source you have.
Cover the categories, not just the happy path. Easy questions, ambiguous ones, adversarial ones, out-of-scope ones ("I don't know" is the correct answer and you should test that it says so), and the edge cases specific to your domain.
Freeze it and version it. The eval set lives in your repo next to the code. When you add a case, that's a commit. A moving target can't measure progress.
Keep a holdout. If you start tuning prompts against the eval set, you'll overfit to it. Keep a slice you don't look at until you think you're done.

A minimal eval set is just data — JSON, a CSV, a Python list. Here's the shape:

# evals/dataset.py
EVAL_SET = [
    {
        "id": "refund-window-basic",
        "question": "What is our refund window?",
        "context": "Refunds are accepted within 14 days of purchase.",
        "expected": "14 days",
        "must_not_say": ["30 days", "no refunds"],
    },
    {
        "id": "out-of-scope",
        "question": "What's the weather in Cluj tomorrow?",
        "context": "Refunds are accepted within 14 days of purchase.",
        "expected": "REFUSE",  # correct behavior: decline, don't invent
    },
    # ... 30-50 of these, grown from real failures
]

That's the foundation. Everything below scores outputs against this set.

The two halves of every LLM eval

Separate two questions that get mushed together when you eval by eyeball, because they have different fixes:

Did the system retrieve / set up the right context? (a retrieval or pipeline question)
Given that context, did the model produce a good answer? (a generation question)

If you're building RAG, the first half is its own discipline — measuring recall@k and precision@k on questions with known relevant documents tells you whether the right chunk even reached the prompt. That's a deep enough topic that it deserves its own treatment; a dedicated course on RAG and retrieval-augmented generation spends real time there, and the failure modes are different from the ones below. This guide focuses on the second half: scoring the generated answer. The techniques split into two families — code-based checks and model-based judges — and you want both.

Code-based checks: cheaper and more reliable than you think

Before you reach for an LLM to grade an LLM, a surprising amount of quality is checkable with plain code. These checks are deterministic, free, instant, and never hallucinate. Use them for everything they can cover:

Structural validity. If the output should be JSON matching a schema, validate it. A response that doesn't parse is a hard failure, no judgment call needed.
Must-contain / must-not-contain. The answer about a 14-day refund window must contain "14" and must not contain "30." Keyword and regex assertions catch a whole class of factual regressions for free.
Format and bounds. Length limits, required citations present, no leaked system-prompt text, no forbidden phrases (the "as an AI language model" tax), valid enum values.
Semantic similarity. For open-ended answers, embed the output and your reference answer and check cosine similarity passes a threshold. It's fuzzy, but it catches "the answer wandered off topic" without needing a judge model.

# evals/checks.py
import json

def check_structural(output: str, schema_keys: list[str]) -> bool:
    try:
        data = json.loads(output)
    except json.JSONDecodeError:
        return False
    return all(k in data for k in schema_keys)

def check_must_not_say(output: str, banned: list[str]) -> bool:
    low = output.lower()
    return not any(b.lower() in low for b in banned)

The rule of thumb: anything a regex or a schema can catch, don't pay a model to catch. Reserve the expensive, fuzzy judge for the genuinely subjective stuff.

LLM-as-judge: powerful, biased, and fixable

For the subjective half — "is this answer faithful to the source?", "is this helpful?", "is the tone right?" — you use a strong model to grade outputs. This is LLM-as-judge, and it scales human-quality judgment to thousands of examples for the price of an API call. Two metrics carry most of the weight for RAG-style apps:

Faithfulness / groundedness — does every claim in the answer trace back to the provided context, or did the model invent things? This is your hallucination detector.
Answer relevance — does the response actually address the question that was asked, or is it a fluent dodge?

The catch: LLM judges have well-documented biases, and if you ignore them your eval numbers are noise dressed up as signal. The big ones, all reported in the research on using models as evaluators:

Position bias — when comparing two answers, judges favor the one shown first (or in a fixed slot) regardless of quality.
Verbosity bias — judges tend to rate longer, more elaborate answers higher even when a short answer is more correct.
Self-preference — a judge model can favor text written in its own style or by its own family.

You don't abandon the technique; you engineer around the bias:

Score against a rubric, not a vibe. Ask for a 1–5 score with explicit criteria for each level, and require the judge to output its reasoning before the score. A judge forced to justify itself is more consistent.
For pairwise comparisons, randomize and swap. Run each comparison twice with the order flipped; only count it as a win if the judge picks the same answer both times. This cancels position bias directly.
Calibrate against humans. Hand-label 20–30 examples yourself, run the judge on them, and check it agrees with you. If it doesn't, fix the rubric before trusting it on 2,000. An uncalibrated judge is a random number generator with good grammar.
Use a strong model as the judge. Grading is harder than answering. Use a current frontier model for the judge even if your app runs on a smaller, cheaper one.

# evals/judge.py — sketch of a rubric-based faithfulness judge
JUDGE_PROMPT = """You are grading whether an ANSWER is fully supported by the CONTEXT.

CONTEXT:
{context}

ANSWER:
{answer}

Rules:
- A claim is "supported" only if the CONTEXT states or directly implies it.
- Outside knowledge does NOT count as support.

First write one sentence of reasoning. Then output a JSON object:
{{"reasoning": "...", "faithful": true|false}}"""

def judge_faithfulness(client, context: str, answer: str) -> bool:
    resp = client.complete(
        JUDGE_PROMPT.format(context=context, answer=answer),
        temperature=0,
    )
    return json.loads(resp)["faithful"]

Designing judges that hold up — picking the rubric, calibrating, knowing when a model is the wrong tool for the grade — is exactly the muscle a course on AI evals in production builds, because it's the difference between "the new prompt feels better" and "faithfulness went from 0.78 to 0.91 on the holdout."

Wire it into CI, or it won't survive contact with deadlines

An eval you run by hand when you remember to is an eval you'll stop running the week things get busy. The whole point is to make regressions impossible to ship silently, and that means the eval runs automatically on every change to a prompt, a retrieval setting, or a model version.

The pattern is a regression gate: run the eval set, compute the aggregate score, and fail the build if the score drops below a threshold (or below the last known-good baseline). It looks like an ordinary test suite, because that's what it is.

# tests/test_evals.py
import pytest
from evals.dataset import EVAL_SET
from evals.checks import check_must_not_say
from myapp import answer_question

PASS_THRESHOLD = 0.90  # 90% of eval cases must pass to ship

def run_case(case) -> bool:
    output = answer_question(case["question"], case["context"])
    if case["expected"] == "REFUSE":
        return "i don't know" in output.lower() or "can't" in output.lower()
    if not check_must_not_say(output, case.get("must_not_say", [])):
        return False
    return case["expected"].lower() in output.lower()

def test_eval_suite_meets_threshold():
    results = [run_case(c) for c in EVAL_SET]
    score = sum(results) / len(results)
    failed = [c["id"] for c, ok in zip(EVAL_SET, results) if not ok]
    assert score >= PASS_THRESHOLD, f"Eval score {score:.2f} below {PASS_THRESHOLD}. Failed: {failed}"

A few practical notes that keep this sane in CI:

Pin the model version. Provider model IDs update, and an unpinned model means your eval baseline shifts under you for reasons unrelated to your code. Pin it, and treat a model upgrade as its own deliberate eval run.
Budget for cost and flakiness. LLM calls cost money and occasionally time out. Cache where you can, run the judge-heavy suite on a schedule rather than every commit if needed, and set a slightly forgiving threshold so one stochastic blip doesn't red-X a good PR.
Log the failures, not just the score. When the gate trips, the output should name which cases regressed so the fix is obvious. A bare "0.86 < 0.90" sends you debugging blind.

Now a prompt change is a PR with a number attached. The reviewer sees faithfulness went up and refusal rate held steady, or they see it tanked and the build is red. That's the entire difference between hoping and knowing.

Five mistakes that quietly poison your evals

Even teams that build evals often undermine them. Watch for these:

Testing only the happy path. If every case in your set is a question the system already answers well, your score is a flattering lie. Adversarial and out-of-scope cases are where the signal is.
Tuning on your test set. Optimize prompts against the same examples you grade on and you'll overfit to them. Keep a holdout you don't peek at.
An uncalibrated judge. Trusting an LLM judge you never checked against your own labels is trusting a number you made up. Calibrate first.
One giant blended score. A single average hides that faithfulness improved while refusals broke. Track metrics separately so a regression in one can't be masked by a gain in another.
Letting the set rot. Your product changes; cases that no longer reflect real usage drag the signal down. Prune and grow the set as part of normal work, the same way you maintain any test suite.

None of these are exotic. They're the eval equivalent of not testing error paths — obvious in hindsight, easy to skip under deadline.

How this connects to the rest of your LLM stack

Evals aren't a standalone chore; they're the measurement layer that makes every other improvement legible. When you tighten a prompt, evals tell you if it worked — which is why structured prompt engineering and a real eval loop are two halves of the same skill. When you redesign what goes into the context window — what to include, what to cut, how to order it — evals are how you know the redesign helped rather than just felt cleaner; that discipline of deciding what earns a place in the prompt is increasingly called context engineering and has its own dedicated course. And when you wire up function calling, multi-tool orchestration, and the production concerns of a real integration, evals are what keep the whole pipeline honest as it grows — the kind of end-to-end build covered in a deeper course on advanced LLM integration. The pattern is always the same: build the measurement first, then every change becomes verifiable instead of hopeful.

Conclusion

The teams whose LLM features actually hold up in production aren't using a secret model or a magic prompt. They're disciplined about measurement. They have a versioned eval set grown from real failures, code-based checks for everything a regex can catch, calibrated LLM judges for the subjective rest, and a CI gate that blocks regressions before users find them.

Start smaller than you think you can. Write thirty cases this afternoon — half of them things your system currently gets wrong — add three code checks and one rubric-based judge, and put a threshold in your test suite. The first time a red build stops you from shipping a prompt change that would have quietly broken refusals, you'll never go back to vibe-checking. That's the moment an LLM demo becomes an LLM system people can trust.

The courses linked throughout are part of Cursuri-AI.ro, an AI-learning platform with hands-on, current tracks on evaluating AI systems in production, prompt engineering, RAG, and advanced LLM integration.

Sources & further reading:

Zheng et al. — Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (documents position, verbosity, and self-enhancement bias in LLM judges)
Liu et al. — G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment
Liang et al. — Holistic Evaluation of Language Models (HELM)

This article is educational content. Techniques and tooling evolve quickly; validate approaches against your own data and current library documentation.

How Click Fraud Works — and How to Detect Bot Clicks in Real Time

galian — Thu, 18 Jun 2026 13:35:47 +0000

Every time someone clicks your Google or Bing ad, you pay. The uncomfortable part:
a meaningful share of those clicks were never going to become customers. They come
from bots, competitors burning your budget, click farms, and misconfigured scripts
hammering your landing page. Independent studies — and our own data at
ProtectAds —
put invalid traffic at roughly 15–30% of paid-search spend.

If you run PPC, that's not a rounding error. On a €10,000/month budget, it's
€1,500–€3,000 quietly leaking out every month. This article breaks down how click
fraud actually works, why the ad platforms don't fully stop it for you, and why the
"just block the IP" approach falls apart at scale.

First, the vocabulary: invalid traffic vs. click fraud

The ad industry (IAB/MRC) splits Invalid Traffic (IVT) into two buckets:

GIVT — General Invalid Traffic: the obvious stuff. Known data-center IPs, declared bots and crawlers, spiders. Detectable with lists and simple rules.
SIVT — Sophisticated Invalid Traffic: the expensive stuff. Hijacked devices, headless browsers pretending to be Chrome, residential-proxy networks, click farms with real fingerprints, automation that mimics human timing.

Click fraud is the malicious, intent-driven slice of IVT aimed specifically at
your ads — a competitor draining your daily budget, or a click farm monetizing fake
engagement. GIVT you can filter with a blocklist. SIVT is where real detection
earns its keep. (We go deeper on this distinction
here.)

Why the platforms don't fully solve this for you

Google and Microsoft do filter obvious invalid clicks and issue some credits. But
their filtering is conservative, opaque, and applied after the fact — you find out
in aggregate, weeks later, with little per-click evidence. They're also structurally
conflicted: invalid clicks are still billed first and credited later, if at all.

That leaves a gap for sophisticated invalid traffic that looks human enough to pass
platform filters but never converts. Closing that gap is an engineering problem:
score every click in real time and act on it before the budget is gone.

Why sophisticated click fraud is so hard to catch

The obvious stuff (GIVT) is easy to filter. The expensive stuff (SIVT) is hard on
purpose — it's built to look human:

It rotates through fresh IPs and residential proxies, so any static blocklist is out of date the moment you save it.
It runs on real or convincingly spoofed devices, so a single attribute rarely gives it away.
It mimics human timing and behavior well enough to slip past simple rules.

That's why "detect fraud" isn't one trick — it's continuous analysis at scale,
correlating signals across many clicks and campaigns over time, with thresholds
tuned so you catch the bad traffic without blocking real buyers. Doing that
reliably, and fast enough to act before the budget is gone, is the hard part — and
it's why most advertisers are better off with a dedicated system than a homegrown
script. (Here's
how ProtectAds approaches it.)

Why "just block the IP" doesn't scale

The first instinct is a spreadsheet of bad IPs pasted into Google Ads exclusions.
It breaks down fast:

Problem	Manual blocklist	Automated protection
New IPs every day	You're always behind	Handled continuously
Attackers rotate IPs constantly	Whack-a-mole	Doesn't rely on a static list
Ad platforms cap exclusion lists	Fills up fast	Prioritizes the worst offenders automatically
Evidence for refund claims	None	Per-click log you can export
Across many campaigns/accounts	Doesn't	Centralized

IPs are cheap and disposable for attackers; your manual list is neither. Sustainable
protection has to run continuously, automate the exclusions, and keep an audit trail
you can take back to the ad platform.

Turning detection into protection

Detection is only half the job — you have to act on it. A working pipeline:

Observe ad clicks as they hit your site.
Assess each one in real time to tell genuine visitors from invalid traffic.
Block offending IPs by pushing them to your campaign exclusion lists automatically — no manual copy-paste.
Report with a per-click, per-campaign log so you can request ad credits with evidence instead of vibes.

This is exactly what ProtectAds
does for Google Ads (including Performance Max / PMax) and Microsoft (Bing)
Ads. You connect your account once, and it runs the detect → block → report loop
continuously. Agencies running multiple client accounts and domains get dedicated
agency plans
for managing protection at scale.

A note on scope: ProtectAds protects Google Ads and Bing Ads. Meta/Facebook Ads
aren't covered — paid search is where competitor and bot click fraud hits
hardest, so that's where we focus.

How much is this worth to you?

Take your monthly paid-search spend and multiply by 15–30%. That range is your
realistic exposure to invalid traffic. Even at the low end, recovering it usually
dwarfs the cost of detection — which is the entire economic argument for automating
this instead of eyeballing reports once a quarter. (You can sanity-check your own
number with the
click fraud calculator.)

Try it on your own campaigns

If you're spending on Google or Bing ads and you've ever wondered why your
click-through looks healthy but conversions don't follow, invalid traffic is a prime
suspect. The fastest way to find out is to point real detection at your live
campaigns and watch what it flags.

Start a free ProtectAds trial —
connect your Google Ads or Bing account, see the invalid clicks in your own data,
and cancel anytime. Your ad budget is better spent on people who might actually buy.

Written by the team at ProtectAds —
real-time click fraud detection and protection for Google Ads and Microsoft (Bing) Ads.

Model Context Protocol Explained: Build Your First MCP Server in Python

galian — Thu, 18 Jun 2026 12:58:29 +0000

If you've integrated an LLM with a database, a ticketing system, and an internal API, you've written the same glue three times — and you'll write it again for the next model and the next tool. That M×N integration problem is exactly what the Model Context Protocol (MCP) was built to kill. Instead of every application hand-rolling a bespoke connector for every tool, MCP defines one open standard that any model and any tool can speak.

The analogy its authors at Anthropic use is deliberately mundane: MCP is "a USB-C port for AI applications." You don't wire each device to each laptop with a custom cable; you agree on one connector and everything interoperates. That framing is the whole point, and it's why MCP went from an Anthropic open-source release in late 2024 to something adopted across the industry — including by OpenAI and Google — by 2026.

This is a practical guide. We'll cover what MCP actually is, the three-part architecture, the primitives you'll use every day, and then build a real, working MCP server in Python that a host like Claude Code or an IDE can call. No hand-waving — by the end you'll have code that runs.

What problem MCP actually solves

Before MCP, "give the model access to our systems" meant writing function-calling glue specific to one provider's SDK, one tool's API, and one application's plumbing. Swap the model and you rewrote the tool layer. Add a tool and you touched every app that needed it. With M applications and N tools, you were on the hook for roughly M×N integrations.

MCP turns that into M+N. Tool authors write one MCP server. Application authors add one MCP client. Any host that speaks MCP can use any server that speaks MCP — no per-pair glue. The server you write for your company's CRM works in Claude Code, in your custom agent, and in whatever host ships next year, without changes.

That's the strategic shift: tools and models become decoupled, and the integration surface stops growing quadratically. Everything below is just the mechanics of how that's achieved.

The architecture: host, client, server

MCP has exactly three roles. Getting these straight makes everything else click.

Host — the LLM application the user interacts with. Claude Code, an AI-enabled IDE, a desktop assistant, or your own agent. The host orchestrates the model and decides which servers to connect to.
Client — a connector that lives inside the host. The host spins up one client per server, and each client keeps a dedicated 1:1 connection to its server. You rarely write this yourself; the host's framework provides it.
Server — a lightweight program that exposes capabilities (tools, data, prompt templates) over the protocol. This is what you build. A server can wrap a local SQLite file, a SaaS API, a filesystem, or anything you can reach with code.

Under the hood, client and server exchange JSON-RPC 2.0 messages over a transport. There are two you care about:

stdio — the server runs as a local subprocess and communicates over standard input/output. Perfect for local tools, dev work, and anything that touches the user's own machine.
Streamable HTTP — the server runs as a remote service reachable over HTTP, with streaming for long-running responses. This is the modern remote transport (it superseded the older HTTP+SSE approach) and it's what you deploy when the server lives somewhere central.

You write your server logic once; choosing stdio vs. HTTP is mostly a deployment decision, not a rewrite.

The three primitives you'll actually use

MCP servers expose capability through three primitives. The distinction between them isn't bureaucratic — it encodes who is in control, which matters enormously for safety and UX.

Tools — model-controlled

Tools are functions the model decides to call: query a database, send an email, hit an API, run a calculation. They can have side effects, so a well-behaved host asks for user approval before executing one. If you've used function calling, tools are the MCP-native, portable version of it. This is the primitive you'll reach for most.

Resources — application-controlled

Resources are read-only data the application pulls into context: a file's contents, a database row, a config blob, a documentation page. They're identified by URI (for example file:///logs/today.log or db://customers/42) and they don't do anything — they inform. The host decides when and whether to load them, which keeps the context window under deliberate control rather than at the model's whim.

Prompts — user-controlled

Prompts are reusable templates the user invokes intentionally — think a slash-command like "summarize this PR" or "draft a release note." They standardize the high-value interactions your server enables so users don't have to re-type elaborate instructions.

The mental model: tools are for the model, resources are for the app, prompts are for the user. Designing on the correct side of that line is the difference between an integration that feels safe and predictable and one that surprises people. That separation of control is also at the heart of building reliable agents, which is why a structured course on designing autonomous AI agents spends real time on it rather than treating every capability as "just a tool."

Build your first MCP server in Python

Enough theory. Let's build a server that exposes a tool, a resource, and a prompt — and actually runs.

The official Python SDK ships a high-level helper, FastMCP, that handles the JSON-RPC plumbing, schema generation, and transport for you. You describe capabilities with decorators; the SDK infers the input schema from your type hints and the description from your docstring.

Setup

The modern toolchain uses uv, but plain pip works too:

# with uv (recommended)
uv init mcp-demo && cd mcp-demo
uv add "mcp[cli]"

# or with pip
pip install "mcp[cli]"

The server

Create server.py:

from mcp.server.fastmcp import FastMCP

# Name your server — hosts show this to the user.
mcp = FastMCP("demo-tools")


@mcp.tool()
def word_count(text: str) -> int:
    """Count the number of words in a piece of text."""
    return len(text.split())


@mcp.tool()
def days_between(start: str, end: str) -> int:
    """Return the number of days between two ISO dates (YYYY-MM-DD)."""
    from datetime import date
    s = date.fromisoformat(start)
    e = date.fromisoformat(end)
    return abs((e - s).days)


@mcp.resource("notes://team")
def team_notes() -> str:
    """Expose the team's shared notes as read-only context."""
    # In real life this would read a file, a DB row, or an API.
    return "Release freeze starts Friday. Owner: platform team."


@mcp.prompt()
def code_review(language: str, code: str) -> str:
    """A reusable prompt template for reviewing a code snippet."""
    return (
        f"You are a senior {language} engineer. Review the code below for "
        f"correctness, security, and readability. Be specific.\n\n{code}"
    )


if __name__ == "__main__":
    # Default transport is stdio — ideal for local hosts.
    mcp.run()

That's a complete, valid MCP server. Notice what you did not write: no JSON-RPC handling, no schema definitions, no transport code. The type hints on word_count(text: str) -> int become the tool's input/output schema automatically, and the docstring becomes the description the model reads to decide when to call it. That docstring is not decoration — it's the model's only instruction manual for the tool, so write it like an API contract.

Inspect it before wiring it to a model

The SDK includes a dev inspector so you can poke at your server without an LLM in the loop:

uv run mcp dev server.py

This launches the MCP Inspector, a local UI where you can list the server's tools, resources, and prompts, call them with hand-entered arguments, and see exactly what comes back. Debugging here — before a model is involved — is the single biggest time-saver in MCP development. If a tool misbehaves with the inspector, the problem is your server, not the model.

Connect it to a host

To use the server from Claude Code or another MCP-aware host, you register it. For Claude Code, that's a one-liner:

claude mcp add demo-tools -- uv run server.py

For hosts configured by file, you add an entry pointing at the command that launches your server:

{
  "mcpServers": {
    "demo-tools": {
      "command": "uv",
      "args": ["run", "server.py"]
    }
  }
}

Restart the host, and your tools, resource, and prompt show up — the model can now call word_count, the app can pull in notes://team, and the user can invoke the code_review prompt. The same server.py, unchanged, works in every one of them. That portability is the entire payoff, and pushing a server like this from a local toy to something production-grade — auth, logging, error handling, deployment over Streamable HTTP — is exactly the jump covered in this hands-on course on building real AI applications in Python.

From toy to production: what the quickstart doesn't tell you

The server above works, but shipping MCP to real users surfaces concerns the happy path hides. These are the ones that bite teams:

Authentication and authorization. A remote MCP server is a service on the internet. Streamable HTTP servers support OAuth-based auth, and you need it — an unauthenticated tool that can query your database or send email is an incident waiting to happen. Treat the server's tool surface as your real attack surface.

The model can be tricked into calling tools. Because tools are model-controlled, a prompt-injection payload hidden in a document or web page the model reads can try to coax it into calling a destructive tool. The mitigations are concrete: keep destructive tools behind user approval, scope each server's permissions narrowly, validate every argument server-side, and never assume the model's call is benign just because it's well-formed. This intersection of capability and risk is precisely why agentic systems need a security mindset, not just a features mindset — the subject of a dedicated course on AI security and ethical engineering.

Tool descriptions are part of your context budget. Every tool's name, description, and schema get loaded into the model's context. Twenty sprawling tools with verbose docstrings quietly eat thousands of tokens and degrade the model's ability to choose well. Curate your tool surface like an API you have to maintain: fewer, sharper tools beat a kitchen sink. Managing what occupies the context window — tools included — is its own discipline, which a course on context engineering for AI agents treats as a first-class skill rather than an afterthought.

Errors must be legible to a model, not just a human. When a tool fails, return a structured, descriptive error the model can reason about and recover from — not a raw stack trace. "Customer 42 not found; verify the ID" lets the model self-correct; a 500 with a Python traceback does not.

Stateful vs. stateless. stdio servers are naturally per-session and local; HTTP servers may serve many clients and need you to think about concurrency and isolation. Decide early, because retrofitting state handling is painful.

None of these are reasons to avoid MCP — they're the normal engineering of turning a protocol demo into a dependable system, and the same skills you'd apply to any service boundary apply here.

Why this matters for how you build in 2026

MCP's quiet significance is that it makes tools a portable asset instead of a per-app liability. Write a great server for your internal systems once, and it appreciates: every new host, every new model, every teammate's agent can use it without you lifting a finger. That's the opposite of the function-calling glue we used to throw away every time a model changed.

It also pushes good architecture by default. The host/client/server split forces a clean seam between "the model and the app" and "the capability," which is exactly the boundary you want when models get swapped, upgraded, or — as 2026 has reminded everyone — occasionally yanked. Building agents on top of well-designed MCP servers, with the right model routed to the right step, is where a lot of the real engineering leverage lives now; if you want that end-to-end picture, there's a focused course on the Model Context Protocol and building enterprise integrations that goes far deeper than a single tutorial can.

Conclusion

The Model Context Protocol is not hype — it's plumbing, and good plumbing is what lets a field scale. It replaces M×N bespoke integrations with M+N reusable ones, gives you three clear primitives with sane control boundaries, and lets you ship a server in a dozen lines of Python that works across every MCP-aware host.

Start small: build the demo-tools server above, poke it with the inspector, wire it into a host you already use. Then point it at something real in your own stack — a read-only resource over your logs, a single well-scoped tool over an internal API. The first time you watch a model use a capability you exposed once and never re-integrated, the M+N promise stops being abstract.

Write the server once. Let every model use it.

Sources & further reading:

Anthropic — Introducing the Model Context Protocol
Model Context Protocol — Official specification and documentation
Model Context Protocol — Python SDK

This article is educational content. APIs and SDK details evolve; check the official MCP documentation for the current specification before building production systems.

Anthropic disables access to Fable 5 and Mythos 5 to comply with government directive

galian — Sat, 13 Jun 2026 10:04:07 +0000

On June 12, 2026, a frontier AI model disappeared overnight for everyone outside the United States. Not because of an outage, and not because the vendor changed its pricing — but because of a US government export-control directive. Anthropic had to disable Claude Fable 5 and Claude Mythos 5 for all customers, just three days after making Fable 5 — its first "Mythos-class" model — public.

If you build on LLMs, the interesting part of this story isn't the geopolitics. It's the engineering question it forces: what happens to your application when your model is gone tomorrow morning, through no fault of your own?

This is a practical guide to answering that question. We'll cover what actually happened (briefly, and sourced), why a piece of software can fall under export controls at all, and then spend most of our time on the part that matters: how to architect an LLM application so that no single model — from any provider — can take it down.

What happened, briefly and sourced

Anthropic published a statement titled "Statement on the US government directive to suspend access to Fable 5 and Mythos 5." Per that statement, the US government issued an export-control directive requiring the company to suspend access to both models for any non-US national, whether inside or outside the United States.

To comply, Anthropic disabled both models for all customers — not just the targeted group. Everything else stayed online: the statement notes that "access to all other Anthropic models will not be affected." Opus, Sonnet, and Haiku kept working; only the Mythos-class tier went dark.

The government's stated rationale was that it believed it had identified a method of jailbreaking Fable 5's safeguards. Anthropic publicly disagreed with the reasoning — arguing the vulnerability was narrow, that comparable capabilities already exist in other public models (it named GPT-5.5), and that applying this standard across the board "would essentially halt all new model deployments for all frontier model providers." The company called it a misunderstanding and said it was working to restore access.

The takeaway for builders has nothing to do with whether Anthropic or the government is right. It's this: a model you depend on can become unavailable for reasons entirely outside both your control and your vendor's control — and on essentially no notice.

Why software can be "export-controlled" in the first place

It feels strange that an API you call over HTTPS can be subject to export law. It makes sense the moment you see frontier AI the way regulators do: as a dual-use technology.

A dual-use technology serves legitimate and potentially dangerous purposes at the same time. A sufficiently capable model can accelerate both useful research and things nobody wants proliferating — from assisting cyberattacks to sensitive biological domains. That's precisely why Anthropic layers safety classifiers (for cyber and bio) on top of its base model to produce the public Fable 5, while the unrestricted Mythos 5 ships only in a limited program.

Under the US Export Administration Regulations (EAR), the government can restrict the export of strategic technology to non-US persons. The key concept is the "deemed export": giving a foreign national access to controlled technology — even one physically located in the US — counts as an export in its own right. That's why the directive targeted "any non-US national, regardless of location," and why the simplest compliant move was to shut the models off for everyone rather than try to filter access by nationality in real time.

If you're a developer in the EU, the UK, India, or anywhere outside the US, the practical reading is blunt: from the directive's point of view, you are the "foreign national," and the model can be pulled out from under you with no warning.

The real lesson: a model is a dependency, not a constant

This episode is a textbook case of vendor risk and business continuity. The model wasn't deprecated, didn't get more expensive, and wasn't beaten by a competitor. It vanished for reasons external to your product and even to your vendor.

For anyone who wired a product, an internal workflow, or a customer promise to one specific model, the message is clear: an LLM is an external dependency — exactly like a cloud provider, a payments processor, or any third-party API. And you manage external dependencies with redundancy, not hope.

The lesson is not "don't use the best model" or "don't trust Anthropic." Anthropic remains one of the most serious vendors in the market, and the transparency of this disclosure proves it. The lesson is architectural: don't build such that the disappearance of any single model stops your product.

Designing for provider resilience

Resilience here doesn't mean running ten models in parallel. It means being able to switch — quickly, deliberately, and without rewriting your application. Four building blocks get you there.

1. An abstraction layer (don't call the SDK from everywhere)

The single most damaging habit is sprinkling client.messages.create(...) across dozens of files. When you need to switch providers, you're now doing surgery on your whole codebase under time pressure. Put one internal interface between your app and any vendor.

from dataclasses import dataclass
from typing import Protocol

@dataclass
class Completion:
    text: str
    provider: str
    model: str

class LLMProvider(Protocol):
    name: str
    def complete(self, prompt: str, *, max_tokens: int = 1024) -> Completion:
        ...

Every provider — Anthropic, OpenAI, Google, a self-hosted model — implements the same complete() contract. Your application only ever talks to LLMProvider. Swapping a vendor becomes a config change, not a refactor. Designing these seams well is core system-architecture work; if you want the full treatment of boundaries, adapters, and scaling concerns, this course on AI system architecture at scale goes well beyond a single code sample.

2. A router with failover and a circuit breaker

With a common interface, the router becomes simple: try the primary, fall back on failure, and stop hammering a provider that's clearly down.

import time

class ModelRouter:
    def __init__(self, providers: list[LLMProvider], cooldown_s: int = 30):
        self.providers = providers           # ordered: primary first
        self.cooldown_s = cooldown_s
        self._down_until: dict[str, float] = {}

    def _available(self, p: LLMProvider, now: float) -> bool:
        return now >= self._down_until.get(p.name, 0)

    def complete(self, prompt: str, **kw) -> Completion:
        now = time.monotonic()
        last_error: Exception | None = None
        for p in self.providers:
            if not self._available(p, now):
                continue
            try:
                return p.complete(prompt, **kw)
            except Exception as e:        # timeout, 4xx/5xx, or a hard 403 like a suspension
                last_error = e
                self._down_until[p.name] = now + self.cooldown_s   # trip the breaker
        raise RuntimeError(f"All providers unavailable; last error: {last_error}")

This is deliberately small. The point is the shape: an ordered list of interchangeable providers, a breaker that quarantines a failing one for a cooldown, and an app that never sees the difference. A sudden 403/access revocation — exactly what a suspension looks like to your code — is just another failure that trips the breaker and routes to the next provider.

3. Redundancy across jurisdictions, not just vendors

Keep at least two providers ready, ideally under different regulatory regimes. The Fable 5 episode is precisely why jurisdictional diversity matters and not just vendor diversity: a single government action took out one vendor's top tier for a whole class of users. Two US-based providers don't fully protect you from a US-wide policy event; a mix does.

Choosing those alternates well — on real capability, cost, and now exposure — is a skill in itself. If you want a structured, side-by-side framework instead of vibes, there's a dedicated AI model comparison course that covers how to evaluate and route across the 2026 lineup.

4. A safety net you actually control

For your most critical paths, keep an open-weight model you can self-host (something from the Llama or Qwen families). It doesn't have to be the best model in the world — it has to be yours and good enough to keep you running. A model on infrastructure you control cannot be revoked by anyone's directive. That's the difference between "degraded service" and "outage" on the day a managed model disappears.

Portability and switch drills

Two cross-cutting habits make all of the above real:

Portable prompts and evals. If your prompts and evaluation suites are tuned to one model's quirks, you've created a hidden dependency. Treat them as portable artifacts and test them across providers, so a switch doesn't silently tank quality.
Rehearsed failover. A fallback plan you've never executed is an assumption, not a guarantee. Trigger a manual switch to your secondary on a schedule and watch what breaks — discover problems in a drill, not mid-incident.

If your application is agentic — multi-step loops, tool use, sub-agents — provider resilience gets harder, because a mid-loop failover has to preserve state and tool context. Building that correctly is its own discipline, covered in this course on designing autonomous AI agents, and the end-to-end practice of wiring real applications across SDKs (Anthropic, OpenAI, and self-hosted) is the focus of this hands-on course on building AI apps in Python.

A note on governance, not just plumbing

There's a second, quieter lesson here for technical leaders. The trigger was a safety-and-governance dispute: who decides, on what evidence, and how fast, that a frontier capability is too risky for some users. As AI moves deeper into critical systems, "is this model available?" becomes a governance question as much as an uptime one — and understanding why safety classifiers, dual-use controls, and red-teaming exist is part of building responsibly. That intersection of security, ethics, and engineering is exactly what this course on AI security and ethical engineering is about.

Conclusion

The suspension of Fable 5 and Mythos 5 isn't, at its core, a story about a broken model. It's a story about how quickly a frontier capability can move from "available to everyone" to "unavailable by government order" — and about who pays the bill when it does. Not the vendor. The person who built on that model assuming it would always be there.

Anthropic calls it a misunderstanding and is working to restore access; the models may well return in some form. But resilience isn't built on "probably." It's built on architecture: an abstraction layer, at least one fallback from a different jurisdiction, a safety net you control, and the habit of rehearsing the switch before you need it.

Engineers who treat models like the external dependencies they are will look back on the Fable 5 episode as a useful lesson rather than a costly outage. The difference isn't which model you pick. It's the architecture you wrap around it.

The courses linked throughout are part of Cursuri-AI.ro, an AI-learning platform with deep, hands-on tracks on system architecture, model selection, agent design, and the practical engineering of LLM applications — kept current with the 2026 lineup.

Sources:

Anthropic — Statement on the US government directive to suspend access to Fable 5 and Mythos 5
Anthropic — Claude Fable 5 and Claude Mythos 5
CNBC — Anthropic disables access to Fable 5 and Mythos 5 to comply with government directive
9to5Mac — Anthropic pulls Claude Mythos 5 and Claude Fable 5 following US government directive
U.S. Bureau of Industry and Security — Export Administration Regulations (EAR)

This article is for informational purposes and is not legal advice. Dates and named individuals drawn from press reporting may be updated as the situation evolves; check official sources for the current access status.

Claude Fable 5: A Developer's Guide to Anthropic's New Top

galian — Wed, 10 Jun 2026 22:22:18 +0000

Anthropic just moved the ceiling again. Claude Fable 5 is the company's most powerful, most intelligent model to date — and it isn't "Opus 4.9." It's a new tier that sits above the entire Opus family. If you build with LLMs, that distinction matters: it changes how you think about model routing, cost, and which tasks deserve your most capable (and most expensive) reasoning.

This is a practical, no-hype guide for developers. We'll cover what Claude Fable 5 actually is, how it slots into Anthropic's 2026 lineup, what changes in the API surface, when the premium is justified, and how to migrate existing code. Everything here is grounded in Anthropic's own model and API documentation — no invented benchmarks.

What Is Claude Fable 5?

Claude Fable 5 is Anthropic's flagship reasoning model, exposed through the API as claude-fable-5. The headline facts:

A new tier above Opus. Until now, "Opus" was the top of the Claude lineup. Fable 5 establishes a level above it — positioned for the hardest reasoning, planning, and long-horizon agentic work.
1M-token context window, with up to 128K tokens of output.
Premium pricing: roughly $10 / $50 per million input / output tokens — about double Opus 4.8's $5 / $25. That price tag is the whole point: Fable 5 is a precision tool you point at the problems that justify it, not a default for every call.
Adaptive thinking only. The fixed "thinking budget" knob is gone. The model decides how much to reason per request.

The mental model to internalize: Fable 5 is the peak of a four-tier lineup, and capability scales with cost. You don't run your whole pipeline on it any more than you'd render every frame of a film at maximum quality regardless of the shot. You route the hard parts to it.

Where Fable 5 Fits in the 2026 Anthropic Lineup

Anthropic's current family is a ladder of capability-vs-cost. Picking the right rung per task is one of the highest-leverage habits an AI engineer can build.

Model	Role	Reach for it when…
Claude Fable 5	Absolute peak capability; premium price	The hardest reasoning, planning, cross-cutting refactors, and long-running agent loops where correctness outweighs cost
Claude Opus 4.8	Top of the Opus family; a strong default in Claude Code	Complex day-to-day work — planning, large refactors, tricky debugging — with a better capability/cost ratio than Fable
Claude Sonnet 4.6	Balanced, fast, 1M context	The bulk of everyday coding, reading, and iteration
Claude Haiku 4.5	Light, fast, cheap	High-volume small operations, classification, auxiliary steps

The practical takeaway: model choice is a cost-and-quality lever. A well-designed system routes each sub-task to the cheapest model that can do it well, and escalates to Fable 5 only where the payoff is real. If you want a structured, side-by-side breakdown of the 2026 models and how to choose between them, there's a dedicated AI model comparison course that goes deeper than any single table can.

What Changes in the API

This is the part developers actually care about. Fable 5 shares the modern Claude request surface (the same one introduced with Opus 4.7/4.8), with a couple of sharp edges worth knowing before you ship.

Adaptive thinking, not a token budget

Fable 5 supports a single thinking mode: adaptive. You no longer pass a fixed budget_tokens value — the model regulates its own reasoning depth.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-fable-5",
    max_tokens=16000,
    thinking={"type": "adaptive"},        # adaptive is the only thinking mode
    output_config={"effort": "xhigh"},    # strong default for coding/agentic work
    messages=[
        {"role": "user", "content": "Refactor this module and add unit tests."}
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

A few things that will save you a debugging session:

Don't send temperature, top_p, top_k, or budget_tokens. They're removed on this generation and return 400. Steer behavior with prompting and the effort parameter instead.
Don't send thinking={"type": "disabled"} on Fable 5. Unlike Opus 4.8/4.7, an explicit disabled returns 400 here. To run without thinking, omit the thinking parameter entirely. This is the one genuinely new breaking change relative to the Opus 4.x line — easy to miss.
Thinking text is omitted by default. Thinking blocks still stream, but their content is empty unless you opt in with thinking={"type": "adaptive", "display": "summarized"}. If your UI shows reasoning progress, set this or your users will see a long pause before output.

The effort parameter is your real control knob

output_config.effort accepts low, medium, high, xhigh, and max. It controls how much the model thinks and acts — not just thinking depth. For coding and agentic workloads, xhigh is the sweet spot and is the effort level Claude Code defaults to. Treat effort as something to tune per route: max for correctness-critical work, medium/low for latency-sensitive or simple steps.

Large outputs need streaming

With up to 128K output tokens available, non-streaming requests will hit SDK HTTP timeouts well before that ceiling. For anything above ~16K max_tokens, stream and collect the final message:

with client.messages.stream(
    model="claude-fable-5",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "xhigh"},
    messages=[{"role": "user", "content": "Generate the full migration plan."}],
) as stream:
    message = stream.get_final_message()

What it still supports

Fable 5 keeps the modern toolbox: structured outputs (output_config.format), prompt caching (minimum cacheable prefix ~2,048 tokens), server-side compaction for very long conversations, web search with dynamic filtering, and task budgets (beta) for telling an agent how many tokens it has for a full loop. If you're wiring these into a real application, the patterns matter as much as the model — that's the focus of this hands-on course on building AI apps with the Anthropic and OpenAI SDKs, which walks from raw API calls to a production-shaped product.

Fable 5 for Agentic Coding

The reason Fable 5 is interesting to developers specifically is long-horizon agentic execution: multi-file refactors, overnight runs, and tasks that span dozens of tool calls without a human correcting course.

Three habits get the most out of it:

Give the full task spec up front in one well-formed turn. Fable 5 plans better when it has the complete goal early; drip-feeding requirements across many turns tends to cost more tokens and sometimes performance.
Run at high or xhigh effort with generous max_tokens. Long-horizon coherence comes partly from the model reasoning more at each step — give it room.
Route deliberately. Use Fable 5 for the planning and the genuinely hard edits; delegate mechanical or high-volume sub-steps to Sonnet 4.6 or Haiku 4.5.

If terminal-first agentic coding is your world, the workflow discipline — CLAUDE.md project memory, plan/edit/review loops, hooks as deterministic guardrails, and model routing across the lineup — is exactly what a dedicated Claude Code mastery course covers end to end. Agent architecture beyond a single tool (orchestration, delegation, parallelism) is its own discipline, well covered in this course on designing autonomous AI agents.

Context is a resource, even at 1M tokens

A 1M-token window is not a license to dump everything into context. Irrelevant context dilutes the model's attention and costs tokens on every turn, no matter how capable the model is. The skill that separates engineers who "get lucky" with agents from those who ship reliable ones is deliberate context engineering — what to load, what to compact, what to persist as memory across sessions. It's enough of a topic to warrant its own course on context engineering and memory for agents.

When Fable 5 Is Actually Worth the Premium

Here's the honest cost reasoning, because "use the best model" is bad engineering advice.

At roughly double the per-token cost of Opus 4.8, Fable 5 pays off when the cost of a wrong answer is high relative to the token bill:

Worth it: a complex cross-service refactor where a subtle regression costs hours of human review; a planning step that determines the trajectory of a long agent run; an analysis where correctness is non-negotiable.
Not worth it: routine edits, summaries, classifications, and the long tail of mechanical sub-tasks — those belong on Sonnet 4.6 or Haiku 4.5.

A useful rule of thumb: let Fable 5 plan and decide, and let cheaper models execute the parts that are already well-specified. That keeps your bill proportional to difficulty instead of flat-out maximal.

The other lever is effort. Because effort matters more on this generation than on any prior Opus, a Fable 5 call at medium effort can be both cheaper and faster than an Opus 4.8 call at xhigh for some tasks — so benchmark on your own workload rather than assuming "bigger model = always slower and pricier in practice."

Migrating from Opus 4.8 / 4.7

If you're already on the modern Claude surface, moving to Fable 5 is mostly a model-ID swap plus a couple of checks:

Swap the model string to claude-fable-5.
Remove budget_tokens if any remain → use thinking={"type": "adaptive"}.
Strip temperature / top_p / top_k — they 400.
Replace last-assistant-turn prefills with structured outputs (output_config.format) or a system-prompt instruction — prefills 400 on this generation.
Audit for thinking={"type": "disabled"} — it 400s on Fable 5. Omit thinking instead.
Re-tune effort per route — start at high, use xhigh for coding/agentic, reserve max for correctness-critical work.
Set display: "summarized" if you surface reasoning in a UI.

Steering this generation is done through prompting and effort rather than sampling parameters, so the quality of your instructions matters more than ever. If your prompts were tuned years ago for older models, they're probably leaving capability on the table — a structured refresh of prompt engineering fundamentals tends to pay for itself quickly on a model this capable.

A Note on Hype vs. Reality

Two guardrails worth keeping as the launch noise settles:

Fable 5 is the most capable model — not necessarily the default everywhere. In Claude Code, for instance, Opus 4.8 remains a strong default; Fable 5 is the tier you select for the hardest work. "Most capable" and "default" are different claims.
Version hygiene matters. Fable 5 is the current peak, Opus 4.8 is the top of the Opus family, and Opus 4.7 is the previous Opus generation. Anything from the Claude 3.x line (or GPT-4-class / Gemini 2.x models) is outdated and shouldn't be treated as current when you're evaluating tutorials or benchmarks. Always confirm model IDs, limits, and pricing against the official docs, since they shift between releases.

TL;DR Cheat Sheet

For quick reference when you wire Claude Fable 5 into a real codebase:

Model ID: claude-fable-5. Context window 1M tokens, output up to 128K.
Thinking: {"type": "adaptive"} is the only mode. To run without it, omit the parameter — never send {"type": "disabled"} (it returns 400).
Effort: output_config.effort is your main control — xhigh for coding and agents, max when correctness is critical, low/medium for simple or latency-sensitive steps.
Removed (all 400 if sent): temperature, top_p, top_k, budget_tokens, and last-assistant-turn prefills.
Reasoning in your UI: add "display": "summarized" to the thinking config, or the thinking text comes back empty.
Large outputs: stream anything above ~16K max_tokens.
Routing: send the hard reasoning to Fable 5; keep routine and high-volume work on Sonnet 4.6 and Haiku 4.5.

Conclusion

Claude Fable 5 isn't just a bigger Opus — it's a new top tier that reframes how you should think about model routing in 2026. The winning pattern is the same as it's always been, just sharper: use the most capable model where correctness compounds, push everything else down the ladder to cheaper models, and tune effort per route. Master that, and Fable 5 becomes a precision instrument rather than a line item that surprises you on the invoice.

If you want to go from "I read about it" to "I ship with it," the courses linked throughout are part of Cursuri-AI.ro, a Romanian AI-learning platform with deep, hands-on tracks on Claude Code, agent architecture, the Anthropic SDK, context engineering, and model selection — all kept current with the 2026 lineup, Fable 5 included.

Found this useful? Save it, and drop your Fable 5 routing strategy in the comments — what are you sending to the top tier, and what stays on Sonnet?

Claude Code Workflow: Best Practices That Ship Code"

galian — Mon, 08 Jun 2026 08:51:17 +0000

Most posts about Claude Code stop at "install it and say hi." This guide goes further. A reliable Claude Code workflow comes down to a handful of habits that actually ship code: a lean CLAUDE.md, plan mode before any edit, subagents for noisy research, parallel agents in git worktrees, hooks as guardrails, and a verification loop that kills hallucinations. These are the Claude Code best practices worth adopting in 2026 — the opinionated, hands-on version, no fluff.

Quick grounding for anyone new: Claude Code is Anthropic's official agentic coding tool — an AI coding assistant that lives in your terminal. It reads your codebase, edits files, runs commands, and integrates with your dev tools through natural language. It runs in the terminal, in VS Code/Cursor and JetBrains, in a desktop app, on the web at claude.ai/code, and in the Claude iOS app — all sharing the same engine, so your CLAUDE.md, settings, and MCP servers travel with you.

Why most Claude Code workflow advice stops at "install and say hi"

The beginner tutorials get you to a prompt and stop. The "Claude Code vs Cursor" posts argue about UI and never touch cost or parallelism. What nobody connects is the layered setup — the thing that turns a clever autocomplete into a teammate you can delegate to. That layering (memory + skills + hooks + subagents + MCP) plus running several agents at once is where the real productivity lives, and it's exactly what gets fragmented across ten separate posts.

For the structured version of everything below — terminal-first agentic coding, multi-file edits, git, MCP, headless CI/CD, subagents, and the security model — that's the spine of the Claude Code Mastery course on Cursuri-AI.ro (Romanian-language, so plan for that if English is your only language). A few relevant deep-dives are linked along the way.

The right mental model: a teammate you delegate to, not autocomplete

The single biggest mindset shift: stop typing instructions, start describing outcomes. Autocomplete predicts the next token. An agentic tool plans, executes with real dev tools, evaluates the result, and adjusts — a loop, not a guess. Treat it like autocomplete and you'll micromanage every line and get autocomplete-level value.

Describe outcomes, not keystrokes — and let it interview you first

Instead of "open auth.ts, add a function validateToken," describe the goal:

"Add JWT validation to the login flow. Follow our existing error-handling pattern. Write tests and run them."

Then — the part people skip — let it ask questions first. For anything non-trivial, add "ask me anything unclear before you start." A good agent will surface the ambiguity (which token library? refresh tokens?) before writing 200 lines down the wrong road. Treating the prompt like a brief to a competent junior, not a command to a compiler, is genuinely a prompting skill — the same one taught in the Prompt Engineering Masterclass, and it transfers directly to writing a good CLAUDE.md.

The CLAUDE.md that actually gets followed

CLAUDE.md is persistent, per-project (or per-user) memory loaded every session. It's the highest-leverage file in the repo, and the most commonly abused.

Keep it under ~60 lines (and why long files get half-ignored)

The temptation is to dump your entire style guide in there. Don't. A 400-line CLAUDE.md competes with your actual prompt for attention and gets partially ignored. Keep it under ~60 lines as a rule of thumb — not an official limit, but it holds up. Stable rules only: conventions, the "definition of done," and the things that must never be touched.

# CLAUDE.md

## Stack
- Use pnpm, not npm.
- TypeScript strict mode. No `any`.

## Definition of done
- Tests pass (`pnpm test`) before you say it's done.
- No new lint warnings.

## Never touch
- Do not edit files in `/generated`.
- Do not change the public API in `src/api/` without asking.

## Conventions
- API style: see docs/api-style.md.

That's the shape of it: short, declarative, points to longer docs instead of inlining them.

Let Claude update CLAUDE.md after every bug

Here's the habit that compounds. After fixing a non-obvious bug, ask it to record the lesson: "add a one-line rule to CLAUDE.md so this doesn't happen again." Over weeks, the file becomes a distilled record of the project's real gotchas — earned, not guessed. Recent versions also save learnings automatically, but curating the explicit rules by hand keeps the file tight.

Plan mode before code: catch the wrong problem early

Plan mode is a read-only permission mode: Claude investigates and proposes an approach without touching a single file. You cycle into it with Shift+Tab, or start there with --permission-mode plan.

# Start a session in plan mode — read-only until you approve
claude --permission-mode plan

Approve the plan, not the diff — correcting a plan is far cheaper

This is the one to drill into any junior. If the plan is wrong, you fix it in one sentence. If the diff is wrong, you've already paid for 300 lines of edits across five files, and now you're untangling them. Reviewing intent before implementation is where plan mode earns its keep on anything bigger than a one-liner.

Ask for step one, review, then step two

For large features, don't let it run the whole plan unattended. "Do step one, then stop and show me." Review, then "continue." It feels slower; it's faster, because you catch a wrong turn at step one instead of step six.

The layered setup: skills, hooks, subagents, and MCP

This is the part the comparison posts never assemble into one picture. Four mechanisms, each solving a different problem.

Skills as folders with a "gotchas" section

Skills are markdown-based reusable workflows, invoked with /<name> or auto-loaded when relevant. As of 2026 skills and slash commands are unified — a skill is its slash command. Bundled ones include /code-review, /debug, and /batch. Write your own for anything you do more than twice (/deploy, /review-pr), and give every skill a "gotchas" section listing the ways this task usually goes wrong. That section does more for reliability than the happy-path instructions.

Hooks for safety and automation

This is the crucial distinction: instructions in CLAUDE.md and skills are requests, not guarantees. If something must happen, it belongs in a hook. Hooks fire on lifecycle events — PreToolUse, PostToolUse, SessionStart — and can run a shell command, an HTTP request, a prompt, or a subagent. Common uses: auto-format on every file write, run a quick test pass after edits, and block obviously unsafe shell commands before they execute. Guardrails go in hooks; everything else is a polite suggestion.

Subagents for noisy research so your main context stays clean

A subagent runs its own agentic loop in an isolated context window and returns only a summary (spawned via the Task tool). The value is context hygiene: when it needs to read fifteen files to answer "where is rate limiting enforced," a subagent does the digging and hands back a paragraph, instead of flooding the main session with fifteen files no one will look at again. Don't confuse these with agent teams — that's an experimental, disabled-by-default feature where independent sessions message each other and share a task list. Different thing.

If multi-agent orchestration patterns (ReAct, planners, delegation) are the real goal, the AI Agents architecture and automation course covers the theory that Claude Code's subagents put into practice.

MCP: connecting the issue tracker, DB, and browser

MCP (Model Context Protocol) is an open standard for wiring Claude Code to external data and tools — Google Drive, Jira, Slack, databases, browsers. Configure servers with claude mcp or --mcp-config. This is what moves it from "edits files" to "operates your actual workflow": read the design doc in Drive, update the Jira ticket, query the staging DB to confirm a schema. MCP tool search is on by default so all those tools don't blow up your context cost. Pair an MCP connection with a skill that teaches Claude how to use it, and the combination is far better than either alone.

Worth understanding the protocol itself if you build internal tools — Claude Code is a first-class MCP client, and there's a dedicated MCP (Model Context Protocol) course on building the servers it connects to.

Running Claude Code parallel agents with git worktrees

Git worktree isolation is native (--worktree / -w), and it's the single change that most increases throughput. The idea: each agent works in its own checkout of the repo, so two agents never fight over the same files.

One bugfix agent + one feature agent, zero file conflicts

A typical setup: one agent grinding through a flaky-test fix, another building a small feature, each in its own worktree on its own branch. They can't step on each other because they're literally in different directories. You monitor both from the agent view.

The worktree commands and how to merge back

# Spin up an isolated worktree-backed session
claude --worktree

# Or, manage git worktrees yourself and run an agent in each
git worktree add ../app-bugfix   bugfix/flaky-auth-test
git worktree add ../app-feature  feature/csv-export
# then run `claude` inside each directory

# Watch full sessions running in parallel
claude agents

Each lands on its own branch; review the diffs and merge back through normal PRs — same review bar as any human-authored branch, no exceptions.

How many concurrent agents is actually sane

Be honest about the bottleneck: it's your review capacity, not the tool's. Two or three agents are supervisable. Push past that and you're rubber-stamping diffs you didn't really read, which defeats the point. The cap isn't the machine — it's how many parallel changes you can genuinely verify.

Killing hallucinations with an evidence-based verification loop

Agentic tools confidently invent APIs, routes, config keys, and permissions. The fix isn't "be careful," it's a repeatable loop.

"Show me the test output," not "it works"

Never accept "it works." Accept the command it ran and the output it produced. "Run the tests and paste the output." "Show me the curl request and the actual response." An agent that claims a green build but can't show a passing run just hallucinated a green build. Make evidence the default, not a special request.

When it gets confused, stop and ask it to diagnose

If it starts thrashing — two failed corrections in a row — stop asking for fixes and ask for a diagnosis: "Where exactly is this breaking, and what's your evidence?" Forcing it to locate the failure beats letting it patch blindly. Grounding the model in real, verifiable output is core to using any LLM in production reliably — the broader discipline is the subject of Introducere în AI Engineering, which covers evals and reliability alongside the tooling.

Context hygiene: the habit that changes everything

Long sessions degrade. The model's attention spreads thin, old failed attempts pollute the context, and quality quietly drops. Managing context is 80% of getting consistent results.

Clear the session after two failed corrections instead of arguing

The hardest rule to follow: if you've corrected the same thing twice and it's still wrong, don't correct a third time. Clear the session (/clear), re-state the goal cleanly with the lessons learned, and start fresh. Arguing with a confused context is the single biggest time sink there is.

Compact manually around 50% context

Don't wait for auto-compaction. Around half-full, compact the session (/compact) to summarize it and reclaim room, which keeps responses sharp. And when it goes genuinely off the rails, use conversation-rewind to roll back to an earlier point instead of trying to talk it back on course.

The cost math nobody shows you

Here's what comparison posts skip. Two ways to pay: a Claude subscription (Pro, Max, Team, Enterprise) or pay-as-you-go on the Anthropic API. Most surfaces require one of these — Claude Code requires a paid plan, and the desktop app explicitly needs a paid subscription.

Pro vs Max vs API — what to actually weigh

As a snapshot (always confirm current numbers on claude.com/pricing — plan structures shift): Pro is around $20/month, Max is $100/month (5x) or $200/month (20x), and the API is pure per-token. The lever that dominates the bill: output tokens cost ~5x input. On the API, Opus 4.8 lists at $5/MTok input and $25/MTok output; Sonnet 4.6 at $3/$15; Haiku 4.5 at $1/$5. Agentic coding generates a lot of output, so output pricing — not input — is what you feel.

The model default is tier-dependent (a common myth)

There is no single fixed default. It resolves by account type: Max, Team Premium, Enterprise pay-as-you-go, and the Anthropic API default to Opus 4.8; Pro, Team Standard, and Enterprise seats default to Sonnet 4.6. Switch anytime with /model or --model:

# Pick a model by alias or full name
claude --model opus
claude --model claude-sonnet-4-6

# opusplan: Opus to plan, Sonnet to execute
/model opusplan

# 1M-token context variant (Opus and Sonnet only — not Haiku)
/model claude-opus-4-8[1m]

opusplan is a strong default — Opus's reasoning where it matters (planning), Sonnet's speed and lower cost for execution. Two caveats: Sonnet's 1M-token context needs usage credits on every plan (including Max), while Opus 1M is included on Max/Team/Enterprise; and Haiku 4.5 is 200k context, not 1M. If a new model doesn't show up in /model, you're probably on an older build — run claude update and it'll appear.

API vs Max: which actually wins

On the API with heavy daily coding, the bill gets unpredictable enough that a flat Max plan removes the anxiety of watching output tokens tick up mid-refactor. Code with it most days and a flat plan usually wins over metered API billing on raw cost and peace of mind. Use it occasionally, and the API's pay-only-for-what-you-use can be cheaper. Cost-optimizing LLM usage in production — caching, model routing, batching — is a discipline of its own, covered in Integrare Avansată LLM în Aplicații de Producție.

Claude Code vs Cursor — when to reach for each

Not a winner-takes-all. Cursor's IDE-native, inline experience is excellent for tight edit-review-edit loops where you want to stay in the editor. Reach for Claude Code's terminal when you want agentic autonomy — multi-file refactors it drives end to end, headless runs in CI, parallel worktree agents, scripting it into pipelines. And since the VS Code/Cursor extension shares the same engine, it's not strictly either/or: use the extension for inline diffs and the terminal for the heavy autonomous work. Pick by task, not tribe.

Security and team scaling notes

Approval modes, sandboxing, and reviewing AI commits

Permission modes are real guardrails: default, acceptEdits, plan, and bypassPermissions, selectable via --permission-mode and cycled with Shift+Tab. Keep destructive operations behind approval, use hooks to outright block unsafe shell commands, and — non-negotiable — every AI-authored commit goes through the same review as a human's. An agent that can run commands is a powerful tool and a real attack surface; treat its output as untrusted until reviewed.

What changes when more than one person shares the conventions

Once a team shares a repo, CLAUDE.md becomes shared infrastructure: a change to it changes everyone's agent behavior, so it goes through PR review like code. Skills and hooks get version-controlled and packaged as plugins (versioned bundles of skills, subagents, hooks, and MCP servers) distributed through a marketplace, so the whole team runs the same setup. The thing that breaks at scale is uncoordinated worktree agents on the same files — keep agents on separate branches and merge through PRs, exactly as you would with people.

A copy-paste Claude Code workflow starter setup

Drop a CLAUDE.md like the one above in your repo root. Add a couple of hooks (auto-format on PostToolUse, block unsafe commands on PreToolUse). Write one custom slash command for your most repeated task. Then:

# Install the CLI (macOS/Linux/WSL)
curl -fsSL https://claude.ai/install.sh | bash

# Start in your project, in plan mode
cd your-project
claude --permission-mode plan

# Headless mode for scripting and CI
git diff main --name-only | claude -p "review these changed files for security issues"

That's enough to feel the difference the same day.

TL;DR — the 8 habits that matter most

Describe outcomes, not keystrokes — and let it interview you before it starts.
Keep CLAUDE.md under ~60 lines — stable rules only; let it append lessons after bugs.
Plan mode before code — approving a plan is far cheaper than untangling a wrong diff.
Hooks for anything that must happen — CLAUDE.md and skills are requests, not guarantees.
Subagents for noisy research — keep the main context clean.
Parallel agents in git worktrees — capped by your review capacity, ~2-3 in practice.
Demand evidence — "show me the test output," never "it works."
Context hygiene — clear the session after two failed corrections; compact around 50%.

None of this is exotic. It's the boring discipline of treating an agent like a capable teammate: clear briefs, guardrails, evidence, and review. That's the Claude Code workflow that turns agentic coding from a party trick into the thing that clears your queue. For the structured, end-to-end path through all of it, the Claude Code Mastery course walks the same terrain in order — just note it's in Romanian. Either way, adopt the habits above and tune them to your own repo.

Prompt Caching with Claude: How We Cut AI API Costs by 90% in Production (2026 Guide)

galian — Mon, 01 Jun 2026 09:02:05 +0000

TL;DR — Anthropic's prompt caching gives you a 90% discount on cached input tokens and up to 85% lower latency on long-context calls. But the wins only show up if you understand cache breakpoints, TTLs, and what actually invalidates the cache. This guide walks through 5 production patterns we use, real benchmarks, and the pitfalls that silently kill your hit rate.

The cost problem nobody warns you about

When you ship anything serious with Claude — an agent, a RAG system, a code assistant, a customer support bot — you discover the same uncomfortable truth: your input token bill dwarfs your output bill.

A typical agent loop looks like:

System prompt: ~3,000 tokens (instructions, persona, constraints)
Tool definitions: ~4,000 tokens (JSON schemas for 10–20 tools)
Conversation history: 5,000–50,000 tokens (grows every turn)
RAG context: 5,000–20,000 tokens per query
User message: ~200 tokens
Model output: ~500 tokens

Every single turn, you re-send the same system prompt, the same tool definitions, and most of the conversation history. On Claude Sonnet 4.6 at $3 per million input tokens, a 15,000-token prefix sent across 20 conversation turns costs you $0.90 per conversation in input alone — before you've generated a single useful token of output.

Multiply that by 10,000 daily active users and you're burning $9,000/day just to re-tokenize content you already sent.

This is exactly what prompt caching fixes.

What Claude's prompt caching actually does

Anthropic's prompt caching lets the API store the internal state for a prefix of your prompt and reuse it on subsequent requests. Two numbers matter:

Operation	Pricing relative to base input
Cache write (first time a prefix is seen)	1.25× base input cost
Cache read (subsequent hits)	0.10× base input cost (90% off)

You pay a small one-time premium to write the cache, then every hit after that is 10% of the normal price. The break-even point is after the second request — anything more than one read and you're saving money.

The mental model

Think of it as a prefix tree with checkpoints. You mark up to 4 points in your prompt with cache_control, and Claude caches everything from the start of the prompt up to each breakpoint. On the next request, if the prefix matches byte-for-byte, you get a cache hit.

The order Claude processes the prompt is fixed:

tools → system → messages (oldest → newest)

Your cache breakpoints must respect that order. You cannot cache a later block without caching everything before it.

The TTL trap

The default cache TTL is 5 minutes, refreshed on every read. A 1-hour TTL is available as a premium option (costs more on write, same on read). Most teams over-pay for the 1-hour cache when 5 minutes would have served them fine — if your traffic is steady, every request refreshes the TTL and the cache effectively lives forever.

Want to go deeper on Claude's API mechanics in production? Prompt caching, tool use, batch API, streaming, and cost optimization are covered in depth in the Advanced LLM Integration course on Cursuri-AI.ro.

Pattern 1: Cache the system prompt and tool definitions

This is the highest-ROI change you can make, and most codebases get it wrong on the first try.

Wrong (no caching):

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system="You are a senior software engineer. [...3000 tokens of instructions...]",
    tools=[...20 tool definitions, ~4000 tokens...],
    messages=[{"role": "user", "content": "Refactor this function"}],
)

Right (cached):

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are a senior software engineer. [...3000 tokens of instructions...]",
            "cache_control": {"type": "ephemeral"},
        }
    ],
    tools=[
        {
            "name": "read_file",
            "description": "...",
            "input_schema": {...},
        },
        # ... more tools ...
        {
            "name": "last_tool",
            "description": "...",
            "input_schema": {...},
            "cache_control": {"type": "ephemeral"},  # cache breakpoint on the last tool
        },
    ],
    messages=[{"role": "user", "content": "Refactor this function"}],
)

Two things to notice:

cache_control on the system block caches everything up through the system prompt.
cache_control on the last tool caches everything through the tool definitions — this is critical because tools are evaluated before system per the processing order above.

Wait — that's actually wrong as stated. Let me correct: because the order is tools → system → messages, putting cache_control on the last tool caches just the tools, and putting it on system caches tools + system. You typically only need the system breakpoint; it covers everything before it.

Reading the response

The API returns cache stats in response.usage:

print(response.usage.cache_creation_input_tokens)  # tokens written to cache (1.25x cost)
print(response.usage.cache_read_input_tokens)      # tokens read from cache (0.10x cost)
print(response.usage.input_tokens)                 # uncached tokens (1x cost)

On the first request: cache_creation_input_tokens is high, cache_read_input_tokens is 0.
On every subsequent request within 5 minutes: cache_creation_input_tokens is 0, cache_read_input_tokens is high. That's the win condition.

Pattern 2: Cache conversation history with rolling breakpoints

In a multi-turn agent, the conversation grows on every turn. If you only cache the system prompt, you're still re-sending and re-billing every prior turn at full price.

The trick is to add a second cache breakpoint on the most recent assistant message, so the entire conversation up to that point is cached:

def build_messages_with_cache(history, new_user_message):
    """
    history: list of {"role": "user"|"assistant", "content": ...}
    new_user_message: str
    """
    messages = []
    for i, turn in enumerate(history):
        if i == len(history) - 1:
            # Add cache breakpoint on the last historical message
            messages.append({
                "role": turn["role"],
                "content": [
                    {
                        "type": "text",
                        "text": turn["content"],
                        "cache_control": {"type": "ephemeral"},
                    }
                ],
            })
        else:
            messages.append(turn)

    messages.append({"role": "user", "content": new_user_message})
    return messages

Now every new turn reads the entire prior conversation from cache. Cost per turn becomes nearly constant instead of growing linearly with conversation length.

The 4-breakpoint budget

Claude allows up to 4 cache breakpoints per request. A common production layout uses all four:

Breakpoint 1: end of tools
Breakpoint 2: end of system prompt
Breakpoint 3: end of "stable" conversation history (turns 1 through N-2)
Breakpoint 4: end of "recent" history (turn N-1)

This gives you a layered cache: tools rarely change, system rarely changes, old history never changes, recent history is sliding. Each layer hits or misses independently.

Pattern 3: Cache few-shot examples separately from the user query

Few-shot prompting is one of the highest-leverage techniques in production LLM apps — and one of the most expensive if you don't cache. A typical few-shot block with 5–10 examples can run 8,000–15,000 tokens.

FEW_SHOT_EXAMPLES = """
Example 1:
Input: ...
Output: ...

Example 2:
Input: ...
Output: ...

[... 8 more examples ...]
"""

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are a classifier. Categorize support tickets.",
        },
        {
            "type": "text",
            "text": FEW_SHOT_EXAMPLES,
            "cache_control": {"type": "ephemeral"},  # cache the examples
        },
    ],
    messages=[{"role": "user", "content": user_ticket}],
)

Critical rule: put the variable content last. Cache only works on prefix matches. If your user-specific data is in the middle of the prompt, everything after it becomes uncacheable.

Pattern 4: RAG with cached document chunks

RAG systems are notorious for blowing up token bills because the retrieved context is large and unique per query. You can't cache the retrieved chunks themselves (they change), but you can cache the surrounding framework:

def rag_query(user_question, retrieved_chunks):
    return client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": SYSTEM_INSTRUCTIONS,  # ~2000 tokens, stable
                "cache_control": {"type": "ephemeral"},
            }
        ],
        messages=[
            {
                "role": "user",
                "content": (
                    f"Context:\n{retrieved_chunks}\n\n"
                    f"Question: {user_question}"
                ),
            }
        ],
    )

For RAG with a stable knowledge base (corporate docs, product manuals, codebases), there's a more advanced pattern: pre-tile your documents into fixed-size cacheable blocks and choose your retrieval strategy to favor returning whole blocks rather than slices. You trade some retrieval precision for massive cost savings on hot documents.

If you build RAG systems for production, the RAG (Retrieval-Augmented Generation) course on Cursuri-AI.ro covers caching strategies, retrieval optimization, hybrid search, and eval pipelines end-to-end.

Pattern 5: Cache tool results in long-running agents

Agent loops are caching's sweet spot. An agent runs tool_call → tool_result → tool_call → tool_result cycles, and each iteration the prompt grows by the new tool result. Without caching, you re-bill the entire history every iteration.

def agent_loop(initial_user_message, tools):
    messages = [{"role": "user", "content": initial_user_message}]

    while True:
        # Add cache breakpoint to the latest message
        cached_messages = messages[:-1] + [
            add_cache_breakpoint(messages[-1])
        ]

        response = client.messages.create(
            model="claude-sonnet-4-6",
            max_tokens=4096,
            system=[{"type": "text", "text": SYSTEM, "cache_control": {"type": "ephemeral"}}],
            tools=tools,
            messages=cached_messages,
        )

        if response.stop_reason == "end_turn":
            return response

        # Append assistant turn + tool results, loop
        messages.append({"role": "assistant", "content": response.content})
        tool_results = execute_tools(response.content)
        messages.append({"role": "user", "content": tool_results})


def add_cache_breakpoint(message):
    content = message["content"]
    if isinstance(content, str):
        content = [{"type": "text", "text": content}]
    content[-1]["cache_control"] = {"type": "ephemeral"}
    return {**message, "content": content}

In a 15-step agent run with a 4,000-token system prompt and 8,000-token tools, this pattern cuts input cost by ~80–88% versus uncached.

Agent loops, tool design, multi-step planning and cost modeling are the focus of the AI Agents & Automation course on Cursuri-AI.ro — built around the same Claude Agent SDK patterns shown here.

Real benchmarks: before vs after

These numbers are from a production code-review agent running on Claude Sonnet 4.6, averaged over 1,000 conversations of 12 turns each.

Metric	Uncached	Cached	Change
Avg input tokens per turn	18,400	18,400	—
Avg billed input cost per turn	$0.0552	$0.0061	−89%
Avg time-to-first-token	1,840 ms	380 ms	−79%
Avg total cost per 12-turn conversation	$0.66	$0.10	−85%
Cache hit rate (warm)	—	96.3%	—

The latency win surprised us as much as the cost win. Cache reads skip the prompt processing phase entirely, which dominates time-to-first-token for long contexts.

The pitfalls that silently kill your hit rate

These are mistakes we've made or seen in production code reviews.

1. Whitespace and formatting drift

Cache hits require byte-exact prefix matches. If your system prompt is built with f-strings and you add a timestamp, conditional newline, or trailing space, you invalidate the cache:

# BREAKS the cache every minute
system = f"You are a helpful assistant. Current time: {datetime.now()}"

# Works
system = "You are a helpful assistant."
# Pass time as a separate user message field if needed

Audit your prompts for hidden variability: locale-formatted numbers, dict iteration order in older Pythons, tool definitions where field order changes between deploys.

2. Reordering tool definitions

If you generate tool schemas from a dict and the dict iteration order changes between runs, your cache evaporates. Always sort tool definitions before sending:

tools = sorted(generate_tools(), key=lambda t: t["name"])

3. Wrong breakpoint placement

Breakpoints must come after the content you want to cache, not before. The breakpoint marks "cache everything up to here." Putting it on the user message instead of the system prompt is a common rookie mistake.

4. Caching tiny prefixes

There's a minimum cacheable size:

Claude Sonnet & Opus: 1,024 tokens
Claude Haiku: 2,048 tokens

Below the minimum, the cache_control is silently ignored — the API doesn't error, it just doesn't cache. Always check response.usage.cache_creation_input_tokens > 0 on your first request to confirm the cache actually wrote.

5. Ignoring the 5-minute TTL on bursty traffic

If your traffic is bursty — heavy during business hours, dead overnight — the 5-minute cache will expire between sessions and you'll pay the write premium every time. For bursty patterns, either:

Use the 1-hour TTL (more expensive write, same read price)
Or send a small "keep-alive" request every 4 minutes during expected idle windows

6. Mixing cached and uncached models

Cache is model-specific. If your code falls back from Sonnet 4.6 to Haiku 4.5 on rate limit, the Haiku call has no cache history. Either keep fallback paths uncached, or build separate caches per model.

When NOT to use prompt caching

Caching has overhead. Skip it when:

One-shot calls with no shared prefix — single-request classification, one-off summarization. The 1.25× write premium is pure loss.
High-variability prompts — if each request has different boilerplate, you're paying write premium for nothing.
Prompts below the minimum — short prompts can't be cached.
Cost is already negligible — if you spend $20/month on the API, the engineering time to optimize caching costs more than the savings.

A useful heuristic: if your stable prefix is ≥2,000 tokens AND you make ≥3 requests per 5-minute window with that prefix, cache it.

Putting it together: a production checklist

Before you ship a Claude integration in 2026, run this list:

[ ] System prompt has cache_control set
[ ] Tool definitions are sorted and stable
[ ] User-variable content is at the end of the prompt, not in the middle
[ ] Cache stats (cache_read_input_tokens) are logged and dashboarded
[ ] Cache hit rate is monitored — alert if it drops below 80%
[ ] No timestamps, request IDs, or random data injected into cached blocks
[ ] First-request cache write is verified in tests
[ ] Fallback model paths handle cache absence cleanly
[ ] 5-minute vs 1-hour TTL choice is documented with reasoning

Wrapping up

Prompt caching is the single highest-leverage cost optimization for Claude in production. The mechanics are simple, but the gotchas — formatting drift, reorder bugs, minimum sizes, TTL mismatches — are where teams leave money on the table.

If you treat caching as a first-class concern from day one, you ship AI features that are 5–10× cheaper to operate than the naive implementation. If you bolt it on later, you spend weeks chasing cache misses through your logging.

Where to go deeper

I write about production AI engineering — Claude API, multi-agent systems, RAG, cost optimization — on Cursuri-AI.ro, an interactive learning platform with an always-available AI tutor that walks you through every concept and reviews your code. The four courses most relevant to what's in this article:

Advanced LLM Integration — Claude API in production: prompt caching, tool use, batch API, streaming, error handling, retries
Prompt Engineering Masterclass — structured prompting, few-shot patterns, evaluation, prompt versioning
AI Agents & Automation — agent loops, tool design, multi-agent orchestration, cost modeling
RAG (Retrieval-Augmented Generation) — retrieval, embeddings, hybrid search, caching, eval pipelines

Course content is delivered in Romanian (the platform's primary audience), but the code, frameworks, and patterns are language-agnostic — the IT Pro track is built specifically for engineers shipping AI in production.

What's your cache hit rate in production? Drop a comment with your setup — I'm collecting patterns for a follow-up post on caching at the multi-tenant scale (per-customer cache namespaces, cache warm-up strategies, and the cost model when you have 10,000+ concurrent users).

If this helped, a ❤️ or a 🦄 keeps it visible for other devs hitting the same cost wall. Follow for more deep-dives on Claude in production.

Related reading:

Anthropic's official prompt caching docs: docs.anthropic.com
Claude API pricing: anthropic.com/pricing
Full IT Pro AI engineering catalog: Cursuri-AI.ro/courses

AI for Influencers in 2026: How to Build a Content Engine That Runs Itself

galian — Tue, 19 May 2026 13:34:41 +0000

The influencer economy is no longer about who posts the most. It's about who has built the smartest AI content system behind the scenes.

In 2026, the top 1% of creators aren't outworking everyone else. They're out-engineering them. They've turned what used to be a 60-hour-a-week grind into a streamlined pipeline where AI handles 80% of the production work — and they keep 100% of the creative direction.

Over the past two years, working with hundreds of creators and educators through Cursuri-AI.ro — Eastern Europe's leading AI education platform — I've watched this shift happen in real time. The patterns are consistent, the playbook is replicable, and the gap between those who adopt it and those who don't is widening every month.

This article breaks down exactly how it works, what tools they use, and how you can build the same stack — whether you're an influencer who codes, or a developer building tools for creators.

Why AI Changed the Influencer Game (Permanently)

Three years ago, an influencer's competitive advantage was personality plus consistency. Today, that's table stakes.

The real moat now is operational leverage:

How fast can you identify a trending topic?
How quickly can you produce content across 5+ formats?
How precisely can you target each piece to its platform?
How much of this can run without your direct involvement?

The creators who answered "all of it, mostly automated" are the ones scaling past 1M followers, 7-figure revenues, and 50+ pieces of content per week — solo or with tiny teams.

This isn't theoretical. It's already happening. The question is whether you're building the system or watching others build it.

The 5-Layer AI Stack for Modern Influencers

Every high-output creator I've analyzed runs some version of this five-layer architecture. The tools change. The structure doesn't.

Layer 1: Intelligence (Research & Trend Detection)

Before you create, you need to know what to create.

What it does:

Monitors trending topics, keywords, and conversations in your niche
Analyzes competitor content performance
Identifies content gaps and opportunities
Surfaces audience questions before they become saturated

Tools and APIs:

Perplexity API — for real-time research with citations
Exa AI — semantic search for niche topics
Google Trends API + YouTube Data API — for trend signals
Reddit API + Twitter/X API — for audience listening
BuzzSumo or SparkToro — for content gap analysis

Pro tip: Don't just track what's popular. Track what's about to become popular by monitoring signal velocity (rate of change), not absolute volume.

Layer 2: Ideation (Concept & Angle Generation)

This is where most creators waste the most time — staring at a blank page deciding what to make.

What AI does well here:

Generates 30+ angle variations from a single topic
Adapts ideas to your specific voice and audience
Identifies counterintuitive takes that drive engagement
Maps ideas to platform-specific formats

Recommended approach:

Build a custom GPT or Claude project trained on:

Your past top-performing content (with metrics)
Your audience persona and voice guidelines
Your content pillars and forbidden topics

💡 If you've never structured a voice profile before, this is one of the highest-leverage skills you can develop. We dedicate an entire module to it inside our AI for Content Creators track on Cursuri-AI.ro — including the exact prompts and templates we use internally.

Then prompt it like this:

from anthropic import Anthropic

client = Anthropic()

def generate_content_angles(topic: str, voice_profile: str, n: int = 20):
    response = client.messages.create(
        model="claude-opus-4-7",
        max_tokens=4000,
        system=f"""You are a content strategist for an influencer with this profile:
        {voice_profile}

        Generate angles that are specific, counterintuitive, and aligned with their voice.
        Avoid generic takes. Each angle should be testable as a hook.""",
        messages=[{
            "role": "user",
            "content": f"Give me {n} distinct angles for content about: {topic}"
        }]
    )
    return response.content[0].text

angles = generate_content_angles(
    topic="building a personal brand in 2026",
    voice_profile="Direct, data-driven, contrarian, B2B-focused",
    n=25
)
print(angles)

The output of this single function call can fuel a month of content. Cost: ~$0.15.

Layer 3: Production (Multi-Format Content Generation)

This is the heaviest-lifting layer — and where AI compounds value most.

The repurposing principle:

One "pillar" piece (a long-form video, podcast, or article) should generate 10–15 derivative pieces with minimal manual work.

Sample workflow for a 30-minute podcast episode:

Transcription → Whisper API or AssemblyAI ($0.36 for 30 min)
Long-form blog post → Claude/GPT generates structured article from transcript
LinkedIn carousel → 8–10 slide deck with key insights
Twitter/X thread → 10-tweet thread with the strongest takes
Short-form clips → Opus Clip or Riverside AI extracts viral moments
Newsletter → Personalized summary with commentary
YouTube Shorts → Auto-captioned vertical clips
Quote graphics → Designed via Canva API or Bannerbear
Instagram Reels → Repurposed clips with platform-native captions
SEO blog series → 3–5 articles targeting specific search queries

Total human time: 1–2 hours of review and approval, instead of 30+ hours of production.

Layer 4: Distribution (Platform-Native Publishing)

Most creators lose performance here by posting the same content identically across platforms. AI fixes this by adapting each piece to the platform's native expectations.

Adaptive distribution looks like:

LinkedIn → Professional tone, longer-form, hook in first 2 lines
Twitter/X → Punchy, opinionated, thread-friendly
Instagram → Visual-first, emotion-driven captions
TikTok → Hook in 1 second, vertical, trend-aware
YouTube → SEO-optimized titles, timestamps, structured descriptions

Tools:

Buffer, Hypefury, or Typefully — scheduling with AI optimization
Make or n8n — custom automation workflows
Postiz (open source) — self-hosted social scheduling

Layer 5: Optimization (Performance Feedback Loop)

This is the layer most creators skip — and it's the one that compounds the hardest.

What to track:

Hook performance (which first lines drive scroll-stops?)
Format performance (which content types convert best per platform?)
Topic performance (which themes consistently win?)
Audience signals (which content brings in your ICP vs. tourists?)

How AI helps:

Analyzes patterns across hundreds of posts in seconds
Identifies non-obvious performance correlations
Suggests next-week content based on last week's winners
Drafts variations of top performers for retesting

Build a simple dashboard that ingests your analytics from each platform and feeds it back to your ideation layer. This closes the loop — every post makes the next one smarter.

A Minimal Working Example: Content Repurposing Pipeline

Here's a stripped-down Python pipeline that takes a transcript and produces three platform-adapted outputs. Useful as a starting point you can extend.

import os
import json
from anthropic import Anthropic

client = Anthropic()
MODEL = "claude-opus-4-7"

def repurpose_content(transcript: str, voice: str) -> dict:
    """Generate LinkedIn post, Twitter thread, and newsletter from a transcript."""

    prompt = f"""You are an expert content strategist. The creator's voice is: {voice}

    From the transcript below, produce THREE outputs in JSON:
    1. "linkedin": A 200-word LinkedIn post with strong hook
    2. "twitter_thread": A 8-tweet thread (array of strings, max 280 chars each)
    3. "newsletter": A 400-word personal newsletter section

    Each must feel platform-native, not copy-pasted.

    Transcript:
    {transcript}

    Return only valid JSON."""

    response = client.messages.create(
        model=MODEL,
        max_tokens=4000,
        messages=[{"role": "user", "content": prompt}]
    )

    return json.loads(response.content[0].text)


if __name__ == "__main__":
    sample_transcript = """[Your podcast/video transcript here]"""
    voice = "Direct, contrarian, B2B-focused, data-driven"

    outputs = repurpose_content(sample_transcript, voice)

    print("=== LINKEDIN ===")
    print(outputs["linkedin"])
    print("\n=== TWITTER THREAD ===")
    for i, tweet in enumerate(outputs["twitter_thread"], 1):
        print(f"{i}/ {tweet}")
    print("\n=== NEWSLETTER ===")
    print(outputs["newsletter"])

Extend this with:

Whisper for audio-to-text input
A queue system (Redis + Celery) for batch processing
A simple Streamlit UI for non-technical creator team members
Webhook integration with Buffer or Typefully for direct publishing

The 5 Mistakes That Kill AI Content Pipelines

I've audited dozens of creator AI workflows. The same mistakes appear over and over.

1. Treating AI as a Writer Instead of a Drafter

AI-generated text published without human editing is detectable, generic, and erodes trust. Use AI for the first 80%, but always edit the final 20% — that's where your voice lives.

2. Skipping the Voice Calibration Step

Without a documented voice profile (tone, vocabulary, forbidden phrases, examples), every output regresses to the mean. Spend 4 hours documenting your voice once. It pays back for years. If you want a structured framework for this, we walk through the full process in our AI workflow courses.

3. Building Without Measurement

Pipelines without analytics are vibes-based content factories. If you can't tell which output formats win, you're optimizing blind.

4. Over-Automating Distribution

Full automation of posting (no human in the loop) is how creators end up with embarrassing posts going live during global news events. Keep a 1-click approval step at minimum.

5. Choosing Tools Over Architecture

The creators who win don't have the best tools. They have the clearest workflow. Tools change every quarter. Architecture compounds.

What's Coming Next (2026–2027)

A few signals worth watching:

Personalized AI clones — creators training models on their voice/likeness to scale 1:1 audience interaction
Multimodal generation at scale — single prompts producing full video, audio, and graphics in one pass
AI-native platforms — new social networks built around AI-generated content as a first-class citizen
Agent-driven content ops — autonomous agents that research, produce, schedule, and optimize with minimal human input

The creators preparing for this now — by building modular, API-driven systems — will be the ones operating at unprecedented scale by 2027.

FAQ: AI for Influencers

Q: Do I need to code to use AI as an influencer?

No. Many top creators use no-code tools (Zapier, Make, ChatGPT, Claude Projects). But knowing even basic Python unlocks 10x more customization.

Q: Will AI-generated content hurt my reach?

Only if it sounds generic. Platforms penalize low-effort content, not AI assistance. Original voice + AI scaffolding consistently outperforms 100% human or 100% AI.

Q: How much should I budget for AI tools?

A solo creator can build a complete stack for $50–150/month. Larger operations run $500–2000/month. ROI is usually measured in weeks, not months.

Q: Is this ethical? Should I disclose AI usage?

Be transparent about what AI does in your workflow (research, drafting, editing), but you don't need to flag every AI-touched word. The standard: would your audience feel deceived if they saw your process? If no, you're fine.

Q: Which AI model should I use as a creator?

For creative content: Claude tends to lead. For research with citations: Perplexity. For images: Midjourney or Flux. For video: Runway or Sora. Test all of them — they each have strengths.

Conclusion: Build the System, Not the Output

The influencer economy is splitting into two clear tiers.

The first tier still manually crafts every piece of content. They post when they have time. They burn out. They plateau.

The second tier has built systems. AI handles the heavy lifting. They post consistently across every platform. Their content compounds because their architecture compounds.

The gap between these two tiers is widening every month. And by 2027, it will be unbridgeable for those who waited too long to start.

The good news: building your AI content engine doesn't require a team or a six-figure budget. It requires clear thinking, a few APIs, and the willingness to treat content like the engineering problem it actually is.

Start with one layer. Make it work. Add the next.

That's how the top 1% built it. And it's how you build it too.

Want to Go Deeper?

If this resonated and you want a structured path instead of piecing it together from scattered blog posts and YouTube videos:

🎓 Cursuri-AI.ro — Our complete AI education platform covers the entire creator stack: prompting, automation, content pipelines, AI workflows for business, and how to build production-grade AI systems. Interactive courses with an AI tutor that adapts to how you learn — not passive video watching.

Whether you're a creator looking to scale, a developer building tools for the creator economy, or a business owner figuring out how to integrate AI into your operations — start here.

About the Author

I'm the founder of Cursuri-AI.ro, where I help thousands of creators, professionals, and businesses build with AI. I write about AI workflows, content automation, and the engineering side of the creator economy.

If this article helped, drop a reaction and follow for more deep dives. What layer of your content stack are you working on right now? Let me know in the comments — I read every one.

7 Production Patterns for AI Agents That Don't Break in 2026

galian — Wed, 13 May 2026 11:38:37 +0000

A demo agent that loops three times, calls one tool, and returns "Hello, I helped you" is easy. A production agent that handles 10k requests a day across paying customers, without lighting your API bill on fire or hallucinating tool arguments at 3am, is a different animal.

I've shipped AI agents in production for the last 18 months — search, content generation, support triage, document analysis. The same seven patterns keep showing up in every codebase that actually works. None of them are exotic. Most of them are boring. That's the point: production agents are boring on purpose.

Here are the patterns, with Python examples you can drop into your own loop today.

1. The Tool Result Validator

Problem: LLMs hallucinate tool arguments. They will confidently call send_email(to="user@example.com", subject="Refund", body="...") when the user never asked for an email. They will pass user_id="123abc" to a function that requires an integer. They will invent product SKUs that don't exist.

If your tool layer trusts the model's output, every hallucination becomes a production incident.

Pattern: Validate tool arguments at the tool boundary, not inside the tool. Reject early with a structured error the model can recover from.

from pydantic import BaseModel, ValidationError

class SendEmailArgs(BaseModel):
    to: str
    subject: str
    body: str
    requires_user_confirmation: bool = True

def execute_tool(name: str, raw_args: dict) -> dict:
    schema = TOOL_SCHEMAS[name]
    try:
        args = schema.model_validate(raw_args)
    except ValidationError as e:
        return {
            "status": "error",
            "error_type": "invalid_arguments",
            "message": f"Tool call rejected. Fix these fields: {e.errors()}",
        }

    if name == "send_email" and args.requires_user_confirmation:
        return {"status": "pending_confirmation", "preview": args.model_dump()}

    return TOOLS[name](args)

Gotcha: Always return the validation error back to the model as a tool result. Don't raise it. The agent can usually self-correct in the next turn — but only if it sees the error.

2. Bounded Memory

Problem: Naive agent loops accumulate every tool call, every observation, every reasoning step into the conversation history. After 15 turns, you're sending 80k tokens per request. Your latency doubles. Your cost goes up 10x. The model starts losing track of what it was doing because the relevant context is buried under five tool dumps.

Pattern: Treat conversation history as a finite resource. Compress aggressively, summarize old turns, and keep tool outputs out of the main thread when you can.

class BoundedMemory:
    def __init__(self, max_tokens: int = 32_000, summarize_at: int = 24_000):
        self.messages: list[dict] = []
        self.max_tokens = max_tokens
        self.summarize_at = summarize_at

    def add(self, message: dict) -> None:
        self.messages.append(message)
        if self._token_count() > self.summarize_at:
            self._compress()

    def _compress(self) -> None:
        # Keep system message + last 4 turns verbatim
        keep_recent = self.messages[-8:]
        to_summarize = self.messages[1:-8]
        if not to_summarize:
            return
        summary = summarize_with_llm(to_summarize, max_tokens=2_000)
        self.messages = (
            [self.messages[0]]
            + [{"role": "user", "content": f"<earlier_context>{summary}</earlier_context>"}]
            + keep_recent
        )

Gotcha: Don't summarize tool call messages — the model needs the exact arguments to chain reasoning. Summarize only the observations, and only when they're old enough that detail no longer matters.

3. The Observable Loop

Problem: Your agent is in production. A user complains it gave them garbage. You have... a final string output and a vague memory of what the loop does. Good luck debugging.

Pattern: Emit a structured event for every state transition in the loop. Every model call, every tool call, every retry, every error. Ship them to whatever observability stack you already use (Datadog, Honeycomb, OpenTelemetry, even just structured JSON to stdout).

import time
import uuid
from contextlib import contextmanager

@contextmanager
def trace_step(run_id: str, step: str, **attrs):
    span_id = str(uuid.uuid4())
    start = time.perf_counter()
    log_event("step.start", run_id=run_id, span_id=span_id, step=step, **attrs)
    try:
        yield span_id
        log_event("step.end", run_id=run_id, span_id=span_id, step=step,
                  status="ok", duration_ms=(time.perf_counter() - start) * 1000)
    except Exception as e:
        log_event("step.end", run_id=run_id, span_id=span_id, step=step,
                  status="error", error=str(e),
                  duration_ms=(time.perf_counter() - start) * 1000)
        raise

def run_agent(task: str) -> str:
    run_id = str(uuid.uuid4())
    memory = BoundedMemory()
    memory.add({"role": "user", "content": task})

    for turn in range(MAX_TURNS):
        with trace_step(run_id, "model_call", turn=turn):
            response = call_model(memory.messages)
        memory.add(response)

        if not response.tool_calls:
            return response.content

        for call in response.tool_calls:
            with trace_step(run_id, "tool_call", tool=call.name, turn=turn):
                result = execute_tool(call.name, call.arguments)
            memory.add({"role": "tool", "tool_call_id": call.id, "content": result})

    return "Max turns exceeded"

Gotcha: Include a stable run_id on every event. When a customer reports an issue, you want one query that returns the entire trace.

4. Graceful Degradation

Problem: Your agent depends on three external services and a vector store. One of them is having a bad day. Your agent now returns a 500 to the user, even though for this particular query the broken dependency wasn't actually needed.

Pattern: Wrap dependencies in fallback chains. If the primary fails, the agent should know that capability is degraded — not crash.

class ToolRegistry:
    def __init__(self):
        self.tools: dict[str, list[Callable]] = {}
        self.health: dict[str, bool] = {}

    def register(self, name: str, *implementations: Callable) -> None:
        self.tools[name] = list(implementations)

    def call(self, name: str, args: dict) -> dict:
        for i, impl in enumerate(self.tools[name]):
            try:
                result = impl(args)
                self.health[f"{name}:{i}"] = True
                return {"status": "ok", "result": result, "tier": i}
            except Exception as e:
                self.health[f"{name}:{i}"] = False
                log_event("tool.fallback", tool=name, tier=i, error=str(e))
                continue
        return {
            "status": "degraded",
            "message": f"Tool '{name}' is unavailable. Try a different approach.",
        }

The crucial bit is the degraded response — it goes back to the model as a tool result, and a well-prompted agent will re-plan. Maybe it tries a different tool. Maybe it tells the user "I can't check live inventory right now, but here's what I know." Either is better than a 500.

Gotcha: Surface the degraded status in your prompt. A line like "If a tool returns status=degraded, do not retry it. Acknowledge the limitation in your final response." prevents the model from looping on a dead service.

5. The Cost Circuit Breaker

Problem: A bug or an adversarial input puts your agent in a tool-calling loop. By the time you notice, you've spent $400 in 20 minutes.

Pattern: Track cumulative cost per run and per session. Hard-stop when limits are exceeded. This is not optional in production — it's the difference between a bad day and a layoff conversation.

class CostBudget:
    def __init__(self, max_usd_per_run: float = 0.50, max_usd_per_user_per_day: float = 5.00):
        self.run_cost = 0.0
        self.max_run = max_usd_per_run
        self.max_day = max_usd_per_user_per_day

    def charge(self, usage: dict, model: str) -> None:
        cost = compute_cost(usage, model)
        self.run_cost += cost
        if self.run_cost > self.max_run:
            raise BudgetExceeded(f"Run exceeded ${self.max_run}")

    def precheck_user(self, user_id: str) -> None:
        spent_today = redis.get(f"cost:{user_id}:{today()}") or 0
        if float(spent_today) > self.max_day:
            raise BudgetExceeded(f"User {user_id} exceeded daily budget")

Gotcha: Different limits for different surfaces. An internal batch job can have a $5 ceiling per run. A free-tier chat user gets $0.10. A paying enterprise customer gets $2. Hardcoding one number is a footgun.

6. The Deterministic Critic

Problem: "LLM-as-a-judge" sounds clever, but using a model to grade itself is unreliable and slow. Two model calls per output, both hallucinate, both cost money.

Pattern: For checks you can express as code, use code. Reserve LLM grading for genuinely subjective dimensions, and only after the deterministic checks pass.

class OutputCritic:
    def evaluate(self, output: str, context: dict) -> dict:
        issues = []

        if context.get("must_cite_sources") and not re.search(r"\[\d+\]", output):
            issues.append("missing_citations")

        if context.get("max_length") and len(output) > context["max_length"]:
            issues.append("too_long")

        if BANNED_PHRASES.search(output):
            issues.append("banned_phrase")

        if context.get("must_mention"):
            missing = [k for k in context["must_mention"] if k.lower() not in output.lower()]
            if missing:
                issues.append(f"missing_keywords:{missing}")

        if issues:
            return {"verdict": "reject", "issues": issues, "method": "deterministic"}

        if context.get("subjective_check"):
            return llm_grade(output, context["subjective_check"])

        return {"verdict": "accept", "method": "deterministic"}

When the critic rejects, feed the issues back to the agent as a "revise this" instruction. After two rejections, return whatever you have with a flag — infinite revision loops are their own bug class.

Gotcha: Don't make the critic too strict. If your accept rate is below 70%, your prompt is broken, not your output.

7. Stateless Replay (Idempotency)

Problem: Your agent half-completed a task — it sent the email, then crashed before logging the result. The user retries. Now they get two emails.

Pattern: Treat every external side-effect as idempotent by design. Use deterministic IDs derived from the input, dedupe at the tool layer, and make agent runs replayable from any saved checkpoint.

import hashlib
import json

def idempotency_key(tool_name: str, args: dict) -> str:
    canonical = json.dumps({"tool": tool_name, "args": args}, sort_keys=True)
    return hashlib.sha256(canonical.encode()).hexdigest()[:16]

def execute_tool_idempotent(name: str, args: dict, run_id: str) -> dict:
    key = idempotency_key(name, args)
    cache_key = f"tool_result:{run_id}:{key}"
    cached = redis.get(cache_key)
    if cached:
        return json.loads(cached)

    result = TOOLS[name](args)
    redis.setex(cache_key, 3600, json.dumps(result))
    return result

Now if the agent retries the same step within the run, it gets the cached result. If you persist the cache across runs (with a longer TTL), you get cross-run idempotency too — which is what you want for anything that costs money or sends messages.

Gotcha: Be careful what you put in the idempotency key. Timestamps, request IDs, or random nonces in the args will defeat it. Strip them before hashing.

Putting It Together

A production agent loop using all seven patterns is roughly 200 lines of Python. Not glamorous, but it survives. Here's the skeleton:

def run_agent_production(task: str, user_id: str) -> str:
    run_id = str(uuid.uuid4())
    budget = CostBudget()
    budget.precheck_user(user_id)

    memory = BoundedMemory(max_tokens=32_000)
    memory.add({"role": "system", "content": SYSTEM_PROMPT})
    memory.add({"role": "user", "content": task})

    critic = OutputCritic()

    for turn in range(MAX_TURNS):
        with trace_step(run_id, "model_call", turn=turn) as span:
            response = call_model(memory.messages)
            budget.charge(response.usage, response.model)

        memory.add(response.message)

        if not response.tool_calls:
            verdict = critic.evaluate(response.content, task_context())
            if verdict["verdict"] == "accept":
                return response.content
            memory.add({"role": "user", "content": f"Revise: {verdict['issues']}"})
            continue

        for call in response.tool_calls:
            with trace_step(run_id, "tool_call", tool=call.name, turn=turn):
                args = call.arguments
                result = execute_tool_idempotent(call.name, args, run_id)
            memory.add({"role": "tool", "tool_call_id": call.id, "content": result})

    return "Task incomplete after max turns"

That's the loop. Drop in your favorite model API (Claude, GPT, open source — patterns work the same), wire up your tools with the validator from pattern 1, and you have something that won't embarrass you in production.

What I'd Read Next

Anthropic's "Building effective agents" guide — the canonical reference on when to use agents vs simple workflows.
OpenAI's Agents SDK docs — clean reference implementation of multi-agent handoffs.
For Romanian-speaking developers building agents in production, the AI Agents course on Cursuri-AI.ro goes deeper on these patterns with hands-on exercises.

If you've shipped agents in production, what patterns did I miss? Drop them in the comments — I'll add the best ones to a follow-up post.

Written by a developer who has paged themselves at 3am because an agent went into a tool-calling loop. Don't be that developer. Use the circuit breaker.

DEV Community: galian

Claude Sonnet 5 Just Made Running Agents Cheap — What Builders Actually Need to Know

The one-sentence version

What's actually new

The economics shift is the real story

The tokenizer gotcha that will mess up your cost math

When to still reach for Opus 4.8

A pragmatic migration checklist

Frequently asked questions

Is Claude Sonnet 5 better than Opus 4.8?

How much does Claude Sonnet 5 cost?

Does the new tokenizer really change my costs?

Can I use Sonnet 5 in Claude Code?

Should I migrate my agents to Sonnet 5 immediately?

The skill underneath the model

Conclusion

Cursor vs GitHub Copilot vs Claude Code: Which AI Coding Tool in 2026?

TL;DR — three different philosophies

What is Cursor?

What is GitHub Copilot?

What is Claude Code?

Head-to-head: the dimensions that actually matter

The editing model

Agents and autonomy

Ecosystem and integration

Models

Pricing, side by side (mid-2026 snapshot)

So which one should you choose?

The skill underneath the tools

Conclusion

Kiro: A Practical Guide to AWS's Spec-Driven Agentic IDE"

What is Kiro?

Spec-driven development: the core idea

1. Requirements

2. Design

3. Tasks

Agent hooks: automation that runs itself

Steering files: stop repeating yourself

MCP and agentic chat

Your first hour with Kiro

Kiro vs. vibe coding

How Kiro compares to other agentic tools

Pricing

When Kiro is worth it — and when it isn't

Want to go deeper?

Conclusion

Stop Vibe-Checking Your LLM: A Developer's Guide to Evals

Why you can't just assert output == expected

Start with the eval set, not the metric

The two halves of every LLM eval

Code-based checks: cheaper and more reliable than you think

LLM-as-judge: powerful, biased, and fixable

Wire it into CI, or it won't survive contact with deadlines

Five mistakes that quietly poison your evals

How this connects to the rest of your LLM stack

Conclusion

How Click Fraud Works — and How to Detect Bot Clicks in Real Time

First, the vocabulary: invalid traffic vs. click fraud

Why the platforms don't fully solve this for you

Why sophisticated click fraud is so hard to catch

Why "just block the IP" doesn't scale

Turning detection into protection

How much is this worth to you?

Try it on your own campaigns

Model Context Protocol Explained: Build Your First MCP Server in Python

What problem MCP actually solves

The architecture: host, client, server

The three primitives you'll actually use

Tools — model-controlled

Resources — application-controlled

Prompts — user-controlled

Build your first MCP server in Python

Setup

The server

Inspect it before wiring it to a model

Connect it to a host

From toy to production: what the quickstart doesn't tell you

Why this matters for how you build in 2026

Conclusion

Anthropic disables access to Fable 5 and Mythos 5 to comply with government directive

Why you can't just `assert output == expected`