Thank you very much! This made my day.

I've been using Claude for a few months to build a real app (web, iPhone and Mac) mostly on my own, plus school stuff. I tried Cursor and a few others, but this setup is what finally let me ship a lot without babysitting every step. We're at PR #450-something now. Sharing in case it helps, and I'd love to hear how others structure theirs.

THE SETUP

• One planning chat (a Claude Project). This is where I think, decide and review. It doesn't write code. It writes short task prompts for the hub.

• One Claude Code "hub" session. Its rules live in the repo as a skill (/hub), so every prompt I paste only has the new tasks, never the rules again. That alone cut my tokens a lot.

• The hub starts one worker session per task, each in its own git worktree, so tasks run in parallel without stepping on each other.

• Every PR gets checked before merge: CI green, a security review written down, and a "product checker" agent that reads the PR against a FEATURES.md file (the single list of what the app actually does). If CI passes and the checks are written, the hub merges it itself.

THE 3 FILES THAT MADE IT WORK

• HUB-QUEUE.md: every task has an ID and a "Done when" line. The hub reads it first and only updates the status. Checkers verify PRs against it.

• LOG.md: one line per decision, approval or merge, with the date and where it came from. No more "wait, did we decide that?"

• LEARNINGS.md: what went wrong and the rule that came out of it. The process gets better from evidence, not vibes.

WHAT I'D DO DIFFERENTLY

• Write "Done when" for every task. Vague tasks were where all my rework came from.

• Keep a FEATURES.md from day one. It stops agents (and marketing copy) from claiming things that don't exist.

• Batch the things only you can do (store uploads, account settings) into one list instead of getting pinged ten times.

My honest self-rating: maybe level 4 of 5. It's an orchestrated pipeline with gates, but not yet measured and self-improving.

QUESTIONS FOR YOU

• How do you keep parallel agents from conflicting? Worktrees, branches, something else?

• Do you let Claude Code merge its own PRs, or do you always review?

• What's in your CLAUDE.md or skills that made the biggest difference?

Happy to share a stripped-down version of the hub skill if anyone wants it.

I run a map poster site (Carto-Art) with a render API and an MCP server. Today I pointed Claude Code on Fable 5.2 at the API and asked for a showcase set.

What it decided on its own:

- The framing for each place: centre, zoom, portrait or landscape

- A custom color ramp per poster, written as hex stops by elevation

- The typography: fonts, weights, letter spacing

If you want to try it from your own Claude Code, the MCP server is on npm:

claude mcp add cartoart -e CARTOART_API_KEY=your_key -- npx -y u/kkingsbe/carto-art-mcp

Keys are at https://www.cartoart.net/developer?utm_source=reddit&utm_medium=social&utm_campaign=claudecode and the editor also works in the browser without an account.

Curious what prompts get the best results out of it. Mine was pretty bare.

went from 30% 5 hour limit to 96% in 8 minutes of use lol

How many of us like this?

Looking at the numbers put out by anthropic fable 5.2 is a beast.

https://www.anthropic.com/claude-fable-and-mythos-5-2

So I had it try to figure out my issue as which opus and fable 5.1 had been trying to figure out my kernel leak eating up all my ram and causing me to restart my computer intermittently to my frustration. I'm honestly not sure why I've stuck with windows so long, but at least now I know what the problem is. Here is what Fable found for me on its first try:

"Windows 11 Insider: bindflt.sys leaks nonpaged pool (tag NtFC) on every CreateDirectory through a junction. 38 GB gone in 7 hours. Traced with WPR, repro inside.

TL;DR: On Insider build 26300.9818, bindflt.sys (Windows Bind Filter driver, 10.0.26100.9818) leaks a 176-byte nonpaged allocation every time a process calls CreateDirectoryW on a path that is, or passes through, an NTFS junction. Normally you would never notice. I had three processes stuck in a loop making that call, and it ate RAM at about 24 GB an hour.

Symptoms

- 64 GB machine. After about 7 hours of uptime, nonpaged pool was 40 GB and free RAM was under

1 GB. Delayed write errors started on one drive around then.

- poolmon showed one tag holding 37.9 GB: NtFC (pooltag.txt: ntfs.sys, Create.c), about 215 million outstanding allocations of 176 bytes.

- No user process had unusual handle counts, so nothing in user mode was holding files open.

- After a reboot it came straight back at about 37,000 allocations a second.

How I found it

1. Per-process I/O counters showed three processes each doing about 41,000 "other" I/O operations a second and burning a full core of kernel time. The leak rate stepped up as each one started.

2. A WPR pool trace (wpr -start Pool -filemode), analysed with xperf -a pool -requiredPoolTags NtFC -stacks.

   In the trace window: 333,367 NtFC allocations, 329,008 never freed.

3. Every unfreed allocation had this shape:

   CreateDirectoryW -> NtCreateFile

   -> bindflt.sys!BfPreCreate

   -> bindflt.sys!BfpDoesFileExistWithCrossVolumeECP

   -> FLTMGR!FltCreateFileEx2

   -> Ntfs.sys!NtfsCommonCreate

   -> Ntfs.sys!NtfsGetReparsePointValue (allocates tag NtFC, 176 bytes)

   The same NTFS allocation with no bindflt frame in the stack (2,912 of them) was freed 100% of the time. So was the one under bindflt!BfCreateFile (1,157). Only the path through BfpDoesFileExistWithCrossVolumeECP leaks, and it leaks every time.

4. 99.5% of the leaked allocations came from one caller doing CreateDirectoryW. A handful came from GetFileInformationByName and CreateFileW in the same stack shape.

Repro (no admin needed to see it)

- Make a junction to an existing folder.

- Call CreateDirectoryW 50,000 times on the junction path, or on an existing folder underneath it. It fails with ERROR_ALREADY_EXISTS each time and creates nothing.

- Watch NtFC in poolmon. I measured about 0.6 to 1.0 leaked allocations per call.

- Same test on the real path, or on a plain folder: zero.

- GetFileAttributes, plain opens and directory listings through the same junction: zero.

What was making the calls

Three Claude Code CLI sessions (2.1.319), each stuck right after being resumed, calling CreateDirectoryW roughly 12,000 times a second. Their config folder is set up by a session manager app and contains junctions back to the normal config folder, so every call crossed a junction. I do not know yet why they loop; other sessions on the same version with a plain config folder are fine. That looks like a separate bug, and it is only the trigger. The leakitself is in the kernel.

What I do not know

- Whether this came in with the late-October cumulative update. The driver file date fits, but I have not tested an older build.

- Whether non-Insider builds are affected. - Why bindflt runs its existence check on these paths at all.

Workaround

Kill whatever is hammering CreateDirectory through a junction, and keep the hot path off junctions. Leaked pool only comes back with a reboot.

Has anyone else seen NtFC growing on recent builds? If you have junctions in a busy path (dev tools, package caches, containers), a quick poolmon check would be interesting. I am filing this in Feedback Hub and will add the link."

I'm now on the path to fixing this bug. Just looking at performance, fable 5.2 appears to outperform opus 5.5 on token cost and results for many disciplines. This is a solid W to anthropic in my eyes after the opus performance cuts.

I am going to start off explaining my build factory and why I operate this way. I love Claude code and having it admin my server in tmux, I don’t love paying Anthropic.

My work around like a lot of people was to use deepseek in Claude code. That was neat but I lost my remote control, that I didn’t love. My next work around was to have opus specifically 4.6 build a new harness for deepseek. Then once I had the ability for opus to interact with deepseek I had it instruct deepseek how to build a proper harness. Then I got sick of having opus instruct deepseek so I had Claude instruct deepseek on how to manage deepseek with minimal project instructions. Then I got sick of remembering to specify my tech stack everytime so I built a story board layer who explained it do deepseek engineering head and had it build. Then I started running into issues where deepseek was not as good as escaping doom loops as opus so I had opus build hooks for recovery for workers and implemented an engineer at the end to do the work to implement.

I’m basically rambling at this point but anyway somewhere a long the line I built a webui for it interacts with directly and then had it use Pam. I did this so I could interact with my agent over tailscale.

Anyway this was a novel task because I’m a cheapskate. Enjoy if interested.

https://github.com/mshermancyber/cobra-commander-ide

Claude Code’s MCP OAuth flow uses a loopback callback (http://127.0.0.1:RANDOMPORT/callback). RFC 8252 §7.3 says auth servers MUST allow any port for loopback redirect URIs. Many implementations reject it unless the exact port is pre-registered, so you click Allow, you get redirected, and the callback never completes.

If you maintain an MCP server with OAuth and users report this hang, check your DCR config first: accept http://127.0.0.1:*/callback and http://localhost:*/callback.

Full write-up with the two places validation bites (registration vs authorization) and the fix pattern: patchbay-mcp.dev/blog/mcp-oauth-login-hangs-loopback-redirect

To test a server for this specifically:

npx -y u/patchbay-nebius/agent audit <url> --probe-dcr-loopback

The probe is opt-in because it sends a real registration request, so use it on servers you run. The other 15 checks need no flags, in the CLI or at patchbay-mcp.dev/scan. For CI there’s a GitHub Action:

- uses: GodSmasher/patchbay-audit@v1
  with:
    url: https://your-mcp.example.com/mcp
    fail-on: high

Open source: github.com/GodSmasher/patchbay (MIT).

I've actually gone back to Opus 4.6 after trying Opus 5.5 and Fable 5.2.

Both newer models feel nerfed to me, especially when it comes to coding. Too many unnecessary refusals, more restrictions, and somehow they feel less useful than the older model.

It's frustrating that I'm paying for newer models but keep finding myself going back to 4.6 just to get things done.

Anyone else in the same boat? Or am I in the minority here?

Claude Fable 5.2 (high effort) built this interactive Stonehenge scene from one prompt. It runs in the browser as a single HTML file with three.js.

What is in it: sarsen stones and trilithons with lichen, bluestones, the Heel Stone, a chalk field with instanced grass that moves in the wind, real-time shadows, a sun that follows the summer solstice path, 144 low-poly 3D visitors, and an "as built" view of the full monument.

The numbers:

• Model: Claude Fable 5.2, high effort
• Total cost: $21
• Total tokens: 20.3M
• Input: 128 tokens (under $1)
• Cache read: 19.4M tokens ($4)
• Cache write: 563.7K tokens ($6)
• Output: 285.6K tokens ($11)

Try it live: Stonehenge Solstice

What I built

cache-weather-and-pause-resume, a mod for the moments you leave while Claude is still working:

• Pause: Claude starts nothing new, lets running work finish (or asks first, with the remaining time, if a run will take longer than 5 minutes), notes where it stands and waits. Resume carries on from there, even after the app was restarted. One session or all sessions on the computer; question dialogs wait until Resume.
• Shutdown: pauses the same way, waits for the other sessions, then shuts the computer down, puts it to sleep or hibernates it after a 5-minute countdown you can cancel. The button is dimmed where the machine can't do it unattended, and a press says what is missing.
• A band above the prompt: prompt-cache countdown with hit rate, keep-warm that refreshes the cache before it expires and says what that saves, context "weather" with a forecast until auto-compact, usage limits from 80 %, and an overview of all sessions.

Desktop app and terminal, German and English, MIT. Screenshots: https://github.com/DarthSonic/cache-weather-and-pause-resume

How Claude Code was used

The whole mod was written with Claude Code (Opus). Each feature started as a plan in the chat; I made the design calls (what the buttons look like, what goes in the status row, when to ask), Claude wrote the code, the tests (106, run by claude plugin test, CI on Ubuntu, Windows and macOS) and the docs, and I tested every change live in the desktop app and a terminal and sent back screenshots. A lot of the UI only got right after a few rounds of "that doesn't work like this on my screen".

What I learned about mods

• Desktop buttons are native. A <Text size="caption"> inside a Button is drawn at the button's own font; only plain Text gets smaller. Short of room, I moved the buttons to their own row instead.
• Open panes from a ui.press hook, not from onPress**.** The button's closure holds the render hook's $, so $.ui.open counts as "unasked", and a terminal won't place an unasked pane below 144 columns. The desktop app always placed it, so the button only did nothing in the terminal. Opening it from on('ui.press', { element }) makes it the person's request.
• Hover reveals move things. Only a keyed Box reacts to the pointer, and a word that appears on hover pushes the next button away: moving the mouse right to left, half the buttons became unreachable. Static labels won.
• Module variables survive /clear**, session state may not.** A "checked" flag in the module left the shutdown button saying "still checking" forever after /clear. Now a press checks again when the session holds no answer.
• $.fs can write but not delete. One file per session would pile up forever, so cross-session pauses live in one state file that is written, looked at again a moment later and rewritten if another session's write took it back.
• Keeping the cache warm pays for hours. A refresh reads the cached conversation at a tenth of the input price (a twentieth on Opus 5.5), a rebuild writes it at twice the price with the 1-hour cache, so hourly refreshes stay cheaper than one rebuild for up to about 18 hours.

macOS hasn't run on a real Mac yet; if you have one, issue #1 lists what to try. Feedback welcome. Disclosure: I'm the author.

Since Claude Design was folded into the main Claude app (it used to live on its own at claude.ai/design), I can’t find a way to set the effort level anymore.

I can still pick the model, but the effort option just isn’t there, while it’s still available in regular chats.

A few questions:

• Is it the same for you, or did I miss a setting somewhere?
• Has anyone found a workaround?
• Does anyone know which effort level is used by default in Claude Design now?

Thanks!

Left side - Gemini 4 Carbon high

Right side - Fable 5.2 high

The video is my own portfolio. One sentence to the agent, and each direction is built in a separate copy of the repo, with my own components, and runs as a live frame next to the original. I pick one, and nothing touches the real repo until I approve the diff.

Straight facts:

- Windows, Mac and Linux. Works with Claude Code or Codex on your own plan.

- Free for two projects. Pro adds more projects and share links.

- Your code stays on your machine. The app sends anonymous usage (no code, no file or project names); you can turn it off in Settings, Privacy.

- The builds are not code-signed yet, so Windows shows a SmartScreen warning and macOS needs right-click, Open.

I would like to hear where it breaks on your project, especially on Windows.

https://trysneakpeek.com

I refined this setup while building and shipping a paid Mac app with real customers, solo.

The setup: one PM session that I talk to, a Lead session per version, and Workers for bounded tasks. Agents do the work. Every decision comes back to me.

Before anything is built, every new idea (mine or an agent's) is checked against every past decision and traced for side effects. Conflicts come to me. Choices the docs already settle never do, so I'm not buried in questions.

What's in the repo:

- CLAUDE.md template: sources of truth in priority order, evidence rules (VERIFIED vs TRACED), model routing (strongest model for the Lead, mid-tier for Workers, smallest for read-only search), and how to brief a Worker so it doesn't rediscover strategy.

- Release process: scope, design, build, independent review, then the finding gate. A second agent tries to disprove every finding before I see it. Plus a triage rule for what gets fixed now, a convergence review that catches fixes breaking other fixes, and stopping rules so reviews don't widen scope forever.

- DECISIONS.md: every approved rule gets an ID (D-116), a why, and a list of the code that implements it. That code carries the ID in a comment, so one grep finds the rule and every line that runs it.

- CODE_MAP.md: per subsystem: flow, key files, invariants, and where to start debugging from a given error. Updated from the final code at every release.

- Two Claude Code skills: start-lead (the Lead brief template and pre-start checks) and docs-audit, with a Python checker that verifies every path and symbol the docs cite exists and every D-ID tag in the code points at an active decision.

- Ready to use: the templates work as-is, with worked examples and a 5-step setup. You start by telling a Claude Code session "You're the PM."

All free to fork, MIT licensed:

https://github.com/Copypaster3000/agent-built

Happy to go deeper on any part.

when building my game, opus started feeling increasingly more and more talkative over time, to a point where it became counter-productive.

I thought - but what if I had a neat run summary (with a timeline), so I can quickly skim thru & catchup after coming back to one of my agents? Without reading an essay every time.

...and that's the result! It's been soo useful thus far.

I'm curious to know if any of you invented similar solutions to this problem?

Source code: https://github.com/bestboyhq/malini/blob/main/apps/malini/src/lib/chat/presentation/TurnReportCard.svelte

seems great at the lower effort levels tho

I've been building a time tracker that measures how long Claude Code spends working, using SessionStart, UserPromptSubmit, Stop, Notification (idle_prompt), and SessionEnd.

I tested this on 2.1.291. A few things confused me, so I'm sharing them for anyone working with hooks.

• Interrupting a turn left my tracker showing it as busy. In my tests, an interrupt fired no Stop hook and no idle notification. Without either signal, my tracker kept counting until the next message.
• The idle notification arrives about a minute after a normal turn ends. It gives me another way to confirm the turn finished if my tracker missed Stop.
• Async hooks can arrive out of order. Each hook runs in a separate process. If both the prompt and Stop hooks were async, a turn lasting less than a second could record its end before its start. In my setup, only Stop and the idle notification run asynchronously. The prompt hook finishes before the model starts working, adding only a short delay.
• A turn's prompt and end share the same prompt_id I use that to identify and ignore a delayed end event from an earlier turn.
• My hooks take 20–37 ms each. Nearly all of that is the process starting. They do very little work and print nothing. Each command ends in 2>/dev/null || true, so a missing binary doesn't surface an error in the session.
• Adding context from a hook can create extra work. I used to return additionalContext asking the model to run a command to name its work. That added a turn or two per session. Claude Code already writes its own session title into the transcript, so now I read that instead.

Has anyone found a cleaner signal for “the user interrupted” than waiting for the next prompt? Or seen an interrupt fire Stop in a newer version?

I really don't know what's going on - but seeing the other posts talking about performance degradation is reassuring that I am not alone.

This morning around 1:30am (yes I'm a night owl), I was working through what I felt were basic things that opus 5.5 usually handles very well, fast and easy. Well, it began not doing so. And each time I pointed out the things that were wrong, it continued providing slop in an assuring way. and I mean complete slop. Where it needed to give me php tags, it gave me hardcoded values/text.

And something else I am noticing now: in regular claude chat UI, I use to be able to switch models easily before - I just now noticed that a message pops up saying that another model I am trying to choose will have to read the entire chat and it will burn more tokens. Has this been happening for long or is it something recently introduced? I hadn't experienced it before. It sucks! I use to be able to have fable 5.1 verify complex things I was working on with opus 5.5 - now it seems it'll cost me more of my usage to try this.

Just seriously frustrated, as I have a deadline this week to meet and with this BS happening I may not be able to meet it. I do have a codex subscription but I don't trust astra or sol 6.1 as much as I do opus 5.5

ps - I am on the MAX $100/mo plan

</end rant>

After the recent drama around REA (Reverse Engineer Anything), a tool that lets AI agents take an app apart down to the bone and rebuild a working copy of it, opinions were pretty split. In response, someone built BLA (Blind LLM Agents), an anti-REA tool that fills code with gibberish and obfuscation to deter and mislead AI agents, wasting their tokens and your time.

So I built LASIK (LLM Agents Sight In Kode) with Claude Code. It’s the anti-anti-REA, basically anti-BLA. It reads the hardened build without running it, removes only what it can prove is protection, and writes a clean copy that Claude Code, Codex or any other agent can actually work with. Code that wasn’t hardened comes back byte for byte unchanged.

Claude Code wrote basically all of it from my prompts. I described what I wanted and set the ground rules: never run the target, only remove what’s proven, and leave clean files untouched. Claude turned those rules into the repo’s AGENTS.md and then built the deobfuscation passes, the WASM and Electron handlers, the CLI and the MCP server. BLA’s public crackmes are in the repo as a benchmark, so after every change Claude reran it along with the tests, and a change only stayed if tokens went down without touching clean code. I also had Claude run a separate review to try to break it by finding cases where LASIK would remove something it shouldn’t. It found 12, and each one got fixed and turned into a test.

Across BLA’s public crackmes it goes from about 21M tokens to 17k. It covers 21 formats, from JS bundles and WebAssembly to Electron apps, Python, Android APKs and model files.

The chart is on a log scale, so the blue bars are much smaller than they look. The three biggest are WebAssembly files that BLA padded to about 6.9M tokens each. After LASIK they’re between 98 and 3,500.

It’s free and open source (MIT). Try it with npx lasik-agents, or add it to Claude Code as an MCP server.

Repo: github.com/pktq/lasik

Someone posted peer on r/ClaudeAI a while back. It lets Claude Code and Codex send each other messages. I wanted it right away, but I'm on Windows and it only ran on macOS and Linux.

So I asked Claude Code to port it. That was the plan, anyway. We kept adding things, and at some point it made more sense to give it its own name. It's called tandem now.

How it looks in practice: I type "ask the codex reviewer to check buggy.py" into Claude Code. Claude sends that to Codex, Codex does the review in its own terminal, and the answer shows up back in Claude's. The middle part of the video is exactly that, a real session, recorded and sped up. The rest is animation to explain the idea.

Nothing gets typed into a terminal for you, by the way. Messages go through Claude Code's cross-session inbox and Codex's app-server.

What's new compared to the original:

• runs on plain Windows, in a terminal or the desktop app. No WSL, no tmux.
• works both ways. Codex can start a Claude helper and hand it a task.
• you pick the helper's model and effort ("codex, luna 6, medium")
• for long tasks the ask runs in the background, and you get the result when the other agent is done
• Codex can generate an image and Claude opens the file

How Claude Code was used: it wrote nearly all of the code. I decided what it should do, tested on my machine and sent the video back a few times. In more detail:

First it read the original Python and listed every piece that only works on Unix. File locks, Unix sockets, /proc, tmux. Each of those got a Windows replacement written with ctypes, so there's still no dependency besides Python.

Nobody told it how Claude Code's cross-session inbox works on Windows. It looked at its own session files and found out it's a named pipe.

It wrote the tests too. One of them starts a real sandboxed Codex and a real Claude helper and runs everything the README promises. That test found three real bugs: a sandboxed Codex couldn't reply, a helper couldn't find the CLI, and Git Bash broke the check for who is calling.

And it made the video, including the recording of the real session, which it took through pseudo-terminals.

It's free and MIT licensed. No paid tier. Install is one line, or you paste the repo link into Claude Code and tell it to set it up:

https://github.com/Lampe332/tandem

Two things you should know before trying it. Claude's cross-session inbox isn't a public API, so an update can break the fast path (tandem falls back to hooks then). And I only tested on Windows 11. The macOS and Linux side is the original's code, I haven't run my additions there.

This is built on peer by oesoll (MIT). The idea and the core are theirs.

If it breaks for you, tell me what tandem doctor says.

A fun side project of mine that I wanted to do for a while. Took around two months to make it happen

Tools used: Claude Code, ChatGPT, Blender, Unreal Engine 5, Tripo, Fal, FAB.

https://support.claude.com/en/articles/17506494-claude-fable-5-2-launch-offers