The model was the easy part: turning a Pi into a desk assistant

I own DeCampLabs and sell PHNTM One. This is a builder’s account of the current documented design and accepted engineering changes, with AI assistance in preparing the text.

I wanted an assistant with its own place on my desk. Somewhere to leave a project note, ask about a manual and pick up a thought without opening another tab. That became PHNTM One: a Raspberry Pi 5 behind a 10.1-inch touchscreen.

The orb looks nice. It has never once solved a resource-budget problem.

PHNTM One's published configuration is a Pi 5 with 8 GB RAM, 256 GB microSD, a 1920×1200 touchscreen, active cooling, microphone and speaker. The commercial kit also includes a mini keyboard and power supply. At $799, this is an appliance proposition, not a claim that a Pi board is worth that much or that it beats a capable desktop at inference.

The current manual describes Gemma 3 4B Q4_K_M through Ollama with an 8K context budget. A small local model is useful, but it is not a frontier cloud model. It takes time to answer and it can be confidently wrong. Longer Notes can take several minutes. Those aren't fine-print exceptions; they affect how the interface should work.

One workflow, with the boring parts left in

Imagine a workshop project. This is an example, not a recorded customer journey.

First, type a note or dictate up to 60 seconds in Notes. Review the transcript. The original is saved before model processing starts. Clean up, Develop idea and Project checkpoint produce separate drafts; they don't overwrite what you actually said.

Next, import the project's reference PDF through PHNTM Drop over the local network. Ask a question and inspect the cited file and page. A citation is a route back to the source, not a certificate that the model understood it. OCR can miss text, especially in difficult scans, and there is no full recognized-text preview in the documented OCR path.

Finally, explicitly save a project detail as a memory, or set a reminder when the device's clock is trustworthy. The point is to leave tomorrow a useful breadcrumb, not ask a model to invent a history of work you never did.

Why an appliance needs more than a running model

The chat model, embedding workload, browser, audio and document workers share limited memory. Keeping them all resident forever is not the design. The manual describes a RAM ledger that reserves headroom; idle models can be released and reloaded later. A first answer after a quiet spell may therefore be slower.

Document processing makes this concrete. A native parser is a separate workload, not a harmless paragraph inside the chat function. In the accepted October changes, first-native PDF work shares headroom admission with other document work, supports owner pause/cancel and cleans up the worker group. Oversized extraction is bounded.

The engineering lesson is about the whole job. Refusing excessive work before it starts is better than letting Linux decide which process loses. Cancellation must account for the worker group, not just the request that launched it. The evidence for these changes includes resource and cleanup tests; that is bounded evidence, not a promise that every document or future failure is handled perfectly.

Another recent repair concerned failure accounting. Certain storage/history failures had to become failures rather than being counted as successful answers. If an operation didn't complete, a pleasant sentence and a healthy API port cannot make it a success. That's a lesson I would carry into any application that reports its own reliability.

Originals are more important than rewrites

Notes separates the owner's original from generated revisions. It sounds like a small UI choice until a model rewrites a useful detail into something smoother and less true.

Keeping the original creates a way back. Reviewable transcripts and separate drafts also make waiting less ambiguous: there is something saved before the model finishes. It doesn't make the generated draft accurate, and it doesn't remove the processing delay. It gives the owner an inspectable sequence instead of a disappearing input and a confident replacement.

Privacy needs a boundary you can explain

In Private mode, the model, memory search, transcription and speech run on the device. Local chat requires no cloud AI account or internet connection. A paired phone browser communicates across the LAN.

That is different from saying the entire machine never sends a packet. Optional Claude answers send context to the provider. Telegram, if connected, carries messages through Telegram in every mode. Connected email and calendar functions have their own data paths. OS networking and owner-initiated updates are separate again.

The public explanation needs to preserve those distinctions. A local inference engine is one boundary; account integrations are another. Conflating them makes a simpler slogan and a worse owner's manual.

The clock is part of the product

Reminders introduce a less glamorous dependency: believable time. After offline power loss, restored time may be old or unverified. The manual warns that reminders can be mistimed until a time source is reachable and refuses creation when time is not believable.

“Works offline” therefore needs context. Local model processing is possible without internet. A punctual alert after a power interruption has additional clock requirements. I would rather show an unverified clock than let a polished interface imply certainty it doesn't have.

What the dedicated box adds

Someone comfortable installing a model on an existing computer may not need PHNTM One. They may get stronger performance for less money. The appliance adds a dedicated screen and a workflow for documents, notes, memory and voice without making the main workstation serve that role.

It also makes the less impressive questions unavoidable: What was actually saved? What happens when a worker fails? What leaves the device? Which claims were tested, and which are only documented? Response-time and reliability work is ongoing. A previously shipped unit is not automatically evidence that it contains every change in the newest development build.

I sell PHNTM One, so this is a builder's account with a commercial interest. I am not calling the complete application open source, claiming a world first, or offering an independent review of my own product.

The purpose of publishing the manual, limitations and build details is to let somebody ask better questions than “does the orb glow?” It does. The harder work is everything around it.

Inspect the details

Owner manual · Specifications · Features · Software changes · Media kit

Questions about the build? Reach me at [email protected].