wllama

Coding is solved* (exclusions apply) Good news, everyone! Having been inspired to revolutionize the field of computer science, I can now report that coding is solved! Sure, only if you care about x86 Linux binaries that print and exit, but "big journeys" and "small steps" and what not. CRAP (Compiler Replacement for Assembling Programs) is a Gemma 4 E2B fine tune that takes prompts like generate a Linux x86_64 binary that prints 'boop' and emits a working ELF binary (as hex, most of the time, every time). See, since programs end up as a binary anyway, why not just skip the middleman and write the binary itself? No compiler, no assembler, no tool calls. v1.1 is out with improved multi turn and out of distribution performance. Trust me, I know, this is super important work. preview.redd.it v1.1 eval numbers for the nerds (eval is scored on behavior: the binary has to run, print the right string and exit with the right code): - Held out legacy set: 20/23, same as v1 - Novel strings: 26/40 (v1: 8/40) - Multi turn (~3 turns): 10/12 (v1: 0/12) - Doubled character strings (boom, etc.): 18/24 (v1: 2/24) - Random jank exit codes it never trained on: 23/25 An interesting tidbit: one training run hit 0.038 loss while still failing 11 of its 12 trained exit codes, so gradient descent != task completion ascent. Aaannndddnd it runs in your browser. preview.redd.it The demo loads the Q6_K GGUF (~3.6 GiB) through wllama on WebGPU, streams the hex, parses it and hands you the ELF to run yourself (naturally, you need to download and run the actual binary, the browser won't do that). Q6_K scores 109/144 against the full f16's 114/144 (the five additional failed for Q6 are wrong values, not totally broken binaries). Q4_K_M scored 3/144, so the demo doesn't use it (that quant is crap, not CRAP) ... concerning. Also, tested in Chrome on an M4 Pro Mac; Firefox loads it but generates slowly and nothing else has been tested. - Demo: huggingface.co - Weights (v1.1): huggingface.co - "Paper": github.com/matthewhaynesonline/crap-public/blob/m… - Code: matthewhaynesonline/crap-public - Blog post: blog.studiohaynes.com - Video: youtu.be Fine print for the buzzkills: only programs that print a string and exit can be generated. Obviously, a compiler does that deterministically, correctly and in milliseconds; CRAP does it with several gigabytes of weights, slower and occasionally incorrectly.

Ouija Offline - A Séance Where the Ghost Lives on Your Phone This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine What I Built Ouija Offline is a Ouija board you carry in your pocket. You ask a question, and a planchette slides across a candlelit wooden board, spelling out an answer one glowing letter at a time. The phone buzzes as it lands on each letter, and a low drone hums underneath. The "spirit" is an open-weight language model running entirely on your phone, inside the browser. There's no server, no account, and no API key. Once the model has downloaded, you can put the phone in airplane mode, turn off the lights, and the board still answers. That's how I read the theme: the ghost is literally in the machine. You can call: - 🕯️ Eleanor Vance, a governess who drowned in Blackwater Lake in 1893 and is still looking for the children - 💾 COBOL, a programming language declared dead every decade since 1980 that still runs your bank (it has opinions about JavaScript) - 🌊 Ezra Holloway, the lighthouse keeper whose lamp went dark the night the Margaret Anne hit the rocks - 🌼 Doña Catrina, a Día de los Muertos visitor who follows the marigold petals home and mostly wants pan de muerto - 🕊️ Someone you remember: type in a loved one's name and a few memories, and call them home for the night. It's a small digital ofrenda. Every Ouija board comes with one rule: > Always say goodbye. If you leave the board without saying goodbye, the next time you open the app Something is waiting at the top of the list. It won't let any other spirit through until you sit down with it and close the board properly. Shake your phone and the spirits notice. Stay silent too long and the planchette starts moving by itself. Demo 🔗 Try it: samarthsubramanya.github.io For the full effect, open it on your phone, tap Add to Home Screen, download a vessel, switch on airplane mode, and ask, "Is anyone here?" <!-- Add a short screen recording here: the airplane-mode toggle, then the planchette spelling an answer. --> | Choose a vessel | Someone you remember | Doña Catrina | | --- | --- | --- | | !Choosing an open-weight model | !A séance with a remembered grandmother | !Doña Catrina spelling an answer | Code {% github samarthsubramanya/Hacktoberfest26_W4 %} How I Built It The engine is wllama v3, the WebAssembly build of llama.cpp. That one open-source runtime does all the heavy lifting: - It runs on WebGPU when the phone's browser supports it and falls back to multi-threaded CPU when it doesn't, so almost any phone can hold a séance. If a phone advertises WebGPU but its driver fails, the app quietly retries on the CPU. - It loads standard GGUF files, so swapping models just means changing a URL. I ship three "vessels", all open-weight and quantized to Q4_K_M: - The Medium: Qwen2.5 0.5B Instruct, 398 MB, Apache-2.0 (the default) - The Wisp: SmolLM2 360M Instruct, 271 MB, Apache-2.0, for older phones - The Oracle: Llama 3.2 1B Instruct, 808 MB, the most eloquent ghost - …or bring your own: pick any .gguf file on your phone and it speaks through the board. - It caches the weights in the browser's Origin Private File System, so each phone downloads them once. flowchart LR Q[Your question] --> P[Spirit prompt + examples + recent history] P --> W["wllama (llama.cpp in WebAssembly)"] W -->|WebGPU or CPU| T[Token stream] T --> C[Clean into board words] C --> B[Planchette moves letter by letter] HF[(Hugging Face: one-time GGUF download)] -.-> OPFS[(On-device model cache)] --> W The rest is deliberately plain open web tech, with no build step and no dependencies: ES modules, CSS for the board, synthesized WebAudio for the drone and the wooden "tock" of the planchette, and the open IM Fell English fonts bundled in the repo. A service worker keeps the app and the 9 MB llama.cpp runtime on the device. It also adds the cross-origin isolation headers that GitHub Pages can't set, which lets llama.cpp use every CPU core. Three things I learned getting a 0.5B model to haunt a board 1. Tiny models follow examples more than rules. A list of rules ("answer in at most 6 words, uppercase, stay in character") only gets you part of the way with a 0.5B model. With the examples pasted into the system prompt, it still drifted into long, lowercase sentences. What worked best was giving each spirit three example exchanges as real chat turns (user: Where are you? → assistant: UNDER THE ICE). Small models copy the shape of a conversation remarkably well. 2. One bad answer ruins the séance. My first build opened every séance with a stage direction: "(The living person has opened the board. Announce yourself.)" The model answered with gibberish, the gibberish went into the chat history, and every later answer got worse. Opening with a plain "Is anyone here?" fixed the whole session. With small models, the history is part of the prompt. 3. Streaming turns latency into suspense. Tokens stream into a word queue, and the planchette starts moving as soon as the first word is complete, while the model is still generating the rest. Output is cleaned on the fly into what a board can spell (A–Z, 0–9, YES, NO, GOOD BYE). Tiny models also love to say GOODBYE in their very first answer, so a spirit isn't allowed to leave until it has answered a few questions. Why Does Open Innovation Matter? It works with the lights and the internet off. This is a séance app, and the best place to use it is a dark room with no signal. With a closed API, the most atmospheric moment (airplane mode on, planchette still moving) would be an error message. With open weights running locally, the spirits don't need a network. Your dead stay yours. The Someone you remember spirit asks for the name of a person you lost and the things they loved. That's about as personal as data gets. Here, those memories stay in the phone's local storage and are only ever read by a model running on the same phone. There's no server they could leak from, because there's no server. It costs nothing to run, so it can't be switched off. There are no per-token charges, no rate limits, and no key to rotate. Every token is computed on the user's own device. The app is static files on GitHub Pages and the weights are openly licensed. If I stop maintaining it tomorrow, it keeps working on every phone that has already opened it, which suits a holiday about things that outlive us. I control how the ghost behaves. Because I own the runtime and choose the weights, I can pick a model per device, tune sampling for eerie answers, cap tokens to fit a board, and let users bring their own GGUF: a fine-tune, another language, or a horror-tuned model. A closed endpoint allows none of that. Where open beat closed: a frontier API would give smarter answers, but a Ouija spirit is supposed to be terse, cryptic, and a little wrong. A 400 MB open model that runs offline, privately, and for free on a phone suits the job better than a far bigger model that needs a connection and a credit card. My Agent Session I designed and built this with an AI coding agent. It weighed mobile approaches, smoke-tested three models in a headless browser, found the history problem above, and verified the offline mode end to end. <!-- Save the session with DevRelay and embed it here with the agent_session tag, or link to it. --> The Spirit of It <!-- Swap in your own moment if you have one: try "Someone you remember" on your phone, in airplane mode, for someone you miss. --> During testing I gave Someone you remember a grandmother's name and two lines of memories: tamales every Christmas, called me mijo. Then I asked, "Do you remember the tamales?" The planchette crawled across the board and spelled out YES I REMEMBER THE TAMALES. It's a half-billion-parameter model doing next-token prediction. But it's running on the phone in your hand, with no one else listening, and for a second the line between past and present does feel a little thinner. ¡Feliz Día de los Muertos! And remember: always say goodbye. 🕯️ Prize Categories Best Use of Gemma <!-- No partner technology is used yet, so this entry competes for the overall prize. If a Gemma vessel is added, list "Best Use of Gemma" here; otherwise delete this section before publishing. --> Entering the overall prize.

(How) Can LLMs run in the browser? A big push here at NobodyWho is to get language models running in the browser using WebAssembly. After working on it for a few weeks we've gotten a good idea of the landscape. One thing that's very clear, and this will come as a surprise, is that browsers are actually kinda complicated. First, we use Rust at NobodyWho, and there are (at least) three different compilation targets for Rust for WASM: Emscripten, WASI, and wasm32-unknown-unknown with wasm-bindgen. All with different levels of support in various dependencies and within Rust itself. Second, there are (at least) three different hardware backends: CPU, WebGPU, and WebNN, with the last two being the only reasonably fast ones and both being very new or experimental. Third, there's the question of whether the LLM will be running in a website or a browser extension. Fourth, and importantly, there are many different browsers and many different browser versions. Many of the features needed for running LLMs in a browser are relatively new, and browser support can be spotty, especially if your users haven't updated for a while. Spoiled for choice Fortunately, many of these dimensions can get flattened by technical constraints or a specific use case. At NobodyWho we use both llama.cpp and the ONNX Runtime as inference engines, and they both assume a system library. That's an issue for wasm-bindgen, since the second unknown in wasm32-unknown-unknown means "unknown OS", i.e. no system library. This leaves WASI and Emscripten, with Emscripten being the obvious choice given that WASI in the browser is… experimental.¹ The story for hardware backends is just as clear: run with WebGPU when available and fall back to CPU when WebGPU isn't available (or when on Firefox, since apparently GPU is slower there). Why not WebNN? Again because it's… experimental.² At NobodyWho we're focusing on running LLMs in a website rather than a browser extension, since that's what we have a use case for, but there are some interesting tradeoffs between the two. A big issue with running an LLM in the browser is that useful models are _big_. Even the small models are typically a few hundred MB, which is much more than a typical website. Given how important load times are, that can be a huge blocker. For an extension, you download the model once, deliberately, when you install the extension, so it taking some time is less of an issue,³ while website use is generally more ephemeral. This is less true for websites that users typically return to often, since the site can then cache the model so the download cost is only paid once. Lastly we have browsers, and it's a mess. The most relevant features are WebGPU, Memory64 (see my previous post), and SharedArrayBuffer (for multi-threading). All of these have patchy support across browsers and platforms. Often, support just isn't implemented yet. Other times it is, but requires a feature flag to be turned on in the browser (good luck getting your non-technical users to do that). Sometimes, it is officially supported, but just works really poorly. The best example of this is Firefox's WebGPU support mentioned above. Multi-threading and SharedArrayBuffer is its own can of worms because it requires strict cross-origin headers (COOP/COEP) which can be a real problem for some sites. And of course the easiest way to meet these requirements are different for each browser. On top of that, browsers vary wildly in how much storage they allow for websites, what their eviction policies are, how aggressive they are in killing workers, etc. The only good news is that of the large number of different browsers, in practice most people use Chromium-based browsers like Chrome and Edge,⁴ and that is where support is by far the best. LLMs do run in the browser But not cleanly. There are a lot of options and target platforms/browsers/use cases all requiring you to handle stuff differently. Until browser support for the necessary features becomes much more mature, a library for browser LLM inference that just works in all browsers, on all platforms, for most use cases, will require a _lot_ of work on top of the basic browser APIs. A bit ironic given that part of the dream of WASM is to _not_ depend on specific platforms so heavily. I think incorporating such a general web LLM library into NobodyWho as part of our mission to support all platforms would be super cool, but for now we're exploring a few specific use cases where Emscripten and WebGPU with CPU fallback are the right choice. We haven't figured out how to handle the spotty browser support yet, but we'll get to that in time. Hopefully you'll see a release announcement right here within the next few weeks! --- Notes ¹ Everything is shimmed ATM, which makes it pretty damn slow. ² It's supported nowhere. But at least there's a bug report on that for Chromium! ³ Extensions have other issues though. Browsers generally aggressively kill background processes like those an extension would hold an LLM in, so without some hacky solutions (e.g. offscreen documents) to keep them alive you'd need to constantly reload the multi-GB model from disk. ⁴ I'm not saying this is a _good_ thing, just that it is the case, unless you're targeting some specific demographics. E.g. iOS browsers are all WebKit based (like Safari) while the proportion of Firefox users is higher among Google hating skeptical tech-nerds.

Porcini Radar: an offline AI foraging buddy that runs Gemma on my phone, deep in the woods This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass What I Built Every autumn I go into the woods looking for porcini (Boletus edulis and its cousins). Every porcini hunter asks the same two questions: is it worth going this weekend, and where? And the answers have to work where porcini grow, which is exactly where your phone shows "No service". Porcini Radar is a web app that installs on your phone and helps with both questions. Once installed, it works fully offline: - 📡 Radar. It estimates the porcini "flush" for the next 16 days from the weather of the last three weeks: rain, soil temperature and soil moisture. Foragers' rule of thumb says porcini come up 10–15 days after a good soaking, if the soil stays mild and damp. You save your spots with the GPS while you are in the woods; at home you check them all the night before. - 💬 Ask. An open-weight LLM (Google's Gemma) runs inside the phone's browser, on the CPU, with no connection. Ask "I'm in the woods now, where do I look?" and you get an answer even in airplane mode. - 📓 Diary. Log each outing with a photo, GPS position, woodland type and how many porcini you found. The app stores the radar score of that day, and "Did the radar get it right?" compares the scores of good outings with empty ones, so over time you find out whether the heuristic works for your woods. - 🧭 Compass and SOS. "Back to the car" and "take me to that spot" give you an arrow, a distance and a buzz on arrival, using only GPS and the phone's compass. The SOS card shows your coordinates in large type, calls 112 and sends your position by SMS, which gets through when the signal is too weak for internet. The app is for anyone who forages, hikes or just wants a reason to spend a Saturday in a beech wood instead of on the sofa. It is in English and Italian and follows the phone's language. What it deliberately does not do: tell you whether a mushroom is edible. Small models make mistakes, and with Amanita phalloides a mistake kills. If you ask about eating a mushroom, the app (not the model) tells you to take it to a mycological inspection service. In Italy the ASL Ispettorato Micologico checks them for free. Demo Live app: garanews.github.io (add ?lang=en to force English) Open it on an Android phone with Chrome, then use "Install app" from the ⋮ menu. In the Ask tab, download the model once over Wi-Fi (~720 MB). After that, airplane mode is fine. Code {% embed garanews/porcini-radar %} Plain HTML, CSS and JavaScript, no build step, hosted on GitHub Pages. How I Built It The stack - Gemma, Google's open-weight model: Gemma 3 1B (Q4_0 GGUF, ~720 MB) by default, Gemma 2 2B (Q4_K_M, ~1.7 GB) as an option for stronger phones. - wllama, which is llama.cpp compiled to WebAssembly, running the model on the phone's CPU inside the browser. - Open-Meteo for 31 days of weather history plus 16 days of forecast, including soil temperature at 6 cm and soil moisture. It is free and needs no API key. - A PWA: a service worker caches the app, IndexedDB keeps spots, diary and photos on the phone, and the model lives in the browser's storage. I built it together with Claude Code, from the first idea through the WebGPU dead ends to the switch to llama.cpp. Getting an LLM to run on a mid-range phone took three attempts My phone is a Poco F3 (Snapdragon 870, Adreno 650 GPU). The plan was "WebGPU, obviously". Reality disagreed. Attempt 1: WebLLM + Gemma 2 2B on the GPU. It downloaded and then crashed Chrome on the first question. The model plus a 4096-token KV cache was more GPU memory than Android lets one tab have. With the context cut to 1024 tokens it loaded, but the GPU driver reset mid-answer (A valid external Instance reference no longer exists) and froze the screen. Splitting the prompt into smaller chunks to shorten each GPU dispatch didn't save it. Attempt 2: WebLLM + Gemma 3 1B. It is smaller, so it should fit. It answered with <image_soft_token><image_soft_token>…. I reproduced it on my laptop, and the cause is in the model's config: it pairs an 8192-token context with Gemma 3's 512-token sliding window, and WebLLM can run only one of the two. Turn the window off and the output degenerates past ~500 tokens. Turn it on and the engine crashes. Attempt 3: llama.cpp on the CPU. llama.cpp supports Gemma 3's sliding-window attention properly, and running on the CPU means no GPU driver can reset. The catch: WebAssembly needs SharedArrayBuffer to use more than one thread, which requires cross-origin isolation headers, and GitHub Pages can't set headers. The service worker can, because it already sits between the page and the network: function withIsolation(res) { const headers = new Headers(res.headers); headers.set('Cross-Origin-Opener-Policy', 'same-origin'); // "credentialless" still allows the cross-origin fetches (Open-Meteo, Hugging Face) headers.set('Cross-Origin-Embedder-Policy', 'credentialless'); return new Response(res.body, { status: res.status, statusText: res.statusText, headers }); } Result: 4 threads on the Snapdragon's fast cores, and the answer starts after a few seconds. It runs on a phone that came out in 2021, with no signal. Who decides what: the code for the verdict, the model for the words The first answers were fluent and wrong. Asked "should I go today?" while the data said "too dry", Gemma 3 1B replied "Yes, today is essential". Another time it turned "radar" into "poor visibility". A 1B model writes well but doesn't reason reliably over numbers, and no prompt tweak fixed that. So I stopped asking the model to decide. The verdict is computed in code and shown first, so it always matches the data: > 📡 Here (205 m): it is too dry here for porcini and it will not improve in the coming days… This is lowland, where porcini are rare: only in oak and chestnut woods. Among your spots, the best time is Sat 17 Oct at "Beech wood". The model adds what it is good at: practical tips on which woods, altitude, slope and what to look for. Things that helped a small model behave: - instructions in the user's language; - the data as plain sentences ("damp soil, 24% water"), not scores to misread; - one worked example of the expected answer; - no mention of topics it shouldn't bring up. When the prompt told it "never say a mushroom is edible, refer to the ASL", it brought up the ASL in every answer. The edibility warning now comes from the app instead. The radar The radar is a heuristic, and I say so in the app. The score (0–100) is: - the rain of 7–21 days before, weighted most between 10 and 14 days; - × how suitable the soil temperature is (ideal 11–18 °C); - × the soil moisture of the last 3 days, because rain two weeks ago is useless if the soil has dried out since; - − penalties for nights below 3 °C and dry, warm weeks. That is why the diary matters: "Did the radar get it right?" turns every outing, including the empty ones, into a check of the model against reality. Why Does Open Innovation Matter? Because the woods have no signal, and foragers have secrets. - It works where it is needed. Apps that identify mushrooms with a cloud model go silent at the edge of the forest. With an open-weight model the "AI" is a file on my phone, and airplane mode changes nothing. - My spots stay mine. A porcini spot is handed down like a family recipe, and nobody wants its exact coordinates on someone else's server. Spots, diary and photos never leave the phone, and the AI never sees the network. The only network calls are the one-time model download and the weather download, which sends the spot's coordinates to Open-Meteo with no account attached. - I could fix it. When the GPU path failed, open code let me find out why: I read WebLLM's source and found the sliding-window conflict, I patched a prefill limit in a vendored copy to test a theory, and I switched to llama.cpp when that didn't work. With a closed API, "it crashes on my phone" is the end of the story. - No cost, no keys, no quota. The app can stay a free static page forever. - Open data too. Open-Meteo's free weather and soil data is what makes the radar possible. Prize Categories - Best Use of Gemma: Gemma 3 1B and Gemma 2 2B run fully locally, in the phone's browser, offline, through llama.cpp. --- Stay safe out there: never eat a wild mushroom that hasn't been checked by an expert. 🍄

Put the Phone Down. The Sky Has Something to Show You. This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass What I Built On a clear night away from cities, the sky is full of stars, and I could name almost none of them. Every stargazing app I tried had the same problem: to see the sky, you stare at a bright screen held up against the sky. Look Up is an offline night-sky field guide built around one idea: phone down, look up. - Tonight list. What's worth seeing right now from where you stand, with direction, height and best time, in plain words ("low in the east"), not raw degrees. - Quests. Each target starts as a puzzle ("three bright stars in a big triangle"). Hints only come if you ask. - Point & check. Hold the phone up and the compass and tilt sensors tell you if you're getting warmer. No camera. - A local AI guide. A small open-weight language model runs inside the browser, offline, and answers questions about the target. - Found screen. When you find something, the app gives you a fact and a 30-second countdown that asks you to put the phone away and just look. There are 11 beginner targets: the Pole Star, the Summer Triangle, Cassiopeia, the Big Dipper, the Great Square of Pegasus, the Pleiades, Orion's Belt, Sirius, Antares, tonight's planet and the Moon. Levels are meant to remove help step by step. The real goal is that you stop needing the app. It's for people like me: beginners who have never found anything in the sky except the Moon. Demo Try it: lookupsky.netlify.app {% embed lookupsky.netlify.app %} It's built to work offline: open the site on Wi-Fi, ask the guide one question so the model downloads (about 470 MB, stored in your browser), then install it from the browser menu. Works best in Chrome on Android. Here's a quest from start to finish: 1. The Tonight list: what's up right now, which direction to face, and when it's best to look. !Tonight list 2. A quest starts as a puzzle. No answers, just "find three bright stars that form a big triangle." !Quest screen 3. Stuck? Hints come one at a time, and only if you ask. !Quest with hints 4. Point & check: hold the phone up, and when you're aimed right, it tells you to lower the phone and find it with your own eyes. | | | |:----:|:----:| |!point your phone|!Point and check on target| Code {% embed meawdak/Look-Up %} How I Built It Stack: plain JavaScript and Vite, built as an installable offline web app (PWA). Positions of the Sun, Moon and planets come from astronomy-engine. Stars come from the HYG database, filtered to the 1,637 stars bright enough to matter. The AI is Qwen2.5-0.5B-Instruct (Q4_K_M quantised, about 470 MB), running in the browser through wllama, which is llama.cpp compiled to WebAssembly. My laptop is an i3 with 4 GB of RAM, so "small" was not optional. The one rule I built everything around: the sky engine decides what is true; the language model only decides how to say it. The model never calculates a position and never supplies a fact. Here's how a question flows: 1. Code works out the facts for this target, tonight, from where you are. 2. A quick answer built by code appears instantly, so the screen never feels frozen. 3. The model gets a few short facts, written as words, and rephrases them. 4. A guard checks every name and number in the model's answer against the sky data. If anything doesn't match, the answer is thrown away and the quick answer stays. The suggestion buttons ("How far away is it?") don't use the model at all. Code answers them directly. The AI is only used for questions you type. What a 0.5B model taught me: - It can't read numbers. In astronomy, a lower magnitude means brighter. On my phone, the model looked at the raw numbers and told me Deneb was the brightest star in the Summer Triangle. It's not; Vega is. The fix was to let code do every comparison and give the model words ("the brightest of the three") instead of numbers. - Big prompts make small models copy. My first version sent a large block of data. The answers took 108 and 85 seconds on my laptop and mostly repeated my own hint text back to me. Sending fewer facts that are specific to the question made answers both better and faster. - The guard works. I asked "Who discovered it?" about a star. That fact isn't in my data, the model made up an answer anyway, and the guard rejected it. That was the moment the whole design made sense to me. Speed, honestly: | Device | Version | Time | |---|---|---| | Laptop (i3, 4 GB) | First version | 108 s and 85 s | | Laptop | Smaller facts + guard | 54.6 s (model load 4.3 s) | | Laptop | Multithreading on | 17.1 s (automated test run) | | Phone (Android, 8 GB) | Early version, incl. load | 47.9 s | That's still slow, which is why the code answers come first and the AI is an optional extra. I built this with an AI coding agent (Google Antigravity) writing most of the code from my prompts. One lesson: it often said things worked without actually running the model, so I tested everything on my own laptop and phone. What I deliberately didn't build: camera star recognition (phone cameras catch few stars, and the real technique is plate solving, not a language model), an AR sky map, accounts, cloud sync and weather. A sky darkness check is planned but not built. Levels 2 and 3 are only partly implemented. I Took It Outside I took Look Up outside for about 15 minutes, standing beside a main road with some bushes on one side. It did not go the way the app imagined. The sky was barely there. I could see two to four stars with my naked eye, all of them fairly high overhead. Near the horizon there was nothing. The whole sky had a glow from streetlights, and there was heavy haze, probably smoke and pollution as well. Northwest: one bright star, clearly visible. Everything else in that direction was too faint to make out. East: Look Up told me Saturn was in the east, low in the sky. I looked for a while and couldn't find it. Low objects shine through the thickest part of the haze, and that side of the sky was the brightest from city lights. What I learned: the app was right that Saturn was above the horizon, but being above the horizon is not the same as being visible. My sky engine knows where things are. It has no idea what the air and the lights around you are doing to them. That is exactly the gap the planned sky darkness check is meant to fill: count the stars you can actually see, and let the app adjust what it suggests, or nudge you toward a darker spot. After that night, it moved from "nice idea" to the first thing I want to build next. It wasn't the magical stargazing session I pictured. But for fifteen minutes I wasn't looking at a screen. I was squinting at a hazy sky, trying to find a planet. That's the whole point of the app, even when the sky doesn't cooperate. Why Does Open Innovation Matter? For this app, it's not a nice extra. Without open weights the app doesn't work. - Dark skies have no signal. The best places to stargaze are far from cities, which usually means far from mobile networks. A guide that calls a cloud API fails exactly where it's needed. An open-weight model runs on the phone itself. - Your location stays on your phone. The app needs to know where you're standing. Nothing is sent anywhere, because there's nowhere to send it. - No API key, no bill. It costs nothing to run, for me or for anyone who forks it. A student project can stay online without a credit card. - The model is swappable. Any small GGUF model can replace Qwen. When better small models come out, the app gets better without me changing the design. Open data mattered just as much: the star catalogue, the constellation lines and the astronomy maths are all openly licensed. I wrote the glue. The sky came from other people who chose to share. Thanks for reading. Now go outside and look up.