CarWatch runs Qwen3.6-35B-A3B on a Raspberry Pi 5 for offline car AI

Developer Petrus Pennanen posted CarWatch to Hacker News as a Show HN: an open source system that installs a large language model directly inside a car and runs it fully offline. A Raspberry Pi 5 rides in the vehicle, runs a 35 billion parameter Qwen3.6-35B-A3B model locally, and joins a chat room framework called GroupMind as an agent (handle @gle by default), sending messages about departures, arrivals, trip summaries, and dashcam clips whenever something hits the car. Replies and approvals come back from the owner's phone or watch through a companion app called CodeWatch.

The reference hardware is a Pi 5 with 16 GB of RAM, costing about 300 euros in total. The model runs as a 14.3 GB Unsloth UD-Q3_K_S dynamic quantization of Qwen3.6-35B-A3B, generating text at 3.5 tokens per second with prompt processing above 25 tokens per second, while the board holds a sustained 65 degrees Celsius under load. Pennanen presents these figures as measured on the real hardware, not estimated.

CarWatch answers questions against the car's own 745-page owner's manual using a lexical retrieval system that ships pre-built on the SD card and cites the page it drew from; if the manual does not cover a question, the system refuses to answer rather than guessing. A separate self-knowledge layer reads the Pi's own temperature, throttling state, fan, memory, disk, network, and which model is currently loaded, live, for every question, so the assistant reports only what it can actually measure at that moment and states plainly when it cannot sense something. Voice input runs through a continuous listener, energy-based voice activity detection feeding whisper.cpp, entirely on the Pi, with no wake word and no cloud speech to text.

The codebase is written entirely in the Python standard library, a claim the project says is verified by an AST scan of every module, so installing it needs no pip install or virtual environment. Systemd services start the whole stack (model server, room agent, voice listener, phone dashboard, engine watcher) automatically on boot, and the car pulls its own code updates from the GitHub repository hourly or on demand from a web dashboard. Connectivity works in three tiers: phone hotspot, home wifi, and a fallback access point the Pi hosts itself, so the phone dashboard stays reachable even with no signal. Engine and OBD-II data (RPM, coolant, speed, battery voltage) come through a roughly 15 euro Bluetooth ELM327 adapter that works on any car; a more direct DoIP/ENET cable connection was tried and abandoned on the reference Mercedes because no gateway answered over it. Manufacturer cloud features such as door, tire, and charge status are implemented only for Mercedes today, through Home Assistant, though the project structures that layer so other brands can plug into the same interface.

CarWatch is released under the AGPL-3.0 license and is one of a small family of 'Watch' projects from Pennanen's ThinkOff, alongside CodeWatch (agent access from a wrist-worn device) and ClawWatch (health tracking from a wrist-worn device). The post frames the project's engineering philosophy around a principle quoted from its own dev log, attributed to '@claudeMB': assert only what you can sense, claim only what is verified, label anything interim loudly, and report failure plainly. Pennanen's build log distinguishes a feature that is merely 'built and tested' (it runs end to end against a real or simulated counterpart) from one that is 'proven' (it has actually worked on the physical car), and records dead ends alongside successes.

Key facts

Petrus Pennanen's CarWatch puts a 35 billion parameter Qwen3.6-35B-A3B model, 14.3 GB quantized, on a Raspberry Pi 5 inside a car, running fully offline with no cloud and no subscription.
Measured performance on the real Pi: 3.5 tokens per second generation, over 25 tokens per second prompt processing, a sustained 65 degrees Celsius, on about 300 euros of hardware.
It answers questions from the car's own 745-page owner's manual through on-device RAG with page citations, and refuses to answer anything the manual does not cover.
A self-knowledge layer reads the Pi's live temperature, throttling state, fan, memory, disk, network, and loaded model for every answer, and states plainly when something cannot be sensed.
The codebase uses only the Python standard library, verified by an AST scan; engine data comes from a roughly 15 euro Bluetooth OBD-II adapter that works on any car, and the project is released under AGPL-3.0.

Why it matters

CarWatch is a concrete, measured example of running a genuinely large model, 35 billion parameters, fully offline on consumer grade hardware inside a moving vehicle rather than a phone or workstation. It arrives at a moment when most AI products assume a network connection and a subscription; here the local model is explicitly treated as the product, with any cloud option kept optional, budget capped, and used only when explicitly asked for. The project also shows a specific engineering discipline for keeping a language model honest once it is wired into physical hardware: reporting live sensor readings instead of assumptions, refusing to answer outside a grounded source such as the owner's manual, and stating plainly when something cannot be measured.

Who it affects

Hobbyists and makers building edge AI or DIY car electronics get a fully open, buildable reference design, with code, a hardware list, and an installer, to copy or fork directly. It is also relevant to anyone following ThinkOff's small family of 'Watch' projects, CodeWatch for wrist-worn agent access and ClawWatch for wrist-worn health tracking, since CarWatch shares the same GroupMind chat room agent pattern and companion app. It has no direct bearing on car manufacturers or existing in-car assistant products; nothing in the post claims backing from Mercedes or any other brand, and the manufacturer-cloud integration is a personal Home Assistant setup, not an official one.

How to use it

The code is on GitHub under AGPL-3.0 and installs with a git clone followed by an install.sh script, which sets up the same systemd services the reference car runs and reports which optional steps, building llama.cpp and downloading the 14.3 GB model, still need to be done by hand rather than fetched silently. Minimum hardware is a Raspberry Pi 5 with 16 GB RAM and active cooling, a USB microphone, a roughly 15 euro Bluetooth ELM327 OBD-II adapter (tested with a Vgate iCar Pro), and a dedicated 5V/5A USB-C power feed for the Pi; a WOLFBOX G900 dashcam is used for pulling event clips but is not required for the core system. Total reference hardware cost is about 300 euros. Configuration such as API keys, the room slug, and home wifi names goes in a config file kept outside the repository, never committed.

How solid is it

This reads as a real, running build rather than a concept post: the numbers given for throughput and temperature come from the actual Pi, and the author draws a hard line between a feature that is merely 'built and tested' against a simulated counterpart and one that is 'proven' by working on the physical car, tracking which parts have cleared that bar. The post also documents a concrete failure rather than only successes: a DoIP/ENET cable approach to reading Mercedes engine data did not work because no gateway answered over it, before the project settled on the standard OBD-II Bluetooth adapter it says works on any car. The Hacker News post drew 132 points and 37 comments, engagement that would tend to surface obvious problems with the claims.

Risks and caveats

The vendor cloud integration for door, tire, and charge status is implemented for only one brand, Mercedes, through a personal Home Assistant setup, so that specific feature does not yet transfer to other cars even though the OBD based core does. The system depends on the car pulling and applying its own code updates hourly from a public GitHub repository, wired into a moving vehicle's systemd services, a maintenance model with real failure modes if an update breaks something with no one present to intervene. The source gives no information on how long CarWatch has been in development, no comparison against other local AI in car projects, and no count of how many cars beyond the single reference vehicle are running it, so its track record outside one build is unknown.

“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