PHNTMOne
Proof, not promises

Verify it yourself.

MEASURED ON THE PROTOTYPE · AUGUST 2026 · EVERY SHIPPED UNIT RE-MEASURED DURING ITS OWN BURN-IN

This site makes claims — private, local, honest. Claims are cheap. This page is the numbers behind them and the standard commands that let you check every one of them on your own unit, with no cooperation from us. Nothing below is estimated or projected; where a number can change between builds, your unit's in-box notes carry its own.

The machine

HARDWARE + SOFTWARE
compute
Raspberry Pi 5 · 8 GB RAM · quad-core Cortex-A76
os
Debian 13 (trixie) · stock kernel · systemd — no custom OS, nothing hidden
inference
Ollama / llama.cpp · bound to 127.0.0.1 only · run with --offline
chat model
Gemma 3 4.3B (Q4_K_M) · 8K context · standard published weights — hash them yourself
speech
whisper.cpp (on-device STT) + Piper (on-device voice) — no cloud speech service
app
Python / FastAPI · readable code on the device · SSH documented, never removed

Measured performance

Method noted per number. The Pi is allowed to be a Pi — we publish what it does, not what marketing wishes it did.

BENCHMARKS · 3-RUN AVERAGES, WARM
power → screen
~36 s (systemd-analyze)
power → spoken "ready"
~90 s — the boot self-test passes 7/7, then it tells you, out loud
generation speed
3.3–3.8 tok/s warm · 3.6 tok/s under sustained load
short answer
~16–19 s end-to-end (two sentences)
voice transcription
~2–5 s for a spoken question, fully on-device
ram, sustained
~6.0 / 7.9 GiB — flat across a 20-generation run, no growth
temperature
~38 °C idle · 51–53 °C plateau under sustained inference
throttling
none observed — get_throttled=0x0 at every sample

Reliability, counted

Every boot runs a 7-point self-test and appends one line to an on-device tally — reliability here is a running count, not an adjective.

PROTOTYPE TALLY · RUNNING
clean boots
10 consecutive with self-test passing on attempt 1, ~26 s in — including back-to-back reboots a minute apart
power-loss test
plug pulled without warning → full stack back unaided, zero failed units (first of the five planned before ship)
ship gate
20+ total power cycles before any unit ships, plus a multi-day burn-in per unit
if it breaks
it heals itself on a budget, narrates what it did in plain words, and never hides a failure

The wire

The central claim: in Private mode, nothing you say leaves the box. Check it with standard tools:

  1. See every open port: ss -tulpn — expect sshd, the app on 8800, mDNS, and inference bound to 127.0.0.1 only. Scan it from another machine; it should agree.
  2. Watch the wire while you talk to it: run tcpdump filtered to non-LAN traffic, then have a whole conversation. Expected result: silence. (What you will see, documented, content-free: NTP, DHCP, mDNS.)
  3. The kill test: unplug your router entirely. Chat still works. Memory still works. Reboot with no internet — it comes back and keeps working.
  4. Inspect the workers: ps aux shows the inference process with --offline and loopback bindings. The model files sit on disk in the standard Ollama layout.

The exact tcpdump filter (treats every private LAN range as local):

sudo tcpdump -i any -nn 'not (net 192.168.0.0/16 or net 10.0.0.0/8 or net 172.16.0.0/12 or net 127.0.0.0/8)'

What passing looks like during a full conversation — the only lines you should ever see, none carrying content, none to any PHNTM server (there are none):

IP x.x.x.x.123 > pool.ntp.org.123: NTPv4 — time sync (Debian default)
IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP — your router's lease renewal
IP x.x.x.x.5353 > 224.0.0.251.5353: mDNS — LAN name announcement
…and then silence, for as long as you care to watch.
The one exception, stated plainly

Boosted mode — off by default, enabled only by entering your own API key — sends those prompts to your model provider, labeled per-answer in the UI. Run tcpdump during a Boosted answer and you'll see TLS to your provider; switch back to Private and the wire goes silent again. Delete the key and it's gone from the box.

Updates, without dependence

Shipped units have no update channel — no repo remote, no phone-home, nothing polls. Updates are owner-initiated: a documented local procedure applies a signed build, runs the boot self-test, and rolls itself back automatically if that self-test fails. The device never needs our servers to keep working; there are no PHNTM servers to need.

Numbers on this page were measured on the working prototype in August 2026 and are refreshed at each release. Your unit ships with its own burn-in results. If you measure something different, email the builder — that's a bug report, and it's welcome: [email protected].