This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
What I Built
OneBar is a low-bandwidth weather assistant for hikers. Ask a question like “when should I turn back?” and it replies with one SMS-length message based on the forecast for your location.
The language model writes the sentence, but it does not calculate the weather facts. Code computes details such as sunset, gust speed, and turnaround time; a separate checker verifies that the reply is under 160 SMS characters, includes the facts the question needs, and doesn’t introduce unsupported numbers or contradict the forecast. If a draft fails, OneBar retries once, then uses a checked template.
It’s for people who need a quick, readable answer on the trail, especially when a full weather app is inconvenient on a weak connection. OneBar is not a rescue service or a replacement for an official mountain forecast.
Demo
url: https://onebar-v46s.onrender.com ,demo video:https://youtu.be/KurEtVshOIM
Code
https://github.com/JUICEWRLD998/onebar
How I Built It
I fine-tuned the open-weight Qwen3-8B with LoRA for the specific task of writing short, forecast-grounded replies. The dataset contains 3,290 training examples and 514 validation examples, built from mountain locations and forecast scenarios. I evaluated it on 414 held-out questions, with locations separated by map cell from the training data.
On that test set, the tuned model passed OneBar’s checks on its first draft 98.1% of the time, compared with 56.8% for the base Qwen3-8B. It had no template fallbacks in that evaluation. Every answer still goes through the checker; those results are not a guarantee that a forecast or answer is always correct.
The application uses Python and FastAPI for the facts and checking pipeline, React and TypeScript for the web interface, Open-Meteo for forecast data, and Temporal for durable trip timers and overdue-contact alerts. Tinker was used to fine-tune and serve the model.
Why Does Open Innovation Matter?
Open-weight models let me adapt the model to a narrow, measurable task instead of treating a general-purpose assistant as a black box. I could fine-tune Qwen3-8B, compare it against the untuned model and a larger model on the same held-out questions, and build the product around the behavior the task needs: short answers that use facts computed by the application.
The model is only one part of the safety approach. OneBar keeps the facts and validation in ordinary code, so a model response must pass explicit checks before it is sent. That separation makes the system easier to inspect and improve than relying on a model provider’s answer alone
Prize Categories
Featured Category: Tinker
Partner Category: Temporal
Solo Builder: Mustapha Fadhlullah
Top comments (0)