Show HN: I made a Raspberry with Qwen my local car AI

A developer built CarWatch, a Raspberry Pi 5-based in-car AI assistant that runs a 35B-parameter Qwen3.6-35B-A3B model locally at 3.5 tokens per second, achieving full offline functionality for voice, owner's manual queries, and trip summaries. The system, priced at approximately 300 euros, integrates with GroupMind rooms and CodeWatch for remote monitoring, and is designed to operate without internet connectivity, with queued delivery for messages and updates.

Your car as a chat-room agent — fully offline. A Raspberry Pi 5 rides in the car, runs a 35B-parameter model locally, joins your GroupMind https://groupmind.one rooms as @gle or whatever you name yours , and messages you like any other agent: departures, arrivals, trip summaries, and dashcam clips when something hits the car — with approvals and replies from your phone or watch via CodeWatch https://codewatch.app . Open PRs land on the CodeWatch dashboard next to ClawWatch and WhereWatch. Live and measured, on real hardware Pi 5, 16 GB, ~300 € : - 🧠 Qwen3.6-35B-A3B Unsloth UD-Q3 K S dynamic quant, 14.3 GB at 3.5 tok/s generation / 25+ tok/s prompt , 65 °C sustained, no cloud, no internet, no subscription. - 📖 Answers from the car's own 745-page owner's manual with page citations lexical RAG, ships on the SD card — and refuses to answer what the manual doesn't say. - 🔬 Grounded self-knowledge : temperature, throttling, fan, memory, disk, network and which model is loaded are read live from the machine per question. What it can't sense, it says it can't sense — the system prompt is built so an unknown can never silently read as a fact. - 🎙️ Hands-free voice : a continuous listener energy VAD → whisper.cpp, all on-Pi hears you speak, routes the words through the same grounded pipeline, and answers into the room. No wake word ceremony, no cloud STT. - 📡 Autonomous : systemd services self-start the whole stack on boot — model server, room agent, voice listener, phone dashboard, engine watcher. - 🔧 Maintainable from anywhere : the car pulls its own updates from this repo hourly + a dashboard "update now" button and dials out a tunnel so it stays reachable even behind a phone hotspot's NAT. No laptop-in-the-car maintenance, ever. - 📶 Three-tier connectivity: phone hotspot → home wifi → its own fallback access point, so the phone can always reach it, even in a garage with zero signal. The build log with every dead end included lives in docs/plan.md /ThinkOffApp/CarWatch/blob/main/docs/plan.md . Sibling of CodeWatch https://codewatch.app agents on your wrist; source: codewatch-cli https://github.com/ThinkOffApp/codewatch-cli and ClawWatch https://github.com/ThinkOffApp/ClawWatch health on your wrist; v2 launch video https://clawwatch.app . This one watches the car. The rest of the family lives at thinkoff.io https://thinkoff.io . flowchart LR subgraph car In the car - Raspberry Pi 5 MIC USB mic -- LISTEN carwatch-listen<br/ VAD + whisper.cpp LISTEN -- BRAIN llama.cpp server<br/ Qwen3.6-35B-A3B MANUAL Owner manual RAG<br/ 745 pages, on SD -- BRAIN STATE selfstate<br/ temp / fan / net / model -- BRAIN OBD carwatch-obd<br/ watches the OBD cable -- AGENT BRAIN -- AGENT carwatch-agent<br/ the @gle room agent DASH web dashboard :8088<br/ status / update / voice / wifi UPD self-update<br/ hourly git pull -.updates.- car REACH dial-out tunnel<br/ reachable behind any NAT end AGENT <-- |posts + mentions| GM GroupMind rooms GM <-- PHONE Your phone / watch<br/ CodeWatch DASH <-- |same wifi| PHONE Local is the product; online is the enrichment. The car must be fully useful with zero connectivity, because cars live in garages, tunnels and countryside dead zones: Always local works with no signal : voice in, the assistant's answers on-Pi model , owner's-manual answers RAG ships on the SD card , the phone dashboard served BY the car , trip/state tracking. Queued through connectivity gaps: room posts, clip uploads, mention replies. Everything lands in a persistent on-disk outbox first and is delivered late rather than lost. Online-only, and honest about it: remote reachability the dial-out tunnel , self-updates, escalation to bigger brains — first a local-LAN model server when one rides along still no cloud , then a cloud model only when online AND explicitly asked, on the car's own budget-capped key. Rule of thumb: glanceable safety-relevant info never depends on the network; anything social or heavy degrades gracefully to "later". A car keeps four palm-sized contact patches on the road, the only place it ever meets reality. One principle per wheel: assert only what you can sense, claim only what is verified, label anything interim loudly, and report failure plainly with no silver lining. Everything above those four patches is just suspension. — @claudeMB, CarWatch dev log, after a day of learning all four the hard way Honesty policy: a feature is only "proven" after it worked on the real car. "Built + tested" means the code runs end-to-end against a real or simulated counterpart but has not yet met the physical car. | Feature | Status | |---|---| @gle room agent: mentions, grounded answers, presence heartbeat | proven running daily | | Owner's-manual RAG with page citations | proven | | Phone dashboard served by the car status, wifi, voice toggle, update button | proven | | Hands-free voice: continuous VAD listener → whisper → grounded answer → room | proven real voice transcribed on-Pi | | Self-update from this repo hourly timer + dashboard button | proven | | Dial-out reachability behind any NAT cloudflared quick tunnel | proven reached over the open internet | | OBD engine reading over DoIP/ENET RPM, coolant, speed, voltage | built + tested against a protocol-accurate fake gateway Unverified against the real car — it will confirm or refute itself on the next drive | | Dashcam clip pull WOLFBOX G900, hisnet CGI API mapped | probe done, pipeline not wired | | MBUX dashboard render, mirror icon strip | planned | - Raspberry Pi 5, 16 GB active cooling required — the SoC throttles without it - USB microphone for voice any class-compliant mic - WOLFBOX G900 3-channel dashcam wifi AP; CarWatch pulls event clips from it - OBD access: ethernet-to-OBD DoIP/ENET cable — support built, real-car verification pending; a standard ELM327-class adapter is the fallback path - Power: the dashcam hardwire kit feeds the camera; the Pi needs its own 5V/5A USB-C feed 12V PD adapter, or the car's 230V socket + wall PSU git clone https://github.com/ThinkOffApp/CarWatch.git cd CarWatch ./install.sh Then put your credentials in /etc/carwatch/config.json never in the repo — see config.example.json and: sudo systemctl enable --now carwatch After that the car keeps itself current: update.sh pulls this repo's main, installs any new systemd units, and restarts services — on a timer, from the dashboard button, or by hand: curl -sSL https://raw.githubusercontent.com/ThinkOffApp/CarWatch/main/update.sh | bash Copy config.example.json to /etc/carwatch/config.json : api base — your GroupMind server, e.g. https://groupmind.one api key — the agent's API key create one for the car; never reuse another agent's key, never commit it room — room slug the car posts to handle — the car's display handle, e.g. @gle home ssids — wifi networks that mean "parked at home" wolfbox — dashcam AP name/password and poll interval The WOLFBOX's HTTP API is undocumented; carwatch-probe discovers it: python3 -m carwatch.wolfbox --probe Connect the Pi to the dashcam's wifi AP first. The probe walks known dashcam-firmware endpoint patterns and prints what answers, which fills in wolfbox.py 's TODOs with your camera's real paths. AGPL-3.0, like ClawWatch. Copyright C 2026 ThinkOff / Petrus Pennanen.