A Recent Discovery: How Default vitest Ate 32 GB and Took the Orchestrator Down

Interviewers sometimes ask: "What was your most recent discovery?" It's a good question, because it tests a habit rather than knowledge: whether you dig until you find the actual cause. Here is my latest one. It's less than a day old.

The overnight run that didn't run

Last night I left my orchestrator working. The setup is simple: a set of spec files with calculations, an orchestrator that hands them out to sub-agents, and sub-agents that do the task, run checks, and report back. No decisions from me anywhere in the chain. It was supposed to run itself.

In the morning: task not done. Not "done badly", just stopped somewhere in the middle. The terminal it lived in was gone.

The first hypothesis was wrong

My first suspect was the environment. I had been running everything in a terminal, so I installed a completely different IDE, resumed the same session there, and typed one word: "Continue."

The new IDE crashed too, together with the plugin running inside it. That was a useful result: it ruled out the terminal and the specific client. Something in the task itself was killing the process.

Debugging it together with Claude Code

From there, Claude Code and I worked the problem together, from the logs and whatever had survived on disk. The cause turned out to be almost embarrassingly mundane.

One of the executor sub-agents was running the frontend tests before its task: bun run vitest. vitest wasn't something I had added. The agent had introduced it at some point when it needed checks: the package, a script in package.json. What it never wrote was a vitest.config: no worker cap, no timeouts, no limit on file parallelism.

The vitest default is to run every test file in parallel, one worker per core. Each worker spun up its own jsdom, its own mocks, and its own fixtures with the calculation data. Between them they claimed all 32 GB of free memory. At that moment the agent tried to launch something of its own on top of the tests, there was nothing left, and the system killed the fattest process. That process was the whole IDE, with the terminal and the entire session inside it.

So the orchestrator never "decided wrong". It was doing exactly what it was asked, and the floor got pulled out from under it.

What I took away

Don't hand over configuration wholesale. An agent is very good at adding tools, and it adds them with default configuration. Tool defaults are designed for a person at a laptop who sees the machine start swapping and hits Ctrl+C. Overnight, nobody is at the laptop.

In practice this means two things:

• Put environment limits into the agent's instructions explicitly. Not "run the tests" but "run the tests with at most N workers, with a timeout, and never alongside other heavy processes." The machine's resources are part of the spec, not background.
• Audit every tool the agent introduced for its config, not just its presence. vitest.config.ts, pytest.ini, jest.config: if the file isn't there, the defaults are in charge, and you need to know which ones. For vitest that means maxWorkers, fileParallelism and testTimeout, and they are worth setting by hand.

The most annoying part is that the failure wasn't in the hard part. The spec files, the calculations, the task distribution between agents all worked. What brought the system down was a missing config file that nobody skipped on purpose.

So if someone asks me about a recent discovery any time soon, the answer is this: when AI configures your environment for you, it configures it by default. And "by default" and "safe for an overnight run" are two different things.