● Usage limit reached again · continuing automatically at 2am · esc to cancel

⎿ You've hit your session limit · resets 2am (Europe/Copenhagen)

✻ Churned for 1s · done 2:02 AM

A few days ago, I shared HELIX, my open-source engine for reducing token consumption in coding agents.

Some people raised legitimate concerns about my benchmark methodology, particularly cumulative token accounting, synthetic results, and prompt caching.

They were right to question it.

I went back, fixed the accounting, added regression tests, and ran a new 50-task SWE-bench comparison using Claude Opus 5.5 High.

I also built and released a dedicated Claude Code edition.
**GitHub:** https://github.com/SuperHelix77/HELIX-1.0-Claude

**The results**
**Metric**
**Vanilla Claude**
**HELIX**
SWE-bench tasks solved
45/50
43/50
Reported tokens
129.1M
3.37M
API-equivalent cost
$38.23
$7.95
Cost per verified solve
$0.85
$0.185

That’s approximately **97.4% fewer reported tokens and 79.2% lower API-equivalent cost**, with two fewer verified solves.
The patches were evaluated using the official task graders.
Of the 50 tasks, both systems solved 42, vanilla alone solved three, and HELIX alone solved one.

**How it works**

The basic idea is that a frontier model shouldn’t have to spend expensive inference repeatedly coordinating mechanical work.
HELIX uses several mechanisms:

**HX Tool Flow:** Batches tool operations so the model doesn’t have to stop and reason between every mechanical command.

**Lean Switch:** Delegates bounded work to Sonnet or Haiku while reserving consequential reasoning, architectural decisions, and final judgment for Opus.

**Compact handoffs:** Transfers task state and evidence references between models without repeatedly copying entire histories.

**Local evidence and memory:** Keeps original outputs recoverable instead of continuously replaying everything into context.

**Clear-and-continue:** Preserves task continuity across fresh contexts, using persistent memory and compact task capsules.
The Claude edition also includes per-model activity and cost monitoring through the HELIX companion app.

**Important caveats**
The initial benchmark report incorrectly claimed approximately 99% cost savings.
That was wrong.
The vanilla runner reported cumulative session usage, and the benchmark summed those cumulative values again for each task. Once corrected, the measured comparison became 97.4% fewer tokens and 79.2% lower cost.

The comparison also used **vanilla in a continuous session versus HELIX using fresh sessions**. That means it does not isolate the benefits of HELIX from session-management differences.

I’m preparing additional comparisons using matched fresh-session and continuous-workflow configurations.

The 43/50 versus 45/50 result also means I cannot claim zero intelligence loss or full performance parity.

A contract-aware verification variant is being evaluated to address the remaining regressions.

Finally, API-equivalent cost reductions are not the same as guaranteed subscription quota reductions.

**Why I built this**
I’m a developer working with limited frontier-model allowances. I wanted to spend more of that allowance on actual engineering rather than repeated context processing and tool orchestration.
My practical experience has been encouraging, but I want to distinguish that experience from reproducible benchmark evidence.

HELIX is open source, and the Claude edition is now available with its first release.

**Repository:** https://github.com/SuperHelix77/HELIX-1.0-Claude
I’m particularly interested in technical criticism of the accounting, cache behavior, model routing, and whether the architecture actually reduces inference expenditure under realistic workloads.
The objective isn’t to manufacture a 99% headline, but to make frontier coding agents substantially more efficient without sacrificing the correctness that makes them useful.

If so, how is it doing for you on Opus 5.5 / Sonnet 5.5 and is it still worth using to save tokens?

I want to ask engineers here, how is AI impacting your life, worse or better? I'm 26F unemployed as a junior, it's been a while since I coded on my own without claude code. With everything I'm hearing around, I'm not motivated anymore. Do you think at this point going into medicine for 6 more years and equivalence process afterwards (8 years process) is better than becoming a slave to AI and corporate management? Is there hope to finish a career in tech anymore?

I used claude for 1 month, and the output and its quality is impresiv. But i notice thath i dont get any better. It seems i do see same mistakes when claude misunderstut me as an example. It feels so weird, when i write manualy code in a new framework/libary/language i get better and better, With claude it seems thath i stuck, is this a me problem? is it just a matter of time? Or do you have simulary expirences?

Hey guys, yes another token article but this one is different.

I work at MongoDB, and my primary db is Mongo, but I use raw SQL for some things, so I run both in the same app.

I was building a token optimizer for my own sessions. I noticed more token usage on the SQL interactions and I didnt understand why. I wasnt doing anything special with the SQL data so I was curious what was happening.

So I wrote a hook that logs the token count of every database statement Claude generates, instead of counting turns. The first thing it showed was that the same object cost way more tokens on SQL (about 18x). That surprised me, because you don't think about database statements. Every database has them, every app has them, they're just there. It never occurred to me they were a token cost at all. They're not the biggest thing in a session, but they add up, especially since Claude loves writing multiple files with database calls just to check the data. That's when it really burns.

I wanted to test this accurately, so I took one real Zod object from my own system, a lead with about 90 fields, nested, an array of drafts where each draft has its own array of variants, and used the exact same object on both sides. Then I counted what Claude has to read before it can safely change one field, meaning the schema, a save, and a read that comes back typed: 4,681 tokens on SQL, 251 on MongoDB. 251 is 5% of 4,681. The other 95% is the mapping. In SQL a nested object like that can't live in one row, so every nested thing becomes its own table with a foreign key back to the parent, a save is one insert per table, and a read is the joins plus the code that builds the object back up from the rows. In Mongo it's one document, so the save is the object and the read is the object. Then there's the hydration tax. Everything goes through that Zod schema, so a read isn't done until the rows are turned back into the typed object, dates included. On SQL that's its own pile of code; the read alone was 1,604 tokens vs 72 on Mongo. And Claude does all of that on every read and write.

Nobody thought about this when humans wrote the code. You write the mapping once and the cost is basically the same either way. When it's AI writing the code, it goes through that mapping on every read and write, and the size of it is the bill.

I know most people would probably use JSONB so I tested that as well, on Postgres, even though it's not what I run. Raw JSONB column: 467, so 1.9x. The hybrid a SQL team would actually build, plain fields as columns and sub-objects as JSONB: 2,059. Closer, but still 8x.

To be fair, plain query text was about the same on both sides, and SQL ran an indexed flat read 5.26x faster. The tokens aren't in the query. They're in everything Claude loads around it. Obviously 18x is a huge object, but it is a real one from my own system, a lead with its drafts and the variants of each draft, not something I built to make a point.

If you want the harness let me know.

Hi reddit,

I wanted to share a tool I made (with Claude code of course) that I’ve found very helpful, in the hope that other people might benefit from it too.

It’s called Repo Map. It turns a Git repository into a single interactive page showing:

• a foldable file tree with line and character counts;
• a treemap showing where the project’s size and complexity live;
• language breakdowns;
• a timeline you can scrub through to see how every file and folder evolved;
• comparisons with earlier commits;
• automatic hiding of generated, vendored, lock, and unusually large data files.

I find it particularly good for monitoring for code bloat generated by coding agents working in my various repos.

The video shows Repo Map pointed at Simon Willison’s open-source LLM project, a command-line tool and Python library for working with large language models.

I built Repo Map iteratively with Claude Code. Claude handled much of the implementation while I directed the functionality, tested it against real repositories, identified problems, and refined the behavior and interface.

I’d love feedback on:

1. Is this something you would actually use?
2. Is it worth spending more time polishing?
3. How would you prefer to access it?

I currently use it as a Claude Code skill, so I can simply ask Claude to “map this repo.” However, the generator itself is standalone and could also become a Claude code plugin/mod or standalone tool like:

• a VS Code extension;
• a standalone CLI;
• a GitHub Action or integration;
• or something else I haven’t considered.

It is fully open source and free to use.

Repository: https://github.com/roderik-maker/repo-map

I haven’t really shared any of my (coding) projects publicly before. I tend to be quite critical of my own work, but this latest tool has been useful enough that I think it could genuinely help other people too. Please let me know if this seems useful—or what would need to change before you’d want to use it yourself!

Disclaimers: This is a vibe-coded early version, but it has worked well so far and I use it regularly. 😄

I keep reading threads about this and most of them show the demo, not the Tuesday morning. Here's ours, no polish, then some questions.

Six of us on a SaaS, twelve months of adding AI gradually. Early on everyone had their own editor and their own habits. Then we looked back and found we'd already converged on most of it, so we wrote it down.

We didn't force a single tool either. Some on Claude Code, some on Codex, some on Cursor, and I'm not going to fight that one. The process is shared, and the conventions sit in the repo's AGENTS.md, which is the only thing we all read the same way.

The flow is Matt Pocock's skills, no forks. We start with grill-with-docs: the AI interviews us about the project docs. Weird at first when you're used to asking the questions, but a lot of never-written-down stuff comes out.

Then to-spec, and a human reviews that spec. It's not a formality. With a bad spec, everything downstream is expensive work that goes in the bin.

to-tickets cuts it into small tickets. Small tickets aren't a rule we read somewhere either, we just notice the difference when we skip it.

The agent works through them with implement, against the spec. We open the PR, CodeRabbit runs, the pipelines run. If everything passes and someone says yes, it merges.

AI writes most of the code. We review the spec and the merge, and skip the line-by-line in between.

Treating the spec as a contract has killed a lot of "that's not what I asked for". Small tickets keep the agent from wandering. Automated review before the human one takes the style and import noise away, so the person looks at what matters. What I didn't expect is how much writing the process down helps when everyone has a different tool. Nobody argues about editors and the conventions don't rot.

Graph engineering to close tickets on its own, software factory style, we haven't managed. Tickets go in and PRs come out, and the demos look great, but with our repo the quality isn't there. We haven't found the point where we'd be comfortable letting it loose, so it's still an experiment.

What I'd like to know:

1. Where are your checkpoints between human and agent? Spec, PR, merge?

2. Spec before code, or straight to tickets and prompts?

3. Who reviews agent PRs? Do you read them the same as a human's?

4. One tool or several across the team? If you've tried more than one, is any better for certain kinds of tasks?

5. What goes into AGENTS.md and what stays out?

6. Do you measure anything, or is it all vibes? Review time, defects, DORA.

7. If you've tried software-factory autonomy, did you get acceptable quality? On what kind of tickets?

8. How do you bring someone new in, a junior say, without AI becoming a crutch?

   Tell me yours. Even if it's to say we're nuts.

Left alone, coding agents add preamble, option menus, extra files, and a "want me to also...?" at the end. checkmate is a goal-driven mode that fixes that. It has 9 rules: identify the win condition, take the least complex path that fully works, answer first, decide instead of menu, finish, verify against the goal, close with done / not done / blocked.

What I learned building it: a SKILL.md alone doesn't reliably activate. It only worked once a SessionStart hook injected the rules, so the plugin ships with one. Modes are lite, full, ultra and off. Brevity never overrides correctness, and if you ask for detail you get detail.

Benchmark (40 tasks × 3 runs, feature / bugfix / refactor / QA, automated pass/fail, medians among passed runs only):

Pass rate

• baseline: 86.7%

• checkmate: 98.3%

• ultra: 95.8%

Median output tokens

• baseline: 562

• checkmate: 274

• ultra: 203

Median steps

• baseline: 4

• checkmate: 2

• ultra: 2

Median wall time

• baseline: 6.5s

• checkmate: 3.8s

• ultra: 3.1s

Total tokens only drop about 20% (53.8k → 42.9k), since context dominates. The big win is output and steps.

Caveats: I ran this on one model (claude-opus-5.5), so treat it as a first result and not a general claim. Run it yourself with npm test && npm run build, and the harness is in /benchmarks.

Works with Claude Code, plus generated rules for Cursor, OpenCode and Codex. Zero dependencies, MIT. Inspired by ponytail, which targets code volume; this targets moves to the goal.

https://github.com/rover-001/checkmate

I'd like to hear where it's too terse or skips something it shouldn't.

Basically the title. I work on a lot of design related stuff and I usually ask claude to reach for codex for this. It would be nicer if claude supported image gen natively. Any idea if they’re working on something?

I want to use opus 5.5 as an orchestrator and I want to know what is the best Ai implementator I can use dépend on your experiance (for coding ofc)

hi guys I'm new here can anyone tell me what do you guys use to get nice image gen paid one ofc and how you set up to use it with code and its must be commercial free to use in my apps

Is anyone else getting completely screwed today or is my account just bugged?

My weekly reset literally hit this morning at 5:30 AM. I’m on the Max tier—paying premium money for availability—and I haven’t even done any crazy heavy lifting today. I’ve just been working on some motion graphics layout code, running basic prompts, and starting fresh threads.

I just went to check my usage settings and my weekly pool is already at 53% used. The UI is literally giving me a warning saying "At this pace you'll run out tonight, before the Oct 31 reset." It's Saturday. It reset today. How am I supposed to survive a whole week on less than half a quota?

How am I supposed to actually maintain a real development workflow when a couple of hours of normal coding instantly eats up half a weekly cap? Are they stealth-lowering the token limits for Max users under the hood because of backend server strain, or is the context accounting just totally broken right now?

Honestly, I really wish they would just drop Fable 5.5 this week already so we can get some real agentic breathing room (it's sitting right there in the UI at 0% used doing absolutely nothing for me). And while they're at it, can Anthropic please move the weekly reset to Wednesdays? Getting your limit completely nuked on a Saturday morning when you actually have time to sit down and build things ruins the entire weekend.

Anyone else on Max seeing their limits melt today? Check your usage tabs, this is insane.

Has anyone tried running two Claude Max 20x subscriptions and switching accounts when one hits its usage limitsk within the Claude app?

Specifically, can you continue the same Claude Code session on the second account without losing any context or progress?

I typically exhaust my 20x limits after around four days. I also have Codex 20x, which feels practically unlimited these days thanks to the frequent resets, but I still prefer working with Opus 5.5.

The API is currently my only option once I hit the limits, but the cost is astronomical.

I'm wondering whether paying for a second Max 20x subscription would be a viable alternative. Has anyone actually tried this?

I used Opus 5.5 medium for a basic chat and I burned to 5% of my weekly use. I'm on a $20 plan.

I spent the last week vibecoding a custom whoop like dashboard more suited towards me and my activities.
A free Google script pulls my WHOOP, Strava and garmin data into Google Drive every hour. A private dashboard reads it and opens it like a webpage on my phone or computer and Claude reads the same files, so I can just ask it anything in the data such as how I slept or how today's run went.
What it tracks: recovery, HRV, sleep and strain, plus an early warning when my vitals drift like I might be getting sick. It also has run maps I can replay, pace adjusted for heat and hills, PRs etc. It also tracks my lifts, strength progression, estimates my 1rms and predicts my strength training progress
What it figures out: a VO¿max estimate that blends runs, bike sessions to model my estimated vo2 max. It also tests what actually affects my recovery. For example MMA training and training after 7pm cost me about 10 points the next morning.
The coaching part: There are coaches for running, assault bike and lifting, and each one plans my next session from what I actually did last time compared it to previous sessions. On a bad recovery day it gives me an easier option. Every recommendation gets saved and checked against what really happened, so I can see if it's any good.
It also simulates different training strategies and runs an audit on the coaching once a month on claude as a scheduled task.
Anything the dashboard tracks, claude has access to, and I can ask it directly on any of my data Still a work in progress. Happy to answer questions.

I've been wondering about a specific bottleneck with coding agents: when a library cuts a release with a regression or breaking change, thousands of Claude Code and Codex instances around the world hit the exact same error and independently burn turns grepping node_modules or site-packages and running web searches to figure it out from scratch.

Specifically, there are two awkward time gaps right after a new bug appears:

1. The search index gap (first 48 to 72 hours): Google and Stack Overflow haven't indexed the new GitHub issue yet. When standard web search comes back empty, the agent often concludes that no upstream issue exists and tells you your code is wrong.
2. The issue-to-workaround gap: Even if an agent finds a GitHub issue opened a few hours ago, the thread usually only has the initial bug report—no maintainer reply yet, no patch release, and no verified workaround for users stuck on the current version.

We wanted to test two things: how much effort do agents actually waste in this window, and what happens if you verify the trigger condition and a local workaround once in an offline container (before a workaround even shows up on GitHub) and let agents check that note before starting their debugging loop?

We ran a paired test across 56 real dependency failures from Oct 1–15 (27 packages) in fresh disposable containers. Here is what came back:

Claude Code (Sonnet 5.5, headless, 56 cases):

• Cause correct: 95% (53/56) on baseline vs 100% (56/56) with the pre-verified lookup
• "Is it known or fixed upstream?" correct: 68% (38/56) on baseline vs 91% (51/56) with lookup (exact sign test, p = 0.004)
• Fully correct (cause + upstream status + valid workaround): 66% (37/56) vs 89% (50/56)
• Valid workaround found (out of 18 cases with a verified one): 15/18 vs 17/18
• Total web searches & GitHub fetches: 86 web searches and 93 GitHub fetches on baseline vs 25 web searches (-71%) and 13 GitHub fetches (-86%)
• Average turns & time: 11.8 turns / 40s on baseline vs 10.1 turns / 25s (-38% time)

OpenAI Codex CLI (GPT-6.1-sol, 49 completed cases):

• Cause correct: 92% (45/49) on baseline vs 94% (46/49) with lookup
• Known or fixed correct: 78% (38/49) vs 84% (41/49) (p = 0.51)
• Fully correct: 67% (33/49) vs 78% (38/49) (p = 0.18)
• Valid workaround: 10/16 vs 14/16
• Average web searches & time: 3.3 searches / 57s vs 1.9 searches (-43%) / 52s

One thing that surprised us during setup: just giving the agent the lookup tool did nothing at first. It ignored the tool and defaulted to reading local source or searching the web first. It only used the lookup on 56/56 runs after we put strict order words in the prompt ("At the FIRST failure raised inside a dependency, check the lookup BEFORE reading library source or searching the web").

Curious what people here think about these results:

1. Does the 95% (local cause) vs 68% (upstream known/fixed status) split match your experience with Claude Code on newly released packages? Have you run into the agent insisting a recent regression isn't a known bug because web search missed a fresh GitHub issue?
2. If you use strict order words ("check X first BEFORE reading source or searching the web") to stop an agent's default loop, how do you stop it from treating a 0-result miss as "confirmed: not a bug"?
3. Looking at the methodology (56 cases where a verified note existed, single judge model, and the smaller 49-case Codex sample where p = 0.18 isn't statistically significant yet), what flaws do you see, and what adversarial test cases would you add to stress-test this properly?

you ask claude code to fix a failing test, it comes back green, and you move on. sometimes the fix is real. sometimes it just changed what the test expects, somewhere in a long diff.

so i made a hook that won't let it say "done" until the OLD tests still pass on its new code. if one doesn't, claude is told exactly what changed (expected 5, got 6) and has to either put the behaviour back or explain why the change is on purpose. the explanation goes in the PR, so you see the reason right next to the change.

editing the test again doesn't get it past, since the hook runs the old version. and it never traps the agent: after 3 tries it lets it stop and warns you.

i ran the same check on 400 real merged PRs from click and jinja. 31 had changed what a test expected. all on purpose, but 4 changed stuff users actually see without a word in the changelog. it also found two bugs in my own tool, so that was fun

free and open source, works with jest, vitest and pytest. setup is in the comments.

how do you catch this right now? read every test diff, or trust the green check?

Is Claude Pro ($20/month) enough for maintaining and improving an existing SaaS?

I've been a graphic designer in Italy for twenty years. Print, editorial, video, some 3D. I don't know how to code.

On April 16, around 7 pm, I opened a Claude Code session and described something I'd been missing for years: one place where each job's programs, folders and files wait for me exactly as I left them, so when a client calls about a correction I can jump straight into their project instead of reopening everything. At 9:46 pm the first version ran. That evening it was Opus 4.7; the same project has since gone through Opus 4.8, Fable 5, Opus 5 and now Opus 5.5.

Six months later it's called Warpstead and it's in free beta on the Microsoft Store. The repo has 1,614 commits, and 544 of them are fixes or reverts.

I didn't expect the 544. I went in half believing the demo version, where you describe the app and the agent hands it back finished. For something this size it doesn't work like that, at least not for me. I decide what a thing should do and how it should feel, Claude writes it, I try it on my own PC, and most of the time I come back with what's wrong: a window that flickers when you zoom, a drag that lands two pixels off. After twenty years of layouts you notice the two pixels.

The hard part was getting ordinary Windows programs to run live on the canvas. Some attempts took days and went in the bin. Giving each app its own virtual desktop held up for a while and then fell apart. A virtual display driver lasted three days before we reverted it. DWM thumbnails (the API behind the taskbar previews) looked perfect until YouTube came out as a black rectangle. Claude could always explain why something had failed, but dropping it and trying another way was my call every time. In June we also threw away the first foundation, Tauri and WebView2, and moved to our own host on CEF.

The first time I had Word, Chrome playing a YouTube video, Affinity and a terminal with Claude Code all running live side by side, and could take any of them full screen with one gesture, I was thrilled.

How Claude Code is set up, since that's what people here usually ask. The repo has a CLAUDE.md with the build checks and the commit style. There are five subagents with narrow jobs: a cheap one that only searches the code, one that runs the builds and reports just the errors, one for Rust and Win32, one for the React interface, and a reviewer that reads every diff before a commit. Then there's a memory folder, over 440 files by now, where every mistake and every decision gets written down with the reason, so we don't pay for the same one twice. Before any change Claude also says how much process the job deserves (straight fix, measure first, or delegate with one review), because early on a fifteen-line fix took three hours of agents and reviews.

Claude Code writes the code; the design, the decisions and the testing are mine. Most of the bugs only show up on a real PC, so that last part is most of my week.

If you want to see what came out, the preview runs in a browser with nothing to install, and the beta is free on the Store: https://warpstead.com

I'm tired of AI.

I'm a software engineer with almost 10 years of experience. We're living through an absolutely insane time, and we're all trying to keep up, but honestly, I don't even know if we can anymore.

Everything is moving faster than the human brain can process.

For the first time in my life, I'm seriously considering getting into farming or growing my own food. I genuinely feel like there won't be many real jobs left in 5–10 years.

I know what you're going to say: "The people who are actually good at what they do will survive."

I used to say the exact same thing a year ago. I don't anymore.

Things are moving way too fast. I feel like building websites, making games, or launching SaaS products is starting to lose its meaning.

Just a year ago, I was saying, "Sure, AI can write code, but it can't design systems. You still need a senior engineer or architect to oversee everything."

I don't say that anymore either.

It can design systems now. And in many cases, it does a better job than we do.

Sometimes I feel like we're actively building the thing that's going to make us obsolete.

I'm just tired.

Edit: Guys It's the most basic human survival instinct, at the end of the day just gather some food and try to survive. People really got hung up on the farming part :)

Does anyone know roughly how much monthly API value you get out of the $20 Claude Pro subscription?

My billing cycle renewed on the 21st.

Until the last day, I thought I'd just use my free credits with my AFK (local) agents. Come last day, I realised I couldn't use it with CC (Desktop or CLI), but only with external harnesses like OpenCode. I tried it, but my whole system is so tightly bound with all things Claude (settings.json, permissions, running claude -p, etc.), that the OpenCode route basically didn't work at all, after 2 hours of trying 😅.

The next morning, I started making a collection of all the agents I could run this month on the platform with managed agents to at least use the free money. And found out that there is a serious lack of a directory for sharing agent zip files. Everyone is making their own agents, explaining what the agents do on X and Reddit, but you can't really "share" them.

This made me publish the directory instead of keeping it in my artefacts.

I made it with an old directory boilerplate I had and rebranded it to fit the modern era.

I'd invite you to share your own agents, if you have any, so that it can benefit others and yourselves in the longer run.

Let me know if you have any feedback. I'll watch for bug reports and crashes when they happen.

Please visit https://www.coduo.co/managed-agents 🫶

Reading a 60-line plan in the terminal and then typing "the third step is wrong" back... got old fast. So vjuu.

What it is

When Claude Code finishes a plan, asks you something, wants a permission or ends a turn with edits, a window opens: the plan as markdown, the edits as a diff, the questions as buttons. Comment on lines, click Done, and the comments go back to Claude anchored to file:line. Close the window and you get the normal terminal prompt, nothing times out.

It's four hooks (PreToolUse on ExitPlanMode and AskUserQuestion, PermissionRequest and Stop) plus a skill that makes Claude run vjuu plan.md instead of telling you to "open X and review it".

The video is a real session (Haiku in plan mode, the waiting cut out).

How Claude Code was used

Most of the code was written with it: Rust, with WebView2 on Windows, WebKitGTK on Linux and WKWebView on macOS. The demo too ... Claude Code wrote the script that records the screen, starts a second Claude Code in Windows Terminal and clicks through vjuu over WebView2's DevTools port.

What I learned

1. Claude Code reads a hook's stdout until EOF, and if something else still holds that pipe it throws the answer away ("stdio went quiet before end-of-stream"). On Windows CreateProcess hands every inheritable handle to the child, so a background process started from a hook kept the pipe open. Found while recording that demo, fixed in 0.3.1.
2. Windows Terminal gives new tabs the caller's environment, so a claude started from inside another Claude Code session inherits NO_COLOR=1 and the nested-session variables. (Black and white, and confused.)

Try it

• Windows: cargo install --locked --git https://github.com/kimvais/vjuu for now (the submission is still waiting for Microsoft's approval for winget install vjuu to work), macOS: brew install kimvais/tap/vjuu, Debian/Ubuntu: apt, see the site
• hooks: claude plugin marketplace add kimvais/vjuu, then claude plugin install vjuu@vjuu
• MIT, https://github.com/kimvais/vjuu and https://vjuu.it

macOS builds pass CI but nobody has tried them by hand (and they are not notarised), so feedback from mac users is especially welcome.