Performance issue

[dududarochadev]

What happened
I didn't used reasonix since yesterday. Now I'm trying to use it and I asked a simple question to it ("search for files with PHASE in name in this repo and let me know what are the plan contained in it").

It created many subagents (more than 30) and was loading for more than 10 minutes.
Here's a screenshot for the second round where I asked it again:

I did the same thing using Opencode and deepseek-flash-v4 and it responded in 18s, so maybe really there's some change that made reasonix looping or loosing performance from yesterday to now.

Update: I had used npm install -g reasonix@latests then just run reasonix from project path. I just tried with npx reasonix code and the performance issue is gone. Just to let you know.

Now my problem is fixed, I'll just open this anyway so you can check if there's something really wrong of if any other user report it as well.

Expected
Answer in short time, like 30 seconds, maybe 1 minute.

Reproduction
Ask any question to deepseek using reasonix

Environment

• Reasonix version (reasonix --version): 0.30.5
• Node version (node --version): v22.19.0
• OS (Windows 11 / macOS 14 / Ubuntu 24.04 / …): Windows 11
• Shell (bash, zsh, fish, PowerShell 7, PowerShell 5.1, cmd, …): PowerShell 5.1
• Terminal app (Windows Terminal, iTerm2, Alacritty, kitty, WezTerm, VSCode integrated, Cursor integrated, Hyper, …): Windows Terminal
• DeepSeek model (e.g. deepseek-v4-flash, deepseek-v4-pro): deepseek-v4-flash

Logs / transcript
If using the CLI, attach the relevant chunk of --transcript, or run
reasonix doctor and paste the output.

[esengine]

Thanks for the detailed write-up — and for circling back with the npx workaround.

The 30+ subagent spawn is the part that worries me, not the latency. A "search files named PHASE" task should resolve in one glob call without ever entering subagent territory. Even if a stale dep tree explained the npx-vs-global timing gap, it shouldn't get the planner to fan out that wide.

A couple of things would help me reproduce or rule it out if you hit it again:

1. reasonix --transcript from the bad run, or the contents of .reasonix/events.jsonl in that project — that'll show whether the model itself kept calling spawn_subagent, or whether something in the tool layer was retrying.
2. reasonix doctor from both the broken global install and the working npx invocation, side by side. Mostly to confirm they're truly the same version end-to-end (binary path, node_modules resolution).

Leaving this open with the bug label while I see if anyone else surfaces the same pattern. If it stays a one-off and the global install never reproduces for you again, I'll close it as transient.

[wangbyby]

same bug for me.

Environment

• version: reasonix 0.36.2 dev
• node version: v25.8.2
• OS: macos
• Shell: zsh
• Terminal: terminal
• Deepseek model: deepseek-v4-flash

[esengine]

Thanks @wangbyby — second confirmation is exactly what I was waiting for.

The two reports together rule out the obvious environment hypotheses:

	@dududarochadev	@wangbyby
Reasonix version	0.30.5	0.36.2 dev
OS	Windows 11	macOS
Terminal	Windows Terminal / VSCode integrated	macOS Terminal
Shell	PowerShell 5.1	zsh
Model	deepseek-v4-flash	deepseek-v4-flash

Different OS, different shell, different terminal, different Reasonix version — but both on deepseek-v4-flash, and both on simple queries that should resolve in one or two tool calls. So the bug isn't an install / npm dep tree thing (the npx workaround on the original report was a coincidence), and it isn't platform-specific. The shape is flash being too eager to fan out into subagents on tasks that don't need them.

There's already an open RFC for the fix: #553 — Tighten subagent delegation policy — default off, parallel-or-real-context-blowup only. That's the right tracking issue for the policy change. I'm linking #415 to it so this conversation surfaces alongside the policy work.

Two things that would still help me reproduce this cleanly, if either of you can dig them up:

• .reasonix/events.jsonl from the affected project (the run-aborted version, ideally captured before /new or restart). That file shows whether each spawn came from the model emitting spawn_subagent over and over, or whether the tool layer was retrying on a stuck call.
• Or reasonix --transcript from a fresh repro, which captures the same data.

Even a snippet showing the first 5-10 spawn_subagent calls would be enough to confirm the delegation-storm pattern.

In the meantime, two workarounds:

1. /preset pro — pro doesn't over-delegate; the planning bias that triggers fan-out is specific to flash's prompt + reasoning depth tradeoff.
2. npx reasonix code — what worked for @dududarochadev. Not a real fix (this is the same code path), but if there's a stale cached state somewhere on the global install, npx sidesteps it. Less reliable than the preset switch.

Tracking via #553 from here. Will close #415 once that policy lands and at least one of you confirms the storm doesn't reproduce.

[wangbyby]

i have the events.jsonl: default.events_副本.txt

the way i generate it:

1. rm ~/.reasonix/sessions/*
2. npm run dev
3. input: find the subgent and explain the code for me
4. press esc and exit