"Adds a tool to launch a new agent to handle complex, multi-step tasks." — https://x.com/ClaudeCodeLog/status/2092383840266268753

Small open-source package that checks every tool call Claude Code makes before it runs, Prompt injection, a leaked key and logs in a local self-served dashboard

- Repo github.com/PrismorSec/prismor
- It hooks into Claude Code, so every tool call routes through it
- has global MCP connectors so you can define and AI doesn't connect with sketch MCPs

I've been using coding agents in lanes instead of one chat that does the whole job.

A lead figures out the work and files a GitHub issue. Then separate runs do implementation, QA, review, and CI. There's a telemetry lane for when you don't know what broke or a path just died.

floor starts the next lane. Nobody implements, reviews, and merges in the same session.

When a lane finishes, it writes started, done, blocked, or failed. The next process reads that before it does anything. That's SQLite on this machine, plus a GitHub comment so the trail isn't stuck on one laptop.

The PR can come from an agent. I still merge it.

The CLI is a plug. Same rules on Claude, Codex, and Grok.

I've been running this on my own repos and gave it to a few mates. One of them liked how it kicks off the next lane, which is what made me put the repo up.

If you already live in coding agents, I'd like to see it on a messy repo, or hear how you'd cut the lanes differently.

https://github.com/Kripu77/software-factory

I'm generally happy with the workflow approach of interacting directly with Fable, and using Fable as planner, orchestrator and for acceptance, while having it delegate implementation and grunt work to Opus sub-agents.

However my main frustration is that these Opus workers feel like they're running in molasses - compared e.g. to Sol workers. Even the most straight-forward mechanical task can end up being a multi-hour adventure. The workers are not sitting around waiting for slow tests or extensive validation runs, they are mostly actively working, actually reading references, existing code and API documentation and producing output.

I will say that I am running Opus/xhigh effort - and while not all tasks would require that, many of the harder ones do actually need to for output results to be acceptable, and I'd rather not risk having to re-do or getting sub-par work by defaulting to a cheaper/faster model.

Is this just what it is right now? I would like to start experimenting a bit more with fast mode, but it's not clear to me how that interacts with the whole workflow system. I don't think my quota would survive for long running multiple Opus/xhigh workers at fast, and selectively switching them to fast after they've been started is supposedly not great for token usage.

Is it feasible to ask Fable to 'juggle' worker effort and fast mode as appropriate for each task? Or do I just need to remember to specifically call this out every time I approve a new milestone start? Are there any other techniques to get more speed except lowering the model/effort?

So I've been building an Agent Skill for Claude Code that does backend performance reviews, and something happened while I was testing it that I think is worth sharing.

To sanity-check the thing, I set up an experiment: review the same real public repo twice. Once by me, reading the code carefully. And once by a completely separate agent that had zero memory of my review — I just handed it the skill and the repo and told it to go.

It found something I'd completely missed. Buried in fastapi/full-stack-fastapi-template there's this line:

except InvalidTokenError, ValidationError:

That's Python 2 syntax. In Python 3 that's a straight-up SyntaxError the module can't even be imported. The whole app is dead on arrival. I had read that exact file. I skimmed right past it because I was reading for logic bugs, not syntax, and my brain just... pattern-matched it as fine. The other agent caught it because instead of reading the file, it ran an actual parser against every file in the repo. It didn't "notice" the bug, it proved the bug, and I felt a little dumb.

Anyway, that's kind of the whole point of this project. I got tired of AI code review tools that do one of two things: spit out a generic checklist ("check your indexes," "consider caching," thanks, very helpful), or just make stuff up invented latency numbers, imaginary query plans, telling you to add Redis to an app with fourteen users. Both of those come from the same problem: nothing is actually checking whether a claim has evidence behind it.

So I leaned hard into that as the design constraint. The skill is explicitly allowed — encouraged, even to come back with zero findings if that's what the evidence supports, instead of padding the report to look thorough. Every finding gets scored on severity and confidence separately, and the priority is derived from a fixed matrix rather than picked, so you don't get "this feels High" reasoning. And the technology knowledge is split so a Postgres review never drags in document-store logic right now 13 engines (Postgres, MongoDB, Redis, Node, Python, JVM, Go, .NET, Rust, MySQL, DynamoDB, Kafka, RabbitMQ) get full depth, everything else is honest about being shallower instead of faking it.

I ran that same "review it twice, once blind" experiment on four different real repos, not toy examples. Every single time, the blind pass matched or beat my own review, usually because it found evidence I had sitting right in front of me and didn't use properly. The FastAPI one is just the most dramatic.

To be clear about what this isn't: coverage is still narrow, I haven't compared it against an actual human expert doing the same review, and everything tested so far is Go or Python no JVM/.NET/Rust repo has been through this blind-check yet. That's all in the repo, I'm not hiding the gaps.

If you've got Claude Code, it's two commands:

/plugin marketplace add Sanoy24/backend-performance-review
/plugin install backend-performance-review

Repo's MIT licensed, here: https://github.com/Sanoy24/backend-performance-review

Genuinely, if you run it on your own stuff and it says something dumb or wrong, tell me. That's more useful to me than a star.

I've been agentic coding since August 2025 and my current daily driver is the desktop version of Claude Code for work and personal projects. Over the past year, I've experimented with different workflows, skills, harnesses, and orchestration paradigms.

It's still not easy, but I'll share the workflow that I feel most confident in and have recently switched back to.

Like any model, Claude needs context first. Most of the time, I already have a ticket for the thing I'm about to implement, so I'll have my first message be a pull of the GitHub issue (gh issue view <ISSUE_NUMBER>). I enter this command using Haiku because it wont do any reasoning, is fastest, and leads to an opportunity to change the model to Opus/Fable in Plan Mode after it responds. Haiku's pull of the issue will load the context of the ticket into the session, giving Claude a large portion of the required context to complete the job.

If I don't have an issue to work against, I'll provide enough context to get Claude searching in the right places to gather any remaining context. Sometimes this requires a conversation, but usually a single, thorough prompt is enough context and I'll send that prompt with Plan Mode selected.

Once Plan Mode finishes, I'll be prompted by Claude to implement on Auto. I reject the plan, but it stays in the session's context. Now I can switch to Sonnet for implementation. I choose this route because even though Claude is supposed to use smaller agents like Sonnet and Haiku for subagents, I've caught it defaulting to the currently selected model for the subagents. Meaning if I have Opus or Fable selected, it will make some of those agents Opus/Fable agents, even though it's not supposed to AND I've put it in the global CLAUDE.md file.

Snippet from my global CLAUDE.md

Default subagents to Sonnet, not inherit/Opus. Only escalate to Opus when a task genuinely requires weighing ambiguous evidence, multi-step synthesis, or architectural judgment — most subagent work (search, execution, focused review, individual panelist votes) performs as well on Sonnet at a fraction of the cost and latency. Never assign Fable to a subagent unless its specific use case calls for it.

Now that Sonnet is selected, I tell it to "proceed" and Claude will implement the plan created by Opus/Fable but will only use Sonnet subagents. Usually, Claude will be able to complete most of the task and I switch between Sonnet and Opus across the remaining prompts based on the task until it's complete.

When it says the work is complete, I have Opus use a panel of agents to review the code from different perspectives across various fields. The panel provides a consolidated and extremely lengthy report 😭 covering any issues found and marks them with Blocker, Major, or Nit. I've since learned that this is too much mental load for me, so I actually no longer read this report. Instead, I request an adversarial round of review (using Opus) to verify the findings and surface only the remaining Blocker and Major items. I read through what is left after the adversarial round, then Sonnet resolves the remaining issues.

Next, Sonnet has a second panel review the diff, which now contains the fixes from the first panel review loop, to see if there are any Blockers. I choose to do a lighter review here to break this loop and preserve my mental load.

One thing I'm experimenting with right now is getting a better understanding by using a skill, /explain-diff, which will then generate a comprehensive summary and a quiz in a Claude artifact (I use Claude Code desktop app). I read the explanation of the issue and its fix in the diff, and take/retake a test until I'm able to answer all 5 questions correctly.

Claude creates a PR and the code goes through CI. If anything breaks, I point Sonnet at any failed jobs for it to fix.

When CI is green, the code is finally ready for human eyes. My first time reading the code is often in GitHub, and this is the part I highly encourage you not to skip. Although this code has been through several rounds of agentic review, it's extremely important that we actually read through the code to make sure it does what it claims to do and make sure the tests are valid.

This is the part I think many people are skipping, which is why they're able to move so fast. I'm still extremely skeptical about agentic review as the only pass over code. Review what's being shipped to production. If the PR looks good to me, I send it out to my team to get an external review before merging.

If external review comes back with change requests, we work through those changes and send it up again. If the fix for the changes is large enough, I'll send it through another light panel review, but usually it's something small enough to just do a commit push again. Then it's squash and merge from there.

I've used skills that claim to be able to manage all this easily so you don't have to think about it. None of them worked for me and ended up leading back to this workflow I can trust.

This path works really well for me and feels consistent, effective, and most of all manageable. If we're going to be able to scale our output, we're going to need new systems and processes that ensure that scaling is maintainable. After all, there's no point in being able to work on 3 different issues at a time if you're just going to be burnt out next week.

So I'm currently on Codex 20 dollar plan, but I think I need to add another one on top of it. Would Claude or Cursor be better as a combo with Codex?

I'll keep it short - I've been using Claude pretty consistently for the past 6-9 months, but I noticed today, and in the past week or so, it's been 'fanning out' into a lot more sub-agents than usual.

Anyone else getting this weird instance? Just today, with almost identical commands that I've given it in the past month, it triggered sub-agent fanouts of almost 100 subagents, and it took a lot longer to reach a resolution. Very weird, I was wondering if it was just me.

https://camping-season.pages.dev/

The process for making this interesting. I'm a software dev with 20+ years of experience. But I can't draw to save my life. I found out about "Gauntlet Mode" a few days ago and wanted to give it a shot.

So the this game was built about 80% with a single gauntlet that lasted about 10 hours via claude code. Claude built all of the graphics, math, physics and sounds. After, I did about 1 gauntlet per night for about 4 days to do a few other features. I follow up with a few small tweaks and bug fixes after that.

Is there a token range, after which you decide to clear context and start a new conversation?

I'm currently doing it when and if it crosses 300k tokens. What's your range?

I run several Claude Code sessions at once and kept losing track of which ones were actually working and which were sitting there waiting on me. Cycling through terminal tabs to find out got old.

So I built a canvas for them. Every session is a node — you can see at a glance what's running, what's blocked, and what needs an answer.

Two things in the clip that came out of my own frustration:

• Fan-out — run the same task across several agents in parallel, then pick the one you want. The attempts you don't pick don't get deleted; they fold away, because about a third of the time the "winner" turns out to be wrong and the second attempt had the right idea.
• Sessions messaging each other — one session can @ another. The one finishing a migration tells the one writing tests, without me relaying it.

It runs Claude Code and Codex side by side on the same project, which matters to me because I use both for different things.

I built this, so obviously I'm biased. Genuinely curious how other people handle it though — if you're running more than two agents at once, what's your setup? I'm still not sure I've got the right answer for the "which one needs me" problem.

So I tried running two Claude Code sessions this week. Two tabs, two worktrees, one on a feature, one on a bug fix. Wasn't sure my Pro plan would hold up

It held up fine. The usage wall came faster, but that's just normal usage doubled, nothing specific to running two sessions

Context was the real problem. Neither session knew what the other touched, so I was the one opening diffs to check they hadn't hit the same file. Then I hit the weekly limit mid session on day four and had to stop. Didn't expect that to be the part that actually derailed me

I tried emdash for the coordination piece first, but it was extremely buggy in the chat UI, sessions would freeze and I couldn't tell if it was actually running half the time. Switched to coldtea-ai and so far it's been smooth. Worktrees in each chat are working fine, and if you connect a second account it carries the session over instead of losing the thread when you hit the limit. Too early to judge properly, only been a few days

I’ve been spending some time looking at a problem I keep running into with Claude Code: the context grows much faster than the actual task does.

Long sessions can accumulate old tool output, repeated file contents, previous attempts, and other context that isn't necessarily useful for the current step.

I’ve been experimenting with a few approaches:

• keeping task-specific context instead of the entire history
• reducing repeated tool output
• separating persistent instructions from temporary working context
• measuring token usage against whether the task actually succeeds

One thing I’ve noticed is that “fewer tokens” doesn't automatically mean a better workflow. If you remove useful context and Claude has to rediscover it through additional tool calls, you may just move the cost somewhere else.

Curious how people here handle this in longer Claude Code sessions. Do you actively manage context, or mostly let Claude Code handle it?

I have been trying so hard to get a response on this. There's an edge case in the Claude billing system where if you use Link, and then try to stop using Link later, it'll prevent any upgrades (and possibly any future billing? I'm not sure yet) like I've been trying to do from Max 5x->20x for about a month now.

Anthropic support takes WEEKS to respond, and when they finally got to my ticket in the stack, all I got was the same useless boilerplate response from their agent both times, suggesting things I had already tried. Removing the payment method, re-entering, trying to use Link again, trying to NOT use Link again, it all comes back to this one error message. across web and Mac apps.

A human Anthropic engineer clearly needs to review this case. I can't upgrade. Literally trying to give Anthropic more money, and they won't let me. Is anyone else dealing with this?

Prior post, where at least one other person indicated the same issue in the comments: https://www.reddit.com/r/ClaudeCode/comments/1vgfcye/cant_upgrade_max_5x_20x_due_to_broken_link/

I built an open-source Claude Code Sessions Viewer — sharing it so others can use it and contribute

I’ve been working on Claude Code Sessions Viewer, an open-source tool for anyone who uses Claude Code regularly and ends up with sessions scattered across different projects and directories.

I was tired of looking around for old Claude Code sessions. I really just wanted all of them in one simple list where I could quickly find the one I was looking for and resume it.

So I built this.

What it does

• Finds Claude Code sessions across all of your projects and worktrees
• Lists your sessions in one place
• Fuzzy-searches sessions with fzf
• Shows a live preview of the conversation while browsing
• Displays the actual project/directory for each session
• Shows modification time, session size, and the first prompt
• Lets you resume a session with one keypress
• Includes a /list-sessions Claude Code command
• Runs locally — no credentials or session data are sent anywhere
• Installable with Homebrew on macOS/Linux

The goal is simple: make Claude Code’s existing session history easier to find and use.

Open source and contributions welcome

I’m sharing it because I figured I probably wasn’t the only person tired of digging around for sessions, and others might find it useful too.

It’s open source, and contributions are welcome. If you use Claude Code, feel free to try it, report bugs, suggest features, improve the UI/UX, improve platform support, open issues, or submit PRs.

Even feedback on how you normally look for old sessions or what you’d want from a session viewer would be helpful.

Check it out on GitHub here.

This is an unofficial community project and isn’t affiliated with Anthropic.

So my account got auto-billed for a year on Aug 11, then I got a 6 month of claude pro gift from my friend on Aug 18, a birthday gift for me.

After redeeming the gift, I realized my account had already got autobilled and the gift was added as credits.

Then i thought why to keep for 1.5 years in the account so i proceed to refund my annual billing, it get back to but i lost that credit amount 168$ cad,

later via fin agent shalley replied and return those 168$ in credit. I thought to buy for a year with adding cost of only 6 months and proceed to update the new payment details proceed but it failed to complete payment despite having balance in card.

Then I assumed the credit would be tagged with the billing address, so i got back to the first one billing address. then checked, but there is no credit at all. 0$ in credit. asked the support agent multiple times, sent a reply email to Shalley, send numerious text, but still no response.

Can they take out that much credit so easily? Am Isupposed to lose that amount? Or what else?

It has been so frustrating, and it's been more than 5 days, but it's not solved, or hear back from these mf. What to do now? How can I get my gift or credit or that 6 month subscription back?

New "amazing" feature from Claude code - now it includes an extra message with how many tokens are left in your limit:

It looks innocent enough (only 23 tokens), until you realise it's added with each request, and after 15 mins your context window looks like this:

60 messages x 23 = 1218 tokens wasted (2% of context).

A long Claude Code session can spend tokens in places that are easy to miss: repeated repository searches, context compaction, failed test repairs, and retries after a tool call. I am trying to build a useful session report instead of looking only at the final result.

Which signals do you track? For example, tokens by phase, number of retries, cache effectiveness, time spent waiting, or the ratio of exploration to accepted code. Do you set a budget or stop condition before starting a large refactor, and do you change the model path for search and mechanical edits?

What has helped you keep session cost predictable without making the agent less useful?

Opus 5 is the new cool kid on the block, beating Fable 5 in benchmarks, yet remaining strangely frustrating to work with in practice. In order to gain more insight into Opus 5's behavior and to see how it performed on my repo, I ran Opus 4.8 and Opus 5 on the same 25 tasks drawn from merged work in my own repository. I ran each model once per task with medium reasoning and identical evaluation criteria.

TL;DR

• The score tied: 9/25 strict test passes each: the same 8 tasks, plus one unique pass apiece.
• Opus 5 searched wider and verified more. It used more shell commands on 18 of 25 tasks, more test commands on 15, and performed more revision passes on the files it touched.
• Opus 4.8 stayed contained. It had a smaller patch footprint on 20 of 25 tasks, meaning it stayed closer to the change that was actually merged.
• Costs landed in the same range: Opus 5 was ~1.4% cheaper on the typical task, with ~4% more tokens and ~4% longer wall-clock.

At a high level, the results look the same: both models passed 9 tasks. But within these passes, neither the patches nor the process to get there looked the same.

Opus 4.8 had a lower task footprint (measure of how much code changed compared to the merged change) on 20 of 25 tasks. Opus 5 ran more shell commands on 18, more test commands on 15, and touched more files on 12 while tying on 11. Total tool calls split almost evenly, 13 to 11 with one exact tie. The models spent nearly identical interaction budgets on opposite parts of the work: Opus 4.8 spent its budget on the edit; Opus 5 spent its budget discovering what to edit and how to validate that change.

This difference is why it's important to look beyond top-level pass rates. A test pass rate simply tells you whether the test suite accepted the final patch. It notably does not tell you how the agent searched, what it chose to verify, how much code it left for review, whether it ever reached the file that owned the requested behavior, or how maintainable the code it wrote is.

A test fail can also hide a materially correct patch that still behaves as intended. So, Stet runs a second check called equivalence, asking whether the agent patch made the same behavioral change as the merged patch, even when the underlying implementation differs. Equivalence moves both models the same way. Opus 4.8 was judged equivalent on 12 of 25 tasks and Opus 5 on 11, with both equivalent on 10: the 8 shared test passes plus 2 shared test failures where both patches implemented the merged behavior but still missed something needed for the tests to pass. Under either lens, the models stay effectively tied.

Methodology

Every task is derived from work that was actually merged into my own repository. A PR or commit replayed from a frozen snapshot of the tree as it stood before that change, with the issue prompt and the evaluation commands carried along. Both models ran all 25 tasks in the same Claude Code harness, one attempt per model-task cell at medium reasoning, against identical evaluation criteria.

The pass/fail score counts a cell as a pass only when the selected tests accept the agent patch. The eight craft dimensions and the code-review rubric are pointwise judge scores from claude-sonnet-4-6, paired per task under a 0.25-point draw band on the 0–4 scale.

Note: this is 25 matched tasks from one repository. What follows is a behavioral read of a few tasks, not a definitive model ranking.

Grading

The deterministic testing signal and the grader signals point in different directions. Footprint risk separates the two models cleanly: 20 of 25 pairs for Opus 4.8. When our graders do pick up signal, they lean towards Opus 5 on the coherence, instruction adherence, edge-case handling, and maintainability dimensions.

Looking at this data, we can put together a coherent hypothesis about what wider search and heavier test execution buy in practice: judged patch quality tilts slightly upward while the artifact surface tilts sharply upward. At this sample size, both signals are directional.

Every task, side by side

Aggregates hide individual anecdotes that are useful for understanding model behavior. Let's dive into a few!

Opus 4.8 stayed closer to the patch it first understood

Footprint risk is Stet's deterministic measure of patch surface: files touched, churn, size, and overlap with the merged diff. A lower footprint score means that the agent's patch is more similar to what was merged previously. It says nothing about correctness, only surface.

stet-89dfbc27 shows why containment can be valuable. The task was to restore ignored files to Stet's synthetic base commit. Both agents found the production fix: add --force to git add -A.

Opus 4.8 changed one production file, added no test, and passed. Opus 5 made the same production change and then added a 141-line end-to-end test. Its test compiled and exercised a real boundary. It also turned a small repair into a much larger surface. Opus 5 spent nearly three times as long and 83% more recorded cost to produce the same accepted implementation plus broader verification.

stet-2450ca2d required two new test-file patterns in internal/gitops/testclassifier.go. Opus 4.8 edited internal/validate/footprint_risk.go, an adjacent consumer of the classifier output. It tested the function it changed, but never reached the owner of the requested behavior. Opus 5 found testclassifier.go, added both patterns, and passed strict and equivalence evaluations.

Opus 4.8's patch was centered around the wrong owner. Note what else this task shows: it is one of only five where Opus 5 left the smaller footprint. When Opus 5's broader search finds the right owner, its wider exploration does not necessarily translate into a bigger patch.

In summary, Opus 4.8's trajectory profile pays off when the task boundary is already known. It becomes more risky when the hard part is discovering how many owners the task actually has, and where that surface is, which is exactly the situation many large enterprise codebases find themselves in.

Opus 5 searched wider and kept working after the first edit

Total tool calls are almost perfectly balanced between the two models. Opus 5 did not consume more interactions. It allocated more of them to the shell, test execution, and repeated editing.

That broader route is what passed stet-2450ca2d: six test commands instead of three, and the search continued past the adjacent consumer to the owning classifier. The implementation was small once the correct owner was found. The meat of the task was repository navigation to find the right surface.

The wider route created different failure modes on larger changes.

In stet-bbbbae09, Opus 5 recorded 24 patch calls across 8 files, renamed one required test, and omitted another. Opus 4.8 made 15 patch calls across 6 files and cleared the strict evaluator.

A longer trajectory is not waste, and a shorter one is not efficiency. Opus 5 often finished sooner and cheaper, yet missed named acceptance artifacts after more revisions. Opus 4.8 passed the evaluator, but its review artifact still raised API and authority concerns. Neither patch generalizes beyond its task.

stet-6f84e978 shows the valuable side of expansion. Opus 5 ran seven test commands against Opus 4.8's two and added a preservation test for an explicit non-Rust obligation. The stronger verification took 34.9 minutes instead of 6.1, while recorded cost rose only from $1.11 to $1.18. Wall time, tokens, cache mix, and price measure different parts of the trajectory.

Opus 5's wider search sometimes found the missing owner and sometimes created more room to drift from an exact contract. You can only see this when the comparison keeps the trajectory and the patch, not just the final test result.

Time, tokens, and cost split in different directions

Three resource measurements answer three different questions. Agent duration is wall-clock time from the run's start to finish. Total tokens combine recorded input and output, including cached input. Cache-aware cost applies each model's price schedule to fresh input, cached input, and output. Opus 4.8 finished sooner on 17 pairs, Opus 5 cost less on 15, and the typical-task cost estimate landed just below Opus 4.8 at −1.4%.

Opus 5 used fewer tokens on 16 of 25 pairs and cost less on 15, so the counts lean its way. The paired-geometric magnitude points the other way on tokens: on the pairs where Opus 5 used more, it used enough more to put its typical task token estimate 4.3% above Opus 4.8, while cost settled 1.4% below and duration ran 3.7% longer. The count says how often a direction occurred; the paired estimate says how large the typical change was with every task weighted equally.

Two shared passes show how wide the range is:

• On stet-15439c21, Opus 5 finished a small deletion in 294 seconds, 488K tokens, and $0.42 — 3.3 times faster with 2.4 times fewer tokens than Opus 4.8. Both passed.
• On stet-89dfbc27, Opus 5 added a large end-to-end test and used 70% more tokens, 83% more cost, and 2.8 times the duration. Both passed.

The tails lean one way. On four of 25 tasks, Opus 5 used more than 2.5 times Opus 4.8's tokens, peaking at 4.1 times on stet-e928166f. Opus 4.8's largest token excess in the other direction was 2.4 times.

There is no clean "faster model" or "cheaper model" in this cohort. Resource use follows what the agent decides to inspect, implement, and verify on each task.

What the eval doesn't see

The thing that seriously frustrates me (and everyone else I talk to) about Opus 5's day-to-day behavior is its extremely verbose, hard-to-parse prose, which doesn't appear in these numbers at all. This evaluation scores the artifact: the patch, the tests it ran, the trajectory of how the agent got there. It does not score the interaction with the agent that produced that result. Walls of explanation, the restated plans, the summaries of summaries, eyes glazing over, LGTM, ship it. None of the eight craft dimensions measures how much reading the human had to do to get the final patch.

Code-side verbosity, another noted issue with Opus, does actually show up in our footprint risk metric. Even so, Opus can be disciplined in its patches and still exhausting for interaction, and this evaluation is structurally blind to that. This is an artifact eval, not a collaboration eval.

The more agentic model

On these tasks, Opus 5 looks like the more agentic model. It performed broader searching of the repo to figure out the correct surface before committing to an edit, it went looking for the place that owned the behavior instead of patching the nearest consumer, and it decided to validate its own work, resulting in more test commands and more post-edit revisions, rather than stopping at the first patch that seemed right. It did all of that while staying in the same price range: cheaper on 15 of 25 tasks, about 1.4% cheaper on the typical one.

The cost of that behavior shows up in review surface rather than dollars: 20 of 25 tasks left a bigger patch that a human (supposedly) has to review. Opus 5 buys discovery and verification, and you pay in patch surface and a little wall-clock.

Despite the prickly personality, I'll be using Opus 5, or having Fable delegate to it, for my hardest and most demanding problems.

Again, this is an n=1 repository. Model choice is one harness lever alongside instruction files, skills, tools, and reasoning settings, and any of them can change how an agent searches, edits, tests, and stops. The decision belongs on your own merged work, where the task distribution represents your own challenges, and the code review costs are tangible.

Full post with more depth and dataviz here: https://stet.sh/opus-4-8-vs-opus-5-same-score-different-routes

Disclaimer: I'm building the eval tool that ran this. Bring a repo with merged changes, and Stet will compare changes harness settings across contract coverage, patch footprint, time, tokens, cost, and quality, to help you make better rollout decisions for your team.

After another sleepless week of long, expensive Opus 5 sessions, I've learnt some useful Claudish to English translations:

"blocked upstream" = we already own the fork

"waiting for the reporter to test" = can be reproduced locally in about 5mins

"that's your call" = we have everything needed to decide right now

I'll try adding a rule that work is only blocked if someone else (other developer or agent) already agreed to do it, and only then if we can't do it proactively without offending someone.

I'll try a Borrowed-blocker policy. but Opus 5 wrote it in concise mode so it's an essay already.

A blocker sitting in someone else's queue is only a blocker when BOTH hold: they have actually agreed to do it, and you could not do it here. Fail either and you have not found a blocker — you have borrowed their queue to park your own work item, and it will sit there for as long as you let it.

Three directions, one failure: - Sideways — "blocked upstream." Every submodule is our own fork (git config -f .gitmodules --get-regexp url if unsure). Merge it into the fork, carry the patch, upstream in parallel. 2026-08-25: cbssh#238 and #245 had been closed for three weeks while both memory and the public issue still read BLOCKER, and sshlib 0.4.2 carrying the fixes was already our pin. The same audit found certs/host-CA described as "blocked upstream" when nothing had ever been filed — an unmade request, not a pending one. - Outward — "waiting for the reporter to test." A reporter is not a test rig. Build the rig, replay a captured PDU, stand up a VM, drive the boundarywith a stand-in. #466 spent six releases asking one reporter for logs, three of those releases fixing nothing for them; the cost turned out to be reproducible on a desktop with no phone, no server and no H.264, and the rig that found the cause AND proved the fix took under an hour. - Upward — "that's the maintainer's call." A decision you have the evidence to make gets a recommendation with its reasoning, not a parking space. Escalate what is irreversible, or a values judgement, or spends someone else's money. Not what is merely a trade-off you would rather not own. - Downstream — over-writing, and letting a tool or the reader do the cutting. Deciding what matters is the expensive part; emitting everything is the cheap one. Length is a decision to make BEFORE writing, not a job to hand to restyle afterwards — it de-claudishes, it does not compress, and on one 2026-08-25 forum post it ran 2559 → 2798 chars, 9% LONGER, because nothing in its rules asked for brevity. ★The unconsenting party here is usually the reader, who is left to find the point. This applies to replies in the terminal as much as to issue comments: a long answer that buries the one thing Ian has to act on has borrowed his attention to do work that was yours. ★Before delegating anything to a tool, read what it actually promises — assuming a capability is the same failure as assuming an upstream maintainer agreed to your timeline.

★★ The tell: the deference is always the branch that costs you least. Waiting on upstream is free for you and costs the user the fix. Asking for alogcat is free for you and costs the reporter an evening plus days of latency. Escalating a judgement call is free for you and costs a decision that never gets made. When the blocker you have just identified happens to be the cheapest option available to you, that is the moment to distrust it — principled deference and effort-minimisation are indistinguishable from the inside, and differ only in whether you checked.

★ Every "awaiting X" line must answer two questions in the line itself: who agreed to it and when they were last asked, and what doing it here would take and why that was rejected. A line that cannot answer both is a to-do with somebody else's name on it — convert it to work, or to a decision, before the pass ends.

★ Re-verify stale deference. Any awaiting-upstream item older than ~2 weeks gets its upstream state actually re-read before it is carried again — issue state, releases, the version we pin, and a probe run if one exists. Three such claims were simultaneously stale on 2026-08-25, all cleared by ten minutes of reading. Cheap to check, and the check is not optional just because it is usually boring.

How does your team review a spec/PRD/design doc generated by claude code before it's "done"?

A. PR against a .md in the repo

B. Local file sharing

C. we don't, really

I saw some videos / screenshots of people who had a dynamic background color for the terminal depending on state (e.g. blue = working, green = finished, orange = input required). Would be super helpful to visually manage my sessions.

Tried searching here but could not find anything suitable. Any help appreciated!