Show HN: Our space game has a built-in RISC-V emulator that runs Linux https://ift.tt/dLXxV6f

Show HN: Our space game has a built-in RISC-V emulator that runs Linux We're a tiny indie studio, all with a background in the demoscene and for about 3 years now we're developing a space planet terraforming game called SEEDS - Echoes Beneath the Sands. Our protagonist Naxiah is stranded on a small, desolated planet. You're working for an intergalactic distributor of seeds and terraforming equipment, to kickstart new planets in far away galaxies. You must deliver seeds and utilities to an unchartered region, but on your way, you crash on a small planet. Luckily, you have some equipment with you in the ship, so you're able to spawn a base and survive. But for how long? And is the planet really deserted..? :) Well, of course not, there are aliens and other space creatures. And of course, there's ROBO RB-23, which accompanies your adventure. The game is written in Object Pascal and uses our own game engine PasVulkan, our own physics engine, as well as our own RISC-V 64-bit emulator PasRISCV. We love to build stuff, a lot of these things are FOSS. The emulator is quite complete (even with RVV, but that's way too slow emulated to be useful) and runs a stock kernel (6.18.3 as of today). We're using Alpine Linux for our base distribution. All our in-game programs to interact with the planet are native RISC-V Linux programs. We also have our own (free and open source) scripting language POCA (class and prototyped based, JS/Lua inspired, which makes it quite easy for us to script things like HUD, animal behaviour, our story flow graph, etc. We have most of the wiring ready for players to be able to program and reshape and populate the whole planet in automation, although it's not our primary concept for the game (building stuff by hand, making the planet beautiful is also fun). As it's a normal Linux system, you'll be able to use Ruby, Python, or even Rust, C, C++, and Go to change and automate your world. We're also thinking of making a bunch of small games which you can play inside the game, in the base on a computer, on an arcade machine, or in the spaceship. And of course, it also runs DOOM. We already prototyped a small 2D space shooter and a small arcade game, both playable within the game. We also feature a table with hologram games to be played, e.g. chess and a certain block game. We also plan to make this hologram game engine available from the computer, which means, you'll even be able to program own hologram style games. We generally want to make the in-game computer more hackable in future, so that people can create and share their own little games. Currently, it's only a sandbox game (with beginnings of automation), to build stuff with our pre-made items. You can also assemble these to other, ready-made and shareable bigger items. This is the foundation for us to further develop survival and complete our story mode. Our game is still under active development, and we finally got our Steam page ready. We have tons of other things planned, but right now, it's more about polishing and quality for the Early Access. You can watch some videos and screenshots on our website. And we'd love to read your thoughts about his. It has been quite a ride, so far.. https://againstallodds.games/ October 2, 2026 at 05:40PM

Show HN: Arda – Marketing agents to help brands win Google and AI Search https://ift.tt/pXUtArg

Show HN: Arda – Marketing agents to help brands win Google and AI Search https://www.ardainc.com October 3, 2026 at 12:48AM

Show HN: We built a real-time desktop companion for patient's telehealth visits https://ift.tt/BxKkoEu

Show HN: We built a real-time desktop companion for patient's telehealth visits Hey HN, Some friends and I built an app called Sidekick that joins your telehealth visits in real-time. It explains medical terms and suggests useful questions, including ones you may not have thought to ask. After the visit, it provides a summary including next steps, so you can focus on the conversation instead of taking notes. The idea of Sidekick came from our team's experiences with healthcare. Our founder, Rahul, had stage three cancer at 17. His mom had to manage everything around his care: taking notes through treatment, figuring out what questions to ask, etc. A decade later and he’s now in remission, but still sees a lot of specialists and deals with the same challenges. Another teammate became a caregiver after his dad had a severe stroke. He found himself taking notes, looking up medical terms, and trying to keep track of what was said during every doctor visit. Others have dealt with situations like this when navigating pancreatitis and other serious health issues. These experiences got us interested in how we might be able to reduce the burden on the patient or caregiver. A lot of products focus on simply recording or summarizing the visit. That's useful and a step in the right direction, but we kept coming back to the fact that a lot of the challenge originates while the conversation is still happening. If you can catch something in the moment, you can address it with your clinician immediately and potentially lead to better outcomes. If you realize you missed something after the visit, then you have to try to get another appointment (and in SF I often can't get another doctor visit till 2 months later). So we built Sidekick, to help patients and caregivers during a visit in real-time to translate medical jargon and suggest useful questions, ideally without becoming a distraction. If you want to try it, you can download it on our website. Sidekick is desktop-only for now, but we’re working on a mobile app for in-person visits. We would be especially interested to hear feedback on the live part of the experience. What are your thoughts on the balance between live help vs after-visit? Would something pre-visit be more helpful? https://openhand.health October 1, 2026 at 09:27PM

Show HN: Open-source model routing for coding agents at Astra-level performance https://ift.tt/Nt8nf49

Show HN: Open-source model routing for coding agents at Astra-level performance A few months ago we started building a model router for coding agents because we thought we could outperform any single model with an ensemble approach. Recently we’ve achieved that milestone and I want to talk about how we did it. First of all, a quick explanation: the Weave Router ( https://ift.tt/1Bd0Cgu ) plugs into any coding agent (e.g. Claude Code or Codex) and intelligently switches between LLMs. So, for example, Astra handles tricky debugging or complex system design tasks, and Deepseek v4 Flash handles simple frontend updates. What we’re announcing today is our new routing model, which we’re calling Weave Router 2.0. We benchmarked 2.0 against GPT-6 Astra on Terminal Bench 4.0 and SWE Atlas. On both benchmarks, the router had equivalent pass rates. On Terminal Bench, the router hit 52% of Astra’s cost, and completed tasks 2.2x faster. On SWE Atlas, the router cost 54% as much as Astra and ran 2.5x faster. (Full results on our website at https://ift.tt/VugHikQ !) It turns out training a model to route effectively - taking into consideration model capabilities, costs, cache awareness, and more - is a really hard problem! I want to talk about three ways we were able to improve so much over the last few months: 1) a new architecture, 2) larger training data set size, and 3) smarter cache-eviction impact calculation. 1) a new architecture. Our initial approach used an RL model without many priors. While RL is still an important part of the story, the cost of fully exploring the space of routing decisions is very high, so we’ve taken some shortcuts that have significantly improved performance. Consider how large the search space for the routing problem is. Take a typical coding agent session, with ~100 agent turns (i.e. 100 LLM API calls). Technically there are 100 chances to select a model. If we assume a roster of ~10 models (of course there are lots more but we can remove any that are Pareto dominated), then there are 10^100 possible paths through that session. We simply cannot explore all of them! So that's why clever tricks to shrink this space are so important. In particular: we trained a hidden Markov model to trace the session state, then a classifier maps the session to one of a few buckets of similar models. Using the HMM allows us to evaluate not just where a session is currently, but how it got there . We've gotten significantly better performance on bucket selection by incorporating that information - we believe this is because two sessions that might look quite similar to a naive classifier are much better distinguished by this HMM approach. Using this HMM + classifier to select a bucket first significantly shrinks the space to explore, by throwing out most models that could not reasonably serve the given session. This rearchitecture was the single biggest performance unlock! 2) larger training data set size (much less technically interesting but still an important part of the story). By using frontier LLMs to help us label a larger and more diverse set of coding agent sessions, we were able to bootstrap the two models discussed in 1) to a better state, while also providing even richer reward signals for RL. 3) smarter cache-eviction impact calculation. One of the hardest parts of routing well (if you care about saving money) is using the model caches intelligently. We built a subsystem that can calculate the expected value of switching models (and thus paying a high one-time cost to fill up a different cache) much more accurately, helping us avoid costly and unnecessary switches in more cases, while still switching when the benefit outweighs the cost. This is where most of our improvement on cost has come from. We still have a lot of room to continue to improve (we won’t rest until we’re consistently beating Astra/Fable, not just tying!) but matching frontier model performance was a huge milestone for our routing model, and in my opinion validates our initial hypothesis that an ensemble of models can do better than any single model ever could. Our router is open source ( https://ift.tt/1Bd0Cgu ) so anyone can try it out. Or if you prefer you can use our hosted version ( https://ift.tt/VugHikQ ). September 30, 2026 at 11:58PM

Show HN: Gutsy, a 0.8B Jev-compatible decision model that runs on your CPU https://ift.tt/sAZMfLY

Show HN: Gutsy, a 0.8B Jev-compatible decision model that runs on your CPU https://ift.tt/xbHn8ep October 1, 2026 at 10:44PM

Show HN: Dental Scope – Interactive 3D dental anatomy https://ift.tt/dhEpx8V

Show HN: Dental Scope – Interactive 3D dental anatomy https://ift.tt/VNecL2T September 29, 2026 at 07:47AM

Show HN: WattzGOAT – an intentionally vulnerable web app for security training https://ift.tt/w8KpmH3

Show HN: WattzGOAT – an intentionally vulnerable web app for security training Built this as a hands-on lab for teaching web application security. It is a fictional electricity utility's customer portal with 48 deliberately planted flags (most of OWASP Top 10) you find and exploit CTF-style, including a simulated (rule-based, not a real model) AI assistant with its own prompt-injection-style vulnerabilities. Full disclosure, built this with AI assistance but I promise you're going to enjoy tinkering with it. https://ift.tt/Zg7ntYv September 30, 2026 at 11:31PM

Show HN: Real-time Solar System with 526k asteroids and all tracked satellites https://ift.tt/nN6gY8q

Show HN: Real-time Solar System with 526k asteroids and all tracked satellites https://space.bl2.net/ September 30, 2026 at 02:08AM

Show HN: A working 3D model of an Enigma machine https://ift.tt/vODLw2d

Show HN: A working 3D model of an Enigma machine I watched the excellent Veritasium video [1] on the Enigma machine, and watched the full animation by Jared Owen [2], but was still a bit confused on how the inner mechanics of an Enigma machine work. I used Astra to build out the inner components through a combination of reference images, writing out hundreds of extremely detailed prompts, and building my own inspection tools to ensure that every part is sized and positioned in a historically accurate way. It's still a work in progress, but would love any feedback on the experience so far! 1. https://www.youtube.com/watch?v=JsBZOcqZerk 2. https://www.youtube.com/watch?v=ybkkiGtJmkM https://enigma.design September 30, 2026 at 12:15AM

Show HN: Free browser games designed for 80-year-old eyes and hands https://ift.tt/9G2rwbI

Show HN: Free browser games designed for 80-year-old eyes and hands https://ift.tt/eYASJT3 September 29, 2026 at 10:45PM

Show HN: HN.watch – Videos of all Hacker News posts https://ift.tt/vnltNaE

Show HN: HN.watch – Videos of all Hacker News posts Hi HN, I’m Per, founder of Scrimba (YC S20). We’ve spent the last decade teaching people how to code with an HTML-based video format. We’ve now plugged an LLM into it, so that people can create explainer videos about anything. It’s called “Scrimba Explain”. To demo this technology for Hacker News, we built HN.watch. It’s like HN, but with explainer videos instead of articles. We create them on-the-fly the first time someone clicks on a link. While there are obvious visual drawbacks of using HTML instead of diffusion models, there are three big benefits: - Speed: Much faster to generate than pixel-based videos (just a few seconds from click to playback) - Cost: Our cost per video is ~$0.04. (Excluding image generation, which some videos utilize. Quickly blows up the cost) - Easy editing: the above benefits also make AI-assisted editing cheap & fast Our hypothesis is that if video creation goes from “dollars and minutes” to “cents and seconds”, a bunch of new use cases will be unlocked. Here are some we see already: - A video explanation of every single Pull Request (we do this internally) - Give every page in your internal/extrernal docs a video - Turn a complex article into a video in ~4 seconds (via our Chrome extension) - Course creators can quickly draft lessons before recording the real thing - People also create a lot of personal stuff stories for their kids, wedding invitations, birthdays, etc The stack is based on an open-source programming language (Imba) created by our CTO, Sindre Aarsæther. It compiles to JavaScript, so it interoperates fully with the npm + node ecosystem. You can learn more here: https://imba.io/ We’ve also built our own sync engine (OP), and a context management system for agents (Q). We feared this would make the LLMs struggle when writing code for us, as neither is in their training data (there’s very little Imba in there too). However, we’ve been pleasantly surprised to see that LLMs actually are really good at our stack. This is probably because the stack is extremely dense. Imba is compact, and so is OP, where a single declaration sets storage, sync, permissions, UI, and what the AI sees. This means there’s no translations between frontend, API, db and JSON where the model can get confused and get things wrong. Simply said, instead of using React.js, Express, Supabase, and LangChain, we built it all from scratch. Definitely suffering from the “not invented here” syndrome, lol! As for the models, we use Gemini, GPTs, Inworld, ElevenLabs, and a few others. If you want to try it out, just take your pick: - The Web UI (scrimba.com/explain) - MCP (add it to your coding agent) - ChatGPT Plugin - Chrome Extension You can find a link to all of the above in our docs: https://ift.tt/wSk6sza And finally, a real pixel-based video of the tool: https://www.youtube.com/watch?v=k6rbHmBxSEs Would love to hear your feedback and if anyone has ideas for other use cases. PS: I expect quite a bit of pushback from HN for this launch, given how fan of text the HN crowd is. This kind of tool is not for everyone. But there are a lot of people today who prefer videos over text, especially in the younger generations. https://hn.watch/ September 28, 2026 at 10:16PM

Show HN: I built an idle game that rewards you for doomscrolling less https://ift.tt/3vIceTO

Show HN: I built an idle game that rewards you for doomscrolling less https://getisland.app/ September 28, 2026 at 10:59PM

Show HN: Gat – Version large files with Git, without an LFS server https://ift.tt/MT4OvVw

Show HN: Gat – Version large files with Git, without an LFS server Hi HN, I built Gat because I wanted one thing from data versioning: check out an old Git commit and recover the datasets, model weights, or assets that belong to it. It's basically a lock file for large files. I’d appreciate any feedback! https://ift.tt/Wsdmutk September 28, 2026 at 12:20AM