One GPU, every agent

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.

Opt-in, and byte-identical by default

This changes nothing unless you ask it to. Out of the box, Curator runs its own inference exactly as before. Point it at the shared backbone and it routes its thinking there instead: same behavior, one fewer model loaded. If the shared backbone isn’t up, Curator says so plainly rather than silently falling back, so you always know which path you’re on.

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 five projects. 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.