Turnstile is the fix. It's a free, open source CLI that queues heavy builds and tests for a slot and for free memory, across every terminal and agent on the machine.

What it looks like​

$ swift test
turnstile: waiting for memory, needs ~4 GB, ~1.2 GB spare (running: api swift test, ~3 GB; web npm run build, ~2 GB)
turnstile: starting after 41s

That's it. The command runs in place once there's room, with the same output, exit code, environment, and Ctrl-C. Quick commands like npm install or swift --version pass straight through.

Why underneath the shell​

Every agent harness has its own idea of concurrency, and none of them know about each other. Telling each one to behave doesn't scale, and it doesn't cover the build you start yourself, or the prepublishOnly hook that quietly runs a compile.

So turnstile puts shims named swift, cargo, npm, xcodebuild, and friends first on PATH. A small daemon decides who runs. It works the same for Claude Code, Codex, Gemini, Cursor, Aider, and you, with no per-project setup.

The parts I like most​

• It learns. Each command's memory peak and run time are learned from recent runs in that project, so admission is based on what the build costs, not a guess.
• People go first. Agent commands run at background priority and queue behind the ones you type.
• Duplicate runs merge. Two agents running the same test on the same tree share one run.
• It backs off under pressure. When memory runs low it lowers each tool's parallelism, then pauses the newest agent compile if things get critical.
• It fails open. If the daemon is missing or broken, commands run ungated rather than failing.

There's also a menu bar app for watching the queue, and the same gate makes it safe to run a self-hosted CI runner on the Mac you're working on.

Try it​

brew install mcclowes/turnstile/turnstile
turnstile init

Open a new shell and run turnstile doctor. It needs macOS 26 or later. Everything stays on your machine.

The docs cover how scheduling and memory pressure work, and how it compares to containers, cloud agents, and build tools. The code is on GitHub. If it misbehaves on your setup, I'd like to hear about it.

This blog will hold product updates, design decisions, and the lessons that come from building small tools. Some posts will explain what changed. Others will look at why a tool works the way it does, including the choices that didn't survive contact with the real thing.

The studio's philosophy is simple: software should earn the space it takes up. That means focused products, clear interfaces, and care for the details people encounter every day.

Expect occasional notes from the workshop. No content calendar, no filler.