> Curator / blog
• local-llm, ecosystem, mcp

One GPU, every agent

Run several AI tools on one machine and they fight over a single graphics card. Curator can now ride a shared local inference backbone instead of loading its own model. By default it uses that backbone whenever one is running and its own model when not, so while the backbone is up, your memory layer and your orchestrator stop competing for the same hardware.

Here’s a problem nobody warns you about until you hit it: run more than one local AI tool on a single workstation and they all want the same graphics card. Each loads its own model, each reserves its own slice of VRAM, and on a 16 GB card they start elbowing each other out. The fix everybody reaches for is “buy a bigger GPU.” The better fix is to stop loading the same model five times.

Curator now supports exactly that. It can ride a shared local inference backbone over a private on-machine channel instead of standing up its own model, so the brain that orchestrates your work and the memory layer that records it can share one resident model on one card.

Shared when it can be, and your choice

Out of the box, Curator uses the shared backbone when it is reachable and ready, and its own model when it is not, so one fewer model is loaded whenever the backbone is up. You can also pin the path: tell Curator to use only its own model, or only the shared backbone. Pinned to the backbone, Curator treats an unreachable backbone as an error and never loads its own model in its place.

Why share the brain at all

A memory layer earns its keep by being present: capturing turns, ranking what matters, resurfacing it later. That means it’s doing inference alongside everything else you’re running. On a single workstation, the difference between “every tool loads its own model” and “every tool shares one resident model” is the difference between constant VRAM contention and a machine that actually has room to work.

It’s the same instinct behind everything Curator does. Don’t duplicate what you can share, and don’t make the user pay for waste they can’t see.

Where it stands

Curator is v0.3.0, a working eval-gated pre-release product running live across every project we build. The shared backbone pairs it with Arbiter’s local brain; it remembers for Warden and TheAuditor over MCP. See Curator in the agent stack or follow the RSS feed.

Was this useful?