Running Claude Code on max effort for every task? You're paying for verification you don't need, and waiting longer for it. Anthropic engineer Thariq Shihipar tested effort levels on real builds and on Terminal-Bench 3.0. His rule of thumb: Low → quick, in-the-loop work: brainstorming, sketches, easy changes Medium → most everyday engineering, like new features High → when edge cases and verification matter, like fixing a bug in an older codebase Max → when Claude should work fully on its own: end-to-end builds, hunting security bugs What higher effort actually buys you: more testing, more edge cases, more decisions made on its own. What it doesn't buy you: higher effort reduced failures from missed edge cases. It did not fix failures where Claude took the wrong approach. His loop for new features: 1. Give Claude a spec and let it interview you for the gaps 2. Build on low/medium effort 3. Review, and iterate on low/medium 4. Verify and test on high Switch anytime with /effort, even mid-conversation. On the newest models, changing effort doesn't break the prompt cache. The 3 prompts for his loop: Interview (low effort): "Here's my spec. Before writing any code, interview me about anything missing or ambiguous, one question at a time. When we're done, write the final spec to SPEC.md." Build (low effort): "Implement SPEC.md. Keep it simple. Don't add anything the spec doesn't ask for." Verify (high effort): "Review the implementation against SPEC.md like a strict reviewer. List the edge cases, write tests for them, run them, and report every failure before fixing anything. You can use medium effort using Opus 5.5 for Interview and Build , and verify using high effort.

Running Claude Code on max effort for every task? You might be paying 3x for answers you didn't need. An Anthropic engineer, Thariq Shihipar, put Claude Code's /effort settings to the test. The results changed how I think about AI coding costs. What higher effort actually does: → Claude verifies more → Tests more edge cases → Makes more decisions on its own What it costs: → Roughly 3x the tokens per attempt (highest vs. lowest setting, Terminal-Bench 3.0) Where it paid off: - Security: 64% → 87% - Hardware: 34% → 75% - Rulebook work (operations filings): 12% → 22% The pattern: effort pays off when there's real complexity to verify. And the line that stuck with me: More effort never fixed a wrong approach. So his workflow is "build low, verify high": 1- Start with a spec, and let Claude interview you for the gaps 2- Build on low effort while it's still easy to steer 3- Keep iterations light while you figure out the shape 4- Turn effort up for testing, once the direction is right Bonus: Opus 5.5 at medium effort reportedly outscores Fable 5.1 at max effort on Terminal-Bench 4, at $2.94 per run instead of $20. Multiply that across a team, and your effort setting becomes a budget decision. The full framework and a cheat sheet are in the carousel. Save it for your next session. What's your default effort level, and has it ever surprised you?

Your AI agent can delete files, run up a huge API bill, or tell you "done" when it isn't. So who's supposed to stop it? Most off-the-shelf agents hide their limits in default settings your team never chose. A harness moves those decisions into code you own. ML researcher Elvis Saravia just published a walkthrough that builds one with the Pi SDK and the Jev decision model. It has 6 parts: Guard the tools: check every call before it runs Set rules you can change: allow, block, or ask a person Route by difficulty: a cheap model for easy work, a strong one for hard work Plan for silence: if the checker doesn't respond, block tool calls Check the answer: compare the reply with the files the agent actually read Keep a record: log every decision and the numbers behind it The result: your agent's limits, model choices and human handoffs are all readable in code. This is what client work needs. Clients don't trust "the AI is smart." They trust limits they can see. The full breakdown, with an example rule function, is in the carousel. Which of the 6 is your agent missing right now?

A startup just deleted more than 800,000 lines of unit tests. On purpose. The founder of an AI observability startup argues that now that coding agents write so much of the code, unit tests can do more harm than good: → They lock in bad AI-generated code → They create "busy work" for agents → They slow down CI pipelines → They drive up token bills A Coinbase engineer agreed: lean on full end-to-end, integration, and golden tests instead. Not everyone is convinced. Veteran engineer Bob Martin ("Uncle Bob") says he still relies on unit tests to keep his agents honest. Here's how I see it: Unit tests written by agents, for code written by agents, can turn into the AI grading its own homework. But tests that capture real business rules are the guardrails that stop an agent from "fixing" your code into the wrong shape. So maybe the question isn't "delete or keep?" It's "which tests protect behavior, and which only protect implementation details?" Where do you stand? A) Delete most of them and test behavior end-to-end B) Keep them, because they're the agent's guardrails

On October 1, Cloudflare, Perplexity and Amazon all released "decision models." These are models that don't write a single word. You give them some input and a fixed set of options. They return a probability for each one. There's no free text to parse and no reasoning tokens to wait for, just a structured answer your code can act on right away. Why this matters if you build AI agents: Most of what an agent does isn't hard reasoning. It's a long string of small decisions: → Which tool should I call? → Is this ticket urgent, and who owns it? → Should this action go ahead or wait for a human? → Is this request in scope? Today many of us send those decisions to a large LLM and parse its reply. That's slow and expensive, and the answer doesn't tell you how sure the model is. Decision models flip that. They're fast and cheap, and they give you a confidence score you can set thresholds on. For example, you could escalate when P(critical) > 0.35 and auto-reply when needs_human < 0.35. Most of what an AI agent does is small, routine decisions. These models are built to make those calls quickly and cheaply, so the LLM can save its effort for the hard thinking.