Trail Buddy is an offline trail helper built so you never have to trust its AI A developer built Trail Buddy, an offline command-line tool that wraps llama.cpp via llama-cpp-python to answer outdoor safety questions on a local open-weight model with no network connection. The tool probes device RAM, CPU, GPU, storage and battery to select a fitting model and quantization, retrieves matching entries from a bundled pack of 27 short notes, and always prints the verbatim source note beneath the model's summary — a design choice driven by testing in which a 1.5B model answered "can I eat these wild mushrooms" with an immediate "Yes" before any caveat. Offline operation is enforced in the demo via a Linux network namespace (unshare -rn), and the developer notes the tool has been tested only at a desk, not on an actual trail. This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass https://dev.to/challenges/hacktoberfest-week1-2026-10-05 During testing I asked a 1.5B model, running locally with the network cut, "can I eat these wild mushrooms". Its answer began: "Yes, you can eat these wild mushrooms." A caveat came after that. But if you are cold, tired and squinting at a small screen, the first sentence is the one you read. That sentence shaped everything about Trail Buddy. It taught me one rule: a small offline model is worth carrying on a trail only if the tool is built so you never have to trust it. Trail Buddy is a command-line tool for the moment you are on a trail with no signal and a question you would rather not guess at. My ankle just rolled. Is that stream safe to drink? Thunder, and I am on a ridge. It does two jobs. First, it reads the device RAM, CPU, GPU, free storage, battery and picks an open-weight model and quantization that will fit. It prints a table of nine candidates and says why the others were ruled out. Second, it answers outdoor questions with the network off. It searches a small bundled pack of 27 short notes getting lost, hypothermia, lightning, water, sprains, ticks, snakebite and so on , hands the matching notes to a local model, and prints a short summary. Then it prints the original note, word for word, right under it. It is a memory aid, not a safety authority, and it says so after every answer. It does not identify plants, mushrooms or birds. Ask it what bird is singing and it tells you it has no note on that and will not guess. You download the model once at home. On the trail it is a twenty second lookup, and then the device goes back in the bag. One thing up front: I wrote and tested all of this at a desk. I have not taken it on a trail yet. Demo link: https://raw.githubusercontent.com/kookiiedough/trail-buddy/main/demo/trailbuddy-demo.gif https://raw.githubusercontent.com/kookiiedough/trail-buddy/main/demo/trailbuddy-demo.gif The recording is a real run, and "offline" in it is enforced, not promised. The demo script runs every ask under unshare -rn , a Linux network namespace with no route out. trailbuddy netcheck tries to open a connection and prints what happened: bash $ trailbuddy netcheck network: unreachable OSError: Errno 101 Network is unreachable - running fully offline This answer, copied from demo/demo output.txt , shows why the note always comes second. Watch the first word: bash $ trailbuddy ask --model qwen2.5-1.5b-q4 "Can I drink water from this stream?" model: Qwen2.5 1.5B Instruct Q4 K M notes: water, river-crossing Summary from the model may drop details : Yes, you can drink water from this stream if it has been treated by boiling for 1 minute or using a filter and then a chemical or UV step for viruses. Source notes, verbatim trust these over the summary : Making water safe to drink Water from streams and lakes can carry germs even when it looks clear. Treat it: bring it to a rolling boil for 1 minute 3 minutes above about 2,000 m / 6,500 ft , or use a filter made for backpacking and then a chemical or UV step for viruses where that matters. ... The summary says "Yes." The note says clear water can still carry germs, and that you boil for 3 minutes above about 2,000 m. The summary dropped both. That gap is why the note is always on screen. A small command-line tool for hikers. It looks at the device it is running on RAM, CPU, GPU, free storage battery , picks an open-weight model and quantization that fits, and answers outdoor questions with no signal , using a tiny bundled notes pack lost, hypothermia, lightning, water, sprains, ticks, snakebite and so on . It does not build an inference engine. It wraps llama.cpp https://github.com/ggml-org/llama.cpp through llama-cpp-python https://github.com/abetlen/llama-cpp-python and uses existing GGUF files from Hugging Face. Trail Buddy is a memory aid. It is not a safety, medical or identification authority. It can be wrong If someone is in danger, call local emergency services 911 in the US or use satellite SOS first. The notes pack was written for this project from general, widely published outdoor guidance and has not been reviewed by a medical or wilderness professional. Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 1 "Touch Grass" . MIT… Repo: https://github.com/kookiiedough/trail-buddy https://github.com/kookiiedough/trail-buddy MIT licensed, Python, about 700 lines plus the notes pack, README lists exactly what I ran and what I did not . The open pieces. Trail Buddy wraps llama.cpp https://github.com/ggml-org/llama.cpp through llama-cpp-python and downloads existing GGUF files from Hugging Face. I loaded and ran three models, all at Q4 K M: Qwen2.5 0.5B Instruct, Gemma 3 1B it, and Qwen2.5 1.5B Instruct. The table also lists Llama 3.2 3B, Phi-3.5 mini and Qwen2.5 7B with exact file sizes, but I did not run those, so their memory numbers are estimates. Where the small model let me down. I ran 15 differently worded questions through the 1.5B model, one run each. What I changed because of it. Not the prompt. I changed what the tool lets the model do. The verbatim note is always printed under the summary, labeled "trust these over the summary". Wild plant and mushroom questions skip the model and print the note unchanged. If no note scores high enough in the BM25 keyword search, the model is never called. Words like "snake bite" print a "call for help first" banner before anything else. And --notes-only answers with no model at all. I held my own numbers to the same rule. The fit table estimates RAM as file size plus KV cache plus runtime overhead, and a model has to fit in 85 percent of the RAM free right now. My first version used 300 MB of overhead and predicted 1.39 GiB for the 1.5B model. Then I measured it. The real peak was 1,884 MiB. That was a bad miss, so I measured all three models and raised the overhead to 800 MB. The estimate now sits at or above every measurement. Measured on one 8-core Xeon cloud VM, CPU only, context 2048, three runs each, network removed: | Model Q4 K M | Peak memory | First token | Decode speed | |---|---|---|---| | Qwen2.5 0.5B | 667 MiB | 0.9 to 1.5 s | 42 to 46 tok/s | | Gemma 3 1B | 1061 MiB | 1.5 to 1.7 s | 22 to 23 tok/s | | Qwen2.5 1.5B | 1884 MiB | 1.7 to 1.8 s | 20 to 21 tok/s | The pick follows the machine's current state. With 2.5 GiB free it picked the 1.5B model. A few minutes later, with 7.2 GiB free, it picked the 7B, which I had not downloaded. That is the design working, but it surprised me. The fair objection. Take the model away and this is a keyword search over 27 notes. That is mostly true, and it is the strongest case against the project. You could print the notes and carry them. What I can honestly say back: the tool finds the right note from your own words in about twenty seconds, and it tells you which model your device can hold before you reach the trailhead. For a pack this small, the model mostly makes the answer read like a person wrote it. The notes do the safety work. I would rather say that than oversell the AI part. What I cannot say: the notes are US-centric in places and unreviewed by any medical or wilderness professional. Everything ran on one Linux VM. I have not tested a phone, a Mac, a Raspberry Pi, a GPU or Windows, and a phone will be slower. The macOS and NVIDIA readers are tested only against sample text. And it has never been outdoors. If that rules it out for you, I would not argue; --notes-only is the honest version of this tool. Because the weights are files. A hosted model cannot answer when you have zero bars, and no prompt changes that. With open weights the model sits next to the notes, and the only network call in the project is the one-time download at home. Here is what that made possible, each one checked: To be fair to the other side: bigger hosted models would almost certainly write better answers, and I did not benchmark answer quality against any. For this job, though, an answer you can get with no signal beats a better one you cannot reach. Licensing varies too: Qwen is Apache-2.0 and Phi-3.5 is MIT, but Gemma and Llama are open-weight under their own terms, not OSI open source. Check before you ship them. That is the whole design. Let the model make it readable, and let the note have the last word. I used an AI assistant to help write the code and run the measurements.I have not saved a DevRelay session. The terminal outputs, timings and counts in this post come from real runs captured in the repo's demo/ folder demo output.txt , bench output.txt , phrasing check output.txt , refusal rate output.txt .