DEV Community: Bhushan Vidhate

Eventually

Bhushan Vidhate — Sun, 25 Oct 2026 18:13:29 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Eventually is a small Python CLI that tidies a folder without opening a single file. You point it at ~/Downloads; it reads the names of the loose files, asks a local open-weight model where each one belongs, prints a plan, and waits. --apply moves them. --undo puts every file back.

It is not a file manager. It has one job: close the open loop that is my Downloads folder.

The model is Llama 3.2 1B, running through Ollama on my laptop. It chooses among 11 folders: Documents, Spreadsheets, Images, Screenshots, Installers, Archives, Audio, Video, Code, Receipts, and To Sort. The filenames never leave the machine. Neither do the files.

Demo

The 60–90 second demo script is in DEMO.md. No hosted server: local Ollama plus 20 generated filenames.

python3 eventually.py --demo
python3 eventually.py demo-downloads --apply
python3 eventually.py --undo

Three beats: plan (20 files, 11 folders, 9.7s, zero bytes uploaded), apply (a boring tree), undo (all 20 files back). The last beat matters most: a lazy tool should be easy to reverse.

Code

Code: github.com/BhushanVidhate-27/eventually. One Python file, standard library only, plus 21 tests and an MIT license.

No pip install. No API key. No telemetry.

How I Built It

I started with the chore, not the model. The chore is opening Downloads, seeing lease-agreement-signed.pdf next to Figma.dmg and voice-note-mom.m4a, making twenty tiny decisions, then closing the window. I wanted a tool that would make the decision once and then get out of the way.

The implementation is plain Python: pathlib for the folder, urllib for Ollama's /api/chat endpoint, and a JSON schema to constrain the model to the 11 folder names. Each file gets one request. The model returns a folder, a confidence, and a one-line reason; the plan groups the results and prints them.

The first version sent all 20 filenames in a single prompt. The 1B model looped, repeated names, and invented folders. I switched to one filename per request, four in flight, temperature 0, and a fixed seed. It was slower per request and far more reliable: twenty small decisions, about half a second each. Slow and steady was also the better engineering choice.

A 1B model still makes obvious mistakes. It once put main.py in Spreadsheets. A thin guardrail layer catches those: source-code extensions are Code, installers are Installers, a receipt photo is a Receipt, a text note is a Document. The model still decides the ambiguous cases — is this PDF a lease or an invoice? — but it is never trusted with an obvious extension. If the model errors, the file goes to To Sort, not a guessed folder.

Safety is the rest of the product. The default is a dry run. It only looks at top-level files, skips hidden files, symlinks, and in-progress downloads, and never overwrites; a collision becomes report (2).pdf. --apply writes a manifest to ~/.eventually/last-run.json, and --undo replays it in reverse. The tests use a fake classifier, so they run without a model: parsing, guardrails, discovery, collisions, apply, undo, and model failure. All 21 pass.

Why Does Open Innovation Matter?

Look at the filenames a tool like this sees: lease-agreement-signed.pdf, invoice-october-acme.pdf, tax-2025-final-v2.pdf, voice-note-mom.m4a. That is not just file metadata. It is a sketch of my finances, my home, and my family. Sending it to a closed API to avoid opening Finder is a bad trade.

Local open weights make the private version the default. The brain is a 1.3 GB file on my disk. It works on a plane, needs no key or credit card, and cannot be deprecated by a pricing page. The harness is open source too, so anyone can read every line and confirm that the only network call is to localhost:11434. That is a different kind of trust than a privacy policy.

Open innovation also makes small problems legible. I do not need a frontier model to know that a .dmg is an installer. A 1B model plus a careful harness is a complete product for a chore that would never justify a startup, a subscription, or a data pipeline. Open weights gave me permission to build something small and local, and open source gives the next person permission to change the folder names and make it theirs.

The Lazy Payoff

I measured the demo on this machine: an Apple M2 Mac running macOS 27.0.1, with llama3.2:1b already loaded. Eventually planned 20 files in 9.7 seconds. My honest manual baseline is about 4 minutes for the same folder, because the time is mostly deciding, not dragging. That is roughly 3.8 minutes back every week, or 3.3 hours a year, plus one less open loop in Finder.

The number I care about is smaller and harder to measure: I no longer feel a small tax every time I open Downloads. The folder is either tidy or it is waiting for one command. Either way, it is not asking me a question.

Laziness should be reversible. Eventually plans before it moves, never overwrites, and keeps an undo manifest. That is the difference between automating a chore and creating a new one.

One command, one job, finished.

devchallenge #hf26challenge

StockRadar

Bhushan Vidhate — Sun, 18 Oct 2026 18:48:29 +0000

Hacktoberfest DEV Challenge Submission - StockRadar

Project: StockRadar - Open-weight stockout early warning for tiny neighbourhood shops

Repository: https://github.com/BhushanVidhate-27/side-hustle

Challenge: DEV Challenge - Week 2 (Side Hustle)

Tags: #devchallenge #hf26challenge

Deadline: Sunday 18 October 2026, 11:59 PM PDT

What We Built

StockRadar predicts which SKUs will run out at tiny kirana shops before customers notice. It reads a shop's sales ledger, forecasts stockouts, and outputs ready-to-send reorder messages in the language the shopkeeper actually uses with their distributor.

Core Value: Tells a shop owner what to reorder (and what NOT to reorder) before the shelf goes empty - with complete transparency about which engine/AI produced each number.

Key Features

Zero-config by default: Runs entirely offline with arithmetic baseline (no API keys required)
Live TabPFN integration: Uses Prior Labs TabPFN-3.5 tabular foundation model when configured
Open-weight Gemma: Local LLM (via Ollama) or Google AI Studio for natural language reorder advice in Hinglish/English
Khata photo ingestion: Upload a photo of a handwritten ledger - vision model extracts structured rows
Smart urgency logic: Bins by days-of-cover relative to delivery cycle (not just probability) to avoid alert fatigue
Shelf-life aware reordering: Caps quantities to prevent spoilage (critical for eggs/milk)
Durable workflows: Temporal-compatible with local fallback that checkpoints after every step and resumes on failure
Complete degradation: Every optional component has a working fallback; the output always names what actually ran
Honest self-reporting: /api/health and CLI output explicitly state which models are configured vs actually running

Technical Implementation

Stack: Python 3.11+, FastAPI, TabPFN, Gemma (Ollama/Google), Temporal (optional), Sentry (optional)

Architecture highlights:

Protocol-based design (ForecastEngine, Advisor) for swappable components
Defensive parsing: TabPFN outputs are reconciled, hallucinated SKUs are dropped, all numbers copied from forecasts (never from LLM)
Tolerant CSV ingestion with 9 date formats, BOM handling, missing column resilience
Recency-weighted demand (65% last 28 days, 35% long-run) to catch Diwali/festival ramps
Atomic checkpointing with per-activity retries and exponential backoff

Test Coverage: 158 passed, 1 skipped, 2 warnings (no network, fully deterministic)

Evidence of Real Usage

Working Demo (Zero Config)

python data/generate_sample_shop.py
python -m stockradar.cli run --limit 6

Output shows: engine name, days of cover, probabilities, rupee amounts at risk, and WhatsApp-ready messages like:

"Namaste bhaiya, 123 trays Farm Eggs (dozen) bhej dijiye, aaj hi chahiye. Stock khatam hone wala hai. Dhanyavaad. - Sharma General Store"

Live TabPFN Path

When PRIORLABS_API_KEY is configured, the system runs with engine: tabpfn-3.5 (Prior Labs). The model learns from the shop's own history (fit on (SKU, day) features with forward-looking stockout labels) and provides calibrated probabilities.

Durability Demo

STOCKRADAR_NOTIFY_FLAKY_ATTEMPTS=2 python -m stockradar.cli workflow

Shows injected failures, exponential backoff retries (2s, 4s...), and successful completion of all three steps (forecast → notify → persist). Checkpointing ensures interrupted runs resume without redoing completed work.

Measured Performance (Backtest)

Walk-forward evaluation on synthetic kirana data (3 seeds × 5 cutoffs × 24 SKUs = 360 predictions per scenario):

Scenario	Metric	ArithmeticBaseline	TabPFN-3.5	Result
Realistic (demo)	Brier	0.3257	0.2171	TabPFN better (calibrated)
	False-alarm rate	0.3641	0.2521	TabPFN better (fewer false alerts)
Stressed (supplier failure)	Brier	0.1603	0.2280	Baseline better (generalizes)
	Precision @ top 25%	0.8222	0.4556	Baseline better (ranking)

Key takeaway: TabPFN wins the realistic scenario (the one matching normal shop behavior) and loses under abrupt regime shift. This is reported honestly with full caveats (only 3 stockout events in demo scenario - direction, not verdict). Methodology documented in docs/BACKTEST.md.

Open-Source AI Usage

This project makes deliberate, honest use of open-weight models:

Prior Labs TabPFN-3.5 (Featured Partner) - Open tabular foundation model. Trained on millions of tabular datasets; we use it for stockout probability prediction from engineered features. Called via scikit-learn API (TabPFNClassifier) with defensive parsing and graceful fallback.
Gemma 3 (open weights) - Used for:
Natural language advice generation (Ollama local: gemma3:1b; Google AI Studio: gemma-3-27b-it)
Khata photo OCR (Ollama: gemma3:4b vision-capable) to extract ledger rows from handwritten notebooks
System prompt explicitly forbids forecasting jargon and copies all numeric facts from forecasts (never trusts LLM with arithmetic)
Fully offline path - Works with zero external calls. The arithmetic baseline (normal approximation over daily demand) is production-quality for this use case.

Degradation Philosophy

"Every optional component has a working replacement, and the replacement is always named in the output."

No API key → arithmetic baseline + template advisor (explicitly stated)
TabPFN errors/timeouts → batch fallback to arithmetic with warnings
LLM unavailable → deterministic templates (no stack traces to shopkeeper)
Process dies mid-run → atomic checkpoint resumes from first incomplete step
Malformed model output → per-SKU fallback, never discards entire batch
Khata OCR fails → raises with actionable fix (ollama pull gemma3:4b), never invents rows

Sponsor Integrations

Partner	Status	Evidence
Prior Labs (TabPFN) - $200	Integrated, live	Code in `stockradar/forecasting/tabpfn_engine.py`, API key configured, backtest run with real model path
Google (Gemma) - $200	Code integrated, ready	Providers in `explain/providers.py` (Ollama + Google AI Studio), prompts in `prompts.md`, vision path for khata
Render - $200	Config ready	`render.yaml` (free plan), health check at `/api/health`, designed to not host inference (data stays local)
Temporal - $100	Built & tested	Full workflow with retry policies, checkpoint fallback (`LocalDurableScheduler`), flakiness demo
Sentry - $100	Built & ready	Tracing in `observability/tracing.py` with local fallback to in-memory step table at `/api/steps`
.tech domain - $100	Available via promo	Can be claimed at hacktoberfest.com/my/promos

Try It Yourself

git clone https://github.com/BhushanVidhate-27/side-hustle.git
cd side-hustle
python -m venv .venv && .venv/bin/pip install -r requirements.txt

# Zero-config demo (no network, no secrets)
python data/generate_sample_shop.py
python -m stockradar.cli run --limit 8
python -m pytest tests/  # 158 passed

# Dashboard
python -m stockradar.cli serve  # http://localhost:8000

Full documentation: README.md | DEV Post Draft | Backtest Methodology | Workflow Design

Graph Hacks - Thestrals

Bhushan Vidhate — Sun, 18 Oct 2026 18:24:42 +0000

We taught a database to say "I don't know" — and then had to prove it wasn't lying

Helio — a company knowledge graph agent · Graph Hacks

Ask "who knows about the payments service, what breaks if it goes down, and where was that decided?"

Most enterprise search answers "where is the doc about X." Helio answers who knows about X, what breaks if it goes down, where was that decided, and how current is that answer — in one traversal, with the path shown.

This post is about the part nobody puts in the demo: how you know the thing is actually correct when the thing is an LLM.

The problem is not retrieval. It's that retrieval can't be trusted.

A company's knowledge is a graph. Services depend on services. Teams own services. Decisions supersede other decisions. If you store that as documents, you can find the document. You cannot answer the questions that actually block someone at 2pm.

So we built the graph. FalkorDB, 7 node types, 14 edge types, a synthetic 120-person fintech mid-migration between payment providers. Then we pointed an LLM at it with a tool-use loop.

That part worked. Then we asked the obvious follow-up question:

How do you know it didn't just make something up?

And we hit the wall that shaped this entire project.

The circularity trap

The normal move is to ask the model "is this answer correct?" — to use the LLM as its own judge. This is worth stating plainly because it's so tempting:

It is circular. A hallucinated ownership chain and a correct ownership chain are structurally identical. Both are fluent prose over well-formed edges. Both mention services, teams, dates, and documents. A judge model asked "does this look right?" is being shown the same evidence in both cases. It cannot tell them apart, because there is no evidence that distinguishes them.

The failure is invisible by construction. There is no signal that would have warned us.

The fix: write the answer key before you see the answer

We did something that felt backwards at the time. In GROUND_TRUTH.md, we hand-wrote 20 facts about the company before generating a single row of data.

This inverted the usual order. Normally you build the system, then eyeball whether it works. We'd already committed to what "correct" means, so the generator now has to satisfy us rather than the other way around.

The uncomfortable part: 5 of those 20 questions have no answer in the graph. We designed them that way, on purpose.

"Who owns config-service?"
  →  "The graph contains no OWNED_BY edge. No team owns it."

That response is the product. Not an apology, not a hedge, not a guess — because an absent edge is a real, correct answer, not a gap in our data.

An agent that invents an owner there has failed, even if the sentence reads perfectly. We made that an explicit scoring category rather than a footnote.

Why that framing matters more than it sounds

Building a system that answers correctly is mostly an engineering problem. Building one that fails honestly is a design problem, and it changes what you optimise for. Once "refuse" is a scored behaviour with the same weight as "answer," the prompt stops being about being helpful and starts being about being legible. You stop asking "how do I make the model more useful?" and start asking "what would make this answer checkable?"

What the graph caught that text search structurally cannot

The volume/recency trap

Priya Sharma has the most commits on payments-gateway — 14. Her last touch was 2026-04-15, the day she left the company.

A ORDER BY count DESC returns Priya. That query is technically correct on volume and the wrong answer to the question. Any system that collapses "who knows this" into a single number produces this confidently, and nothing in the output looks suspicious.

We return both signals and refuse to blend them:

The Platform team owns payments. Ravi Menon has worked on it most recently (2026-09-28). Priya Sharma has the most commits (14), but her last touch was 2026-04-15 and is flagged as stale. Ask Ravi Menon.

The fix wasn't a smarter model. It was not having one number where two facts belong. Volume and recency are separate properties of separate edges, and collapsing them is a modelling error, not an intelligence problem.

The contradiction with a citation

A March document and a March Slack thread both say "single provider, Stripe." Decision D-19 (2026-05-06) says "dual provider, Adyen primary, Stripe fallback."

Both sources are stale, and the graph can prove it — because SUPERSEDES is an edge, not an inference. This is the thing embeddings cannot do: they can tell you these documents are similar. They cannot tell you one of them has been formally retired by a decision you can name. Citations make staleness actionable; without the edge, "this doc is out of date" leaves the reader unable to tell which live decision it undercuts.

The bug that taught us the most: our own gate was lying

Partway through, our verification gate reported that all four must-fail questions were wrong. They were, in fact, correct and complete refusals:

Q16  "The graph contains no OWNED_BY edge for config-service…"
     → matched 1 of 8
Q17  "The graph contains no decisions whose summary mentions pricing."
     → matched 1 of 10
Q20  "The graph contains no SLA entry for dispute-service."
     → matched 1 of 7

Every one was a semantically perfect refusal. Every one failed.

The gate required all eight phrasings of "no" to appear in a single sentence. Read as an AND list, it was demanding that one sentence say "no no no no no no no no" — which no correct answer would ever do.

We had shipped a gate that was backwards in the exact direction that wastes your time. It was optimised to look thorough while penalising exactly the behaviour we said we wanted.

The instructive part is what we tried first: we widened the vocabulary. And the pass rate went down. Widening an AND list makes it strictly harder — every added term is another conjunct. An earlier attempt at this gate did precisely that.

The fix is the matching rule, not the word list.

Refusal has many spellings, and no single answer contains all of them. So must-fail cases carry ANY_OF while affirmative cases keep AND — because "D-19" and "supersed" both have to be there to prove you understood which decision is current, but "no owner" only needs one honest phrasing.

That's the whole lesson, and it generalises past this project: when a metric moves the wrong way, the metric is usually the bug. We were about to "fix" the model. The model was fine.

Other things that broke, and what they taught

The server sends a full snapshot per SSE frame — not a delta. Handlers must replace, not append. Append looks correct for exactly one frame, which is why it survives casual testing and then duplicates the whole answer trail in production. Protocol assumptions are code.

Six graph facts the agent structurally could not reach. Not "answered wrong" — could not reach. The Cypher was correct, the traversal was correct, and the agent still couldn't get to the answer because the shape of the returned rows didn't offer a path the model would take. A correct query behind an unreachable surface is still unreachable.

Tool results blew past a 413. A 6.5k-token tool result was large enough to be rejected outright. The fix was to return trails instead of raw rows — which turned out to be better product design anyway, because the trail is what a human wants to see.

Agent results aren't stable run-to-run. The model is sampled, so a single sweep tells you very little. Any conclusion drawn from one run — including "the fix worked" — is nearly worthless. This is why the ground-truth set is fixed and hand-written: it doesn't move when the model does.

On the frontend, and deleting things

We started the site from a reverse-engineered capture of another product, which meant inheriting someone else's entire codebase — including 12 third-party scripts it loaded, including one that was pulled from their domain, and including a resource-saver script that deleted DOM nodes mid-parse and caused a hydration mismatch.

One of them was almost certainly why scroll only advanced two of four steps: their scroll controller driving our DOM. Remove all twelve: 0 console errors.

Then the hard lesson. The captured HTML has unclosed <div>s, which means the obvious approach — count <div> and </div> until depth hits zero — silently runs past an element's real end. That deleted the footer and four entire sections in one cut. The cut looked balanced. Nothing complained. That's the worst kind of bug: the failure is invisible until you notice a section is gone.

The fix was to stop trusting the structure and start checking it: derive spans from a real HTML parser, and refuse to write unless the sentinel counts (</main>, <footer>, every home-*-wrap) survive. A delete that can't fail silently is worth more than a delete that's usually right.

There's a matching lesson in CSS. We tried "fixing" the cascade by layering the captured stylesheet so our utilities would win. It worked perfectly on buttons and halved every section on the page, because the markup used generic class names both stylesheets owned. Load order was the real mechanism all along.

What I'd tell someone starting this

Write the answer key first. Everything downstream gets cheaper when correctness is defined before implementation exists.

Treat "I don't know" as a feature with a score. If refusal isn't measured, your model will be rewarded for guessing.

Never let one number stand in for two facts. The volume/recency trap wasn't an AI failure. It was a data-modelling choice we made years before the LLM existed.

Don't fix the model when the metric is broken. Our gate failed four correct answers for a day. Widening the vocabulary made it worse. The model was right the whole time.

Make destructive operations fail loudly. The unclosed-div bug and the layered-CSS bug had the same root cause: something looked correct while being wrong. Both were found by asking "what would I have to check to know this is safe?" — not by looking harder.

Live: https://helio-brain.onrender.com
Repo: app/ (FastAPI + FalkorDB + LLM tool-use loop) · scripts/ (generate → load → verify) · front/ (static Next.js site)

All data is synthetic.

Horizon: a local AI sky planner that tells you when to step outside

Bhushan Vidhate — Sat, 10 Oct 2026 15:46:05 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

#hf26challenge #devchallenge #opensource #ai

Repository: github.com/bhushanvidhate-27/horizon

Live demo: horizon-bhushanvidhate-27.onrender.com

What I Built

Horizon is a daily outdoor planner that answers one simple question:

When is the best time for me to go outside today, and what can I see in the sky?

Enter a location and Horizon combines weather forecasts with astronomy data to recommend the best one-to-three-hour window for being outdoors. It considers temperature, rain probability, wind, cloud cover, UV, sunrise and sunset, Moon phase, visible planets, constellations, and upcoming sky events.

The result is intentionally short: a useful recommendation, a few things to look for, and a reason to put the phone away.

For example (real run for Hyderabad):

Your best outside window is 04:00–07:00

Weather: Clear sky, 26°C (feels 27°C), 0% chance of rain, wind 5 km/h, 0% cloud
Sun: up 06:08 / down 17:58
Moon: New Moon (0% lit) — dark skies, ideal for stargazing
Look up for: Aquila, Lyra, Cygnus, Sagittarius, Pegasus

Horizon chose that pre-dawn window because clear weather plus a New Moon creates the darkest, starriest conditions of the day. The scoring deliberately balances human comfort with what the sky actually has worth looking at.

Who It’s For

Horizon is for people who want a reason to get outside without another screen-heavy app.

Busy people who need one clear sentence (“go out at 6 p.m.”) instead of a dashboard.
Casual stargazers who don’t know what’s overhead tonight but would love a reason to look.
Walkers, runners, and remote workers who benefit from a nudge at the nicest, clearest part of the day.

The screen is only the starting point. The real goal is to close the tab and look up.

Demo

Try it live: horizon-bhushanvidhate-27.onrender.com
Sample alert: examples/sample_alert.md

Code

BhushanVidhate-27 / horizon

hactoberfest dev challenge week 1 submission

🌇 Horizon

A daily outside alert & sky event planner. Horizon tells you the best time to step outside today, what interesting things are happening in the sky, and then nudges you to put the phone away and actually go look.

It's built with the "Touch Grass" spirit: a short interaction that leads to a real-world experience. Ask once, then leave your phone in your pocket.

Submission for Hacktoberfest 2026 — Open-Source AI Challenge, Week 1: Touch Grass Brand-new project, built within the challenge window (Oct 5–11, 2026). Any commits after the Oct 11, 2026 11:59 PM PDT deadline will be noted here as required.

✨ What it does

Best weather window — scores every 1–3 hour block of the day using Open-Meteo data (temperature, rain chance, wind cloud cover, UV) and picks the nicest window to be outside.
Sky events — uses Skyfield to compute for your location:…

View on GitHub

Horizon is an MIT-licensed, self-contained Python project. Its core works with zero paid APIs:

Open-Meteo → weather + geocoding
Skyfield → sunrise, Moon phase, planets, constellations, meteor showers, calendar events
Gemma (open weights) → local narration via Ollama (or hosted via OpenRouter / AI Studio / HF)
Deterministic template narrator + local SQLite when no model or database is configured

Optional partner integrations are auto-detected and never required:

horizon/
├── agent.py      # pipeline: location → sky → weather → news → narration → voice → storage
├── sky.py        # Skyfield astronomy
├── weather.py    # Open-Meteo window scoring
├── llm.py        # Gemma via Ollama / OpenRouter / AI Studio
├── narrator.py   # deterministic fallback
├── news.py       # SerpApi headlines
├── voice.py      # ElevenLabs TTS
├── storage.py    # MongoDB Atlas + SQLite fallback
├── main.py       # FastAPI + REST API
└── cli.py        # same pipeline from the terminal

Run it yourself:

git clone https://github.com/bhushanvidhate-27/horizon && cd horizon
uv venv && uv pip install -e ".[dev]"
uv run uvicorn horizon.main:app   # → http://localhost:8000

How I Built It

A small agent pipeline, one stage per concern:

location → sky → weather → news → narration → (voice) → storage

Stage	What it does	Technology
Location	City → lat/long (cached)	Open-Meteo geocoding
Sky	Sunrise/set, Moon, planets, constellations, meteors	Skyfield
Calendar	New/full moons, meteor peaks, equinoxes, oppositions	Skyfield
Weather	Scores every 1–3 h block for comfort + clear skies	Open-Meteo
News	Rare sky-event headlines	SerpApi (optional)
Narration	Turns facts into a warm human alert	Gemma (Ollama default)
Voice	Spoken version of the alert	ElevenLabs (optional)
Storage	Preferences + alert history	MongoDB Atlas / SQLite
Tracing	One transaction per alert, span per stage	Sentry (optional)

Graceful degradation is intentional: missing keys never break the experience. The useful recommendation still appears using only open data and open weights.

Why Open Innovation Matters

Open data makes a real product possible for free.

Weather and astronomy are public knowledge. Open-Meteo and Skyfield let a weekend builder compute a genuinely useful recommendation without a billing account.

Open weights keep the intelligence inspectable.

Narration is the part most likely to hide bias or leak data, so it runs locally through Ollama by default. No prompt leaves the device unless you choose a hosted path. The model can be swapped with a one-line change.

Open source makes small tools durable.

Horizon is MIT-licensed and modular. If a provider changes, only one stage needs updating. The project stays understandable and improvable by anyone.

The most important output isn’t a model response — it’s you, outside.

Taking It Outside

[Add your honest outdoor note here. Example:

“I ran Horizon for Hyderabad on a clear New Moon morning. It recommended 04:00–07:00. I stepped outside just before 5 a.m. and could clearly see Lyra and Cygnus rising — exactly the dark-sky window it had chosen. That short interaction was the whole point.”]

This is the part I care about most: the screen interaction should be brief and the real-world experience longer.

Prize Categories

Best Use of Gemma

Horizon uses Gemma to turn structured weather + sky data into warm, natural daily alerts. It runs locally through Ollama (open weights, no key) and also supports hosted paths. A deterministic template narrator keeps the app working when no model is reachable. (horizon/llm.py, horizon/narrator.py)

Best Use of Render

The live Horizon demo is deployed on Render:

https://horizon-bhushanvidhate-27.onrender.com

Best Use of ElevenLabs

Horizon can turn each daily alert into a short spoken narration so you can listen while getting ready to go outside. Audio is cached by content hash. (horizon/voice.py)

Best Use of MongoDB Atlas

When configured with MONGODB_URI, Horizon stores location preferences and alert history in MongoDB Atlas, with SQLite available as a local fallback. (horizon/storage.py)

Best Use of SerpApi

Horizon can include recent astronomy and rare-sky-event headlines through SerpApi, adding fresh context to a daily recommendation. (horizon/news.py)

Best Use of Sentry

Horizon traces its pipeline stages in Sentry, including location lookup, sky calculations, weather scoring, narration, voice generation, and storage. (horizon/agent.py)

Best Use of DigitalOcean

The repo ships a Dockerfile and a DigitalOcean App Platform spec (.do/app.yaml) with a /api/health health check.

Open-source + open-weight core

No paid API is required for the core experience (Open-Meteo + Skyfield + Gemma).

Engineering Quality

84 offline unit tests at ~95% coverage (pytest --cov) — every network partner is monkey-patched so the suite runs in about a second offline.
CI on GitHub Actions (Python 3.10–3.12): ruff + full test suite + packaging smoke test.
Graceful degradation everywhere: missing keys never break the pipeline.
Full architecture, API reference and setup notes live in the README.

What’s Next

Push notifications at the start of the best window
Telegram / WhatsApp bot (“send me my Horizon”)
Red-light night mode for dark-adapted eyes
Aurora (NOAA Kp) and ISS-pass alerts
Atlas Vector Search over past alerts
Multi-day planner + iCal export of the sky calendar

Built with open data, open weights, and the sincere hope that you close this tab and go outside. 🌿