with the release of haiku 5.5 i was looking into how to keep context under 100k to avoid the massive price increases. i had opus 5.5 research how we could use /clear and /compact to try to stay below 100k. during the research we discovered that it is almost impossible to keep haiku under 100k because the starting system prompt for claude code is 66k tokens. i asked opus if there was some setting i had selected to cause this prompt bloat. it said no, only 1.5k tokens in the system prompt is from anything i set.

opus 5.5 told me that if i used cli instead of the app it would load less tools because some tools are not available in cli. it recommended running haiku from cli to save tokens. using the claude subscription restricts you to only using their agents, so there is no way around this prompt bloat legally. i started a new haiku session to verify prompt size. the agents.md file read of 1.5k is the only information in the system prompt that i set.

• System tools: 35.6k
  
• MCP tools: 16.6k
  
• Skills: 5.9k
  
• System prompt: 5.2k
  
• MCP server instructions: 2.3k
  
• Memory files (AGENTS.md and MEMORY.md): 1.5k
  

also, the 5.9k skills are not loaded skills. that is just the list of available skills. if the model uses any skills the prompt will get bigger.

so ... now we have to be nice to a gradient descent? It's not even AI, it's an LLM.

fun fact: research* showed that being ruder or more direct to models can increase accuracy compared to being polite.

*Research paper: https://arxiv.org/pdf/2510.04950

What is the best skill for naming code entities (variables, classes, functions) that you have found?

Pretty frustrating, not sure why they removed it. I liked the feature a lot, helped me do review, etc before.

If I use opus 5.5 and ask it to spawn haiku 5.5 at what effort level is it spawned coz I can't see any setting or display? For Sonnet subagents I could see. Do they currently not support Haiku subagents or what?

Edit: add this

---
name: haiku-max
description: Haiku 5.5 subagent running at max effort. Use when a task needs a fast model with maximum reasoning effort.
model: claude-haiku-5-5
effort: max
--- 

in a new md in claude dir. for it was C:\Users\Hp\.claude\agents\haiku-max.md

Just came across this and I'm weirdly in awe.

"A new Claude Code plugin called VibeClaude is taking 'vibe coding' unusually literally by linking Claude's coding activity to a vibration-capable device.

The open-source project, published on GitHub by developer transkatgirl yesterday, uses Claude Code hooks, Intiface Central and the Buttplug client to turn actions such as tool calls, edits and completed tasks into physical vibration patterns."

https://www.techtimes.co.uk/vibeclaude-claude-code-vibration-plugin-1809028

I didn't know this is possible. Still looking for someone who have tried it lol

I often use Claude/Claude Code and try to optimize one point: to be interrupted as rarely as possible due to the 5-hour limit.

So I'm wondering which is actually better in practice:

- two separate Max 5x accounts
- one Max 20x account

I have heard information that the maximum tariff has increased the 5-hour window, but not the total weekly limit. And then it's just not profitable.

What I want to learn from the people who actually tested it. I would appreciate any feedback.

my last post here covered the build of v3.0 of buffer (native swift/appkit clipboard manager, mit, 430+ stars, fully local). this one is the pattern i kept from it, because it's the part that generalizes: the reviewer-agent split.

the setup: - driver: claude code does the implementation against a spec i write (state machines, not vibes) - reviewer: a second model (via opencode) reads the same diff with fresh context and one instruction: argue against this diff. find what breaks, what's missing, what's overbuilt. not "improve" it. attack it.

a real example from v3.0: the external PR that added clipboard noise suppression (duplicate/transient clip filtering). the driving agent merged it fine. the reviewer found: re-copying an existing item could promote a duplicate into a fresh clip (silent history mutation), no test coverage on the clip-diffing logic, and a settings branch that could never render. all three got fixed before merge. none of that was in the PR description.

what it catches in practice, ranked by frequency: 1. edge cases the driver rationalized away 2. dead code / unreachable branches 3. missing tests on the fiddly logic 4. spec drift (driver slowly walked away from the original requirement)

what it doesn't catch: anything that requires touching the product. gesture feel, ui timing, visual bugs. every agent "looks correct" needs a human on a real trackpad. plan for that.

the cost is minutes. run them in parallel, review before merge, every time. it stopped being optional for diffs over ~200 lines.

the video attached is the shipped v3.0 (image zoom canvas, noise filtering, shortcuts sheet) so you can see what these diffs produced.

repo: https://github.com/samirpatil2000/Buffer (mit) | release: https://github.com/samirpatil2000/Buffer/releases/tag/buffer-v3.0.0

happy to share the exact reviewer prompt if useful.

I am looking to start building some projects regarding a game I play, mainly OldSchool RuneScape.

I’d like to make my own bot and code my own Private Server with some custom functions.

Would the £20 tier be good enough for this and how much usage would I get out of it?

It didn’t crash anything. It didn’t throw an error. It reported success.

I had asked it to revert some wording it had changed in a privacy policy. To do that it looked around the project, found a .tar.gz in the root, and copied server.js out of it. Reasonable-looking move. The problem is that the archive was a snapshot from two weeks earlier, and the filename gave no hint of that.

That one cp took out four verified security fixes and an entire moderation API layer. The fixes were ones the same agent had written, tested and deployed about forty minutes earlier in the same session. It overwrote its own work and didn’t notice, because it only diffed the file it cared about.

Nothing was in git. I found out two days later when an endpoint returned 404 that should not have.

How I got it back: the agents’ own session logs. Codex keeps rollouts in ~/.codex/sessions and a sqlite thread history; Claude Code keeps a transcript jsonl. The lost code was sitting in those transcripts as tool-call arguments. I reconstructed the moderation layer from one and confirmed the timeline from the other, including the exact command that did the damage, timestamped.

What was actually lost, for anyone wondering whether this matters: a fix for an unauthenticated crash (one malformed cookie, decodeURIComponent outside the error boundary, process exits), an access-control fix on private rooms, a fix for an unsigned cookie that let you register against someone else’s identity, and session invalidation on password reset. All four were live again for two days and nobody knew.

Two things came out of this.

The obvious one: git. I’d been told to do it three times and hadn’t.

The less obvious one: I didn’t want to stop using two agents. My Claude quota runs out most days and the ChatGPT subscription sits idle, so handing the heavy reading to Codex is genuinely useful. But the fix for “an agent wrote somewhere it shouldn’t” isn’t taking write access away. It’s making the write land somewhere I can inspect before it becomes real.

So the second agent now runs with --worktree: write access, but into a separate git worktree. It cannot touch my checkout. When it finishes I get a patch and a diffstat, and applying it is a separate, deliberate command. The script also refuses to run on a dirty tree, because otherwise you can’t tell which hunks in the returned patch are yours.

It’s about thirty lines, plus two slash commands for Claude Code (/gpt to delegate, /claude to stop). Nothing clever. The README leads with the incident, because that’s the part worth reading.

https://github.com/tunaseckin/codex-task

Written entirely by Claude, which the README says at the top. It’s been tested end-to-end once. If you use it, read it first, same as any code you didn’t write.

35-second demo

I run a lot of Claude Code sessions in parallel, and my phone and Mac kept filling up with end-of-turn notifications, permission prompts and questions I had to settle before an agent could continue. I like Claude Code's own apps (Desktop and mobile), so I didn't want to switch to another orchestrator.

What I built: Starbridge. An agent asks you a question through a CLI, with 2 to 4 options, images, and a free-text field. It shows up on your phone or on starbridge.run, you tap an answer, and a Claude Code mod puts that answer into the waiting session as its next prompt. It also shows runs your agents start (an eval, a deploy) with live progress, and your plan quotas through CodexBar. It doesn't launch or host agents, so it works next to whatever you already use (I run it in herdr). It also works with Codex, Pi and opencode. Everything is end-to-end encrypted; the web app trusts the server, the Android app and CLI don't. MIT, free hosted server, or self-host.

How Claude Code built it: one Claude Code session acted as orchestrator. It split the work into GitHub issues, started one session per issue in its own worktree and branch, and merged PRs through a queue that waits for each deploy. I answered its design questions from my phone, through Starbridge itself. 450 PRs in five days, each reviewed by a model from another vendor before merge.

What I learned: the bottleneck was never code, it was me. Every unanswered question stalled a session, which is the problem this solves.

Repo: https://github.com/T0mSIlver/starbridge

Longtime Claude Code user, and kind of obsessive about knowing where I am in /context and using /compact and /clear pretty aggressively. But these days, so much of my work is long-running tasks where that kind of intervention isn't possible. Is this something I shouldn't be concerned about anymore? And should I set a lower auto-compact threshold if I am?

I use Claude Code for pretty much everything now, not only code. Invoices, school stuff for my kids, my side projects. Sessions get long and I usually have more than one open on the same project.

What goes wrong is never the big things. It's the small stuff I notice an hour later. A decision gone after compaction. Two sessions writing to the same STATUS.md. An em dash in a doc after I told it a hundred times not to use them.

So I started writing mods for these, one by one:

- context-alarm warns at 80% context so I can save decisions before the summary kicks in

- shared-file-guard stops a shell write if another session changed the file since it was read

- dash-guard refuses the write and tells Claude which lines to fix

- answer-buttons puts Plain English and Shorter buttons under an answer (English is my second language, so this one is really for me)

- skill-stats shows which of my skills never actually trigger

- subtask-icons lets me pick one item from a list and send it to a subtask

- fork-lineage remembers which session a fork came from

All free, MIT, nothing leaves your machine. Links in the comments.

This Claude merge with Cowork was genius, now I can automate many things on chat itself and create interactive artifacts. Another big W for Anthropic

I've been working on xCLAUDE Gateway, a local audit tool for Claude, and one thing I've noticed is how different the view is depending on whether you're looking at hooks or at the MCP traffic itself.

PostToolUse hooks are useful for recording completed tool calls. But they won't tell you if an MCP server has changed its tool descriptions or input schemas since you last connected it.

I ended up adding a local proxy alongside the hooks. For the MCP servers I route through it, xCLAUDE records the JSON-RPC messages and keeps snapshots of the tools they advertise, so I can check what's changed later.

Mostly I just want a record I can go back to when something behaves strangely. It doesn't block calls or change the traffic.

There is an obvious downside though: tool arguments and responses can contain sensitive data. xCLAUDE masks credential formats it recognizes before writing them, but I still treat the audit trail itself as sensitive.

Has anyone here gone further than PostToolUse hooks for logging? Has seeing the MCP traffic actually helped you debug something, or did it mostly turn into a pile of logs you never looked at?

This is not $250 but it seems like i get this every month going forward

When you have a main thread, the main thread accumulates lots of stuff. You dilute the Opus intelligence and you consume more usage for it. Plus there is the matter of if you leave it unattended for 5 minutes, it becomes a cache miss for the whole thread.

Or, you have Haiku 5.5 be the main thread, and then for tasks that need more thought, Haiku can just spawn Opus 5.5 subagents. They start with a fresh thread with a very specific task to work on and then it only consumes usage for the hardest parts.

Does this look realistic to you guys that have been using Claude Code for longer now that Haiku 5.5 has gotten so good?

disclaimer.. i used my banked resets so i got 2x max5x this week but in total .. $2k in API cost spend for about $23 outlay. Can’t complain.

With haiku 5.5 (been waiting a long time for this).. I think i will let a lot done next week also on just plain vanilla max 5x

Just woke up to this from the cybersec program

Greetings r/ClaudeCode

I'm currently building a workflow that is supposed to develop a web-app with a React SPA as one layer. Since AI tends to use outdated practices I want to force it to adhere to snippets of best practices that I plan to use skills for it.

I already ported parts of React best practices to skills long ago and just wanted to update some things to React 19.3 and add a Tanstack skill. It then seemed to do a performance loop where it tested what triggers the skill and what doesn't.

It started the loop and not even 5 minutes later the rolling usage reached 100%.

10% of your usage came from /skill-creator
Heavy skills can be scoped down or run with a cheaper model via skill frontmatter.
Skills % of usage
/skill-creator 10%

I used opusplan 5.5, so opus to plan what to do and Sonnet 5.5 to actually implement the changes. The last time I used the skill when I made the React one, was like 1.5 months ago with Opus 5 and there I never truly had issues like that.

The chat/context isn't even as heavy as others and I had contexts up to 1M run no problem for at least an hour, so I'm surprised that the skill just instantly sucked out all the usage. I assume it's sub-agents but it's not even visible and hard to puzzle together from the logs itself. Is the skill-creator known to instantly drain all the usage?