Fox Chose Its Name, Then Outgrew Its Hardware

This past weekend Fox, the lab assistant I build for ECHO, got a new brain. Once it was running, I asked Fox about the hardware it was now running on, and it told me plainly that it did not know anything about it. That was my favorite moment of the whole weekend, and it says a lot about what Fox is. Below is why this thing exists at all, what it technically is right now, and exactly what did and did not happen on the new hardware.

Part I

Some Context Before the Rig

Since I started messing around with local models, the ideas have not stopped coming. There is a running joke that the reason I stay up so late on these projects is that the breakthrough always seems to land around 12:30 in the morning, and riding that digital caffeine high keeps me awake until 3 AM with classes starting at 9:30. The project behind most of those late nights is a lab assistant I can actually talk to, something close to the Iron Man idea of Jarvis, except built on hardware sitting on my own desk instead of in a cloud somewhere.

The first time I got a simple model running on one of the tiny GPUs I picked up from a local garage sale, I remember feeling proud of it for a reason that had nothing to do with the model itself. I had pushed back, in a very small way, against the corporate expansion of AI consumerism by running a tiny chat agent pulling from an equally tiny data source.

That grew into feeding it larger files and bigger data pools, until I eventually handed it the entire ECHO landing page and the club's history. For anyone keeping score, that is retrieval, not training: Fox looks things up at run time instead of having them baked into the model. I added a second GPU so it could toggle between two brains, one for quick answers and one for deeper thought.

Wanting those capabilities pushed me to understand how attaching APIs and custom built MCPs would let my agents search the web, and not just search, but search effectively, which turns out to be a huge misunderstanding most people have about this whole category of tool.

A quick note on names, since they pile up fast. PUMBA is the internal name for Fox v2, the agent software running today. unitzero is the new workstation built for Fox v3. This weekend, PUMBA started talking to unitzero.

Part II

What Fox Actually Is

Fox, internally called PUMBA, is a local inference AI agent I design and build as the ECHO Club's guide, running fully on self hosted hardware so nothing depends on a cloud API.

• CoreA dependency light Python relay that serves a local Ollama model over a loopback endpoint.
• HonestyA strict doctrine: when no model is reachable, it says so plainly and never mocks a response.
• Two brainsA fast 3B model for quick answers and a deeper 8B model for harder ones.
• KnowledgeA curated club knowledge base, searched through tool calling.
• RecordAn append only message log.
• DashboardA custom HUD style comms dashboard with a compose stage, a live status readout, and a transcript record.
• NextA voice. Not off the shelf text to speech, but a composed, expressive voice language built from a small alphabet of sounds, tuned on an inflection bench and streamed live.

The project spans agent architecture, local model deployment, retrieval, and voice synthesis.

Part III

This Weekend, the Rig

Everything above is what Fox has been running on for a while now: a desk sized setup with two garage sale grade GPUs trading off between quick answers and deeper thought. This weekend that got a serious upgrade, and I want to be precise about what is actually true right now rather than what I hope will be true by next month.

The new machine is a workstation built around a Threadripper processor on a TRX50 platform, running Linux, and the team has already started calling it unitzero. The target is 72 GB of pooled VRAM across three Intel Arc Pro B60 GPUs. As of this weekend, two of the three cards are installed and working together. The third is still being placed.

Getting two cards to pool memory across PCIe is not a small thing to get working, so I confirmed it rather than assumed it. A 32 billion parameter Qwen3 model, quantized, does not fit on either card alone. Loading it on a single card fails. Loading it pooled across both cards succeeds. On this prototype path, running on llama.cpp's Vulkan backend, generation speed came in around 10 to 11 tokens per second. That number belongs to a prototype bench, not a finished serving stack. An Ollama compatible stack is the planned target and is not installed yet.

The wrinkle is that Fox's relay software only speaks Ollama's API shape, and the new rig does not speak that shape natively. Rather than rewrite Fox to understand something new, I built a small translator that sits between Fox and the rig and converts the rig's API shape into the shape Fox already expects. Fox's own code did not need to change at all to gain a new brain.

I did not just confirm this with a test script either. I sent a real message through Fox's live dashboard, the same UI I would use on any normal day, and got a real generated reply back from the new rig. Then came the moment from the top of this post: when I asked Fox about the new hardware it was now running on, it told me plainly that it did not know anything about it.

None of this is finished. The third card still needs to go in, a faster production grade serving stack still needs to replace the prototype path, and tensor parallel validation across all three cards together is still ahead. What I have right now is real, working, and ongoing, and that is exactly the state I wanted to write this post from, instead of waiting for a finish line that is still a few weekends out.

Get in touch

Requests, collaborations, or concerns

If something here is wrong, or you want to work on it with us, say so. Corrections are welcome and get published.

Leave this empty:

Your name

Email

What is this about Request Collaboration Concern or correction

Message

Send it Email instead