The best Hacker News stories from Show from the past week
Latest posts:
Show HN: I am building a map of people who lived in the Roman Empire
Driving home from work one day, I wanted to know how many people we knew the names of who lived during the Roman era. Searching around, I found lists of Consuls and officials, but nothing that covered ordinary people or even most people like freedmen and slaves. So I ended up building a pipeline to process the more than 500k Latin inscriptions in the Epigraphic Database Clauss-Slaby <a href="https://edcs.hist.uzh.ch/en/" rel="nofollow">https://edcs.hist.uzh.ch/en/</a> and extract the names of people (and attempt to cluster them, but this is a work in progress).<p>There are databases where Classicists have done this manually for specific regions, Trismegistos <a href="https://www.trismegistos.org/" rel="nofollow">https://www.trismegistos.org/</a> and Latin Inscriptions of the Roman Empire (LIRE) <a href="https://pure.au.dk/portal/en/publications/latin-inscriptions-of-the-roman-empire-lire/" rel="nofollow">https://pure.au.dk/portal/en/publications/latin-inscriptions...</a> are two major efforts I found. But there doesn't seem to be a project that did what I set out to do, although I have read in some places that it was believed to be possible.<p>I am not a classicist or a web developer, but I have Claude and Gemini and I can sort of read basic Latin - so I set to work. I used LIRE and another database as ground truth and built a pipeline to extract and process the inscriptions to recover the names. The process I developed uses a high end LLM like Sonnet or Gemini Pro to supervise the extraction and tuning process on a regional basis until the obvious error rate is reasonable. For this, so far, reasonable to me means less than 1-2% in the smaller initial samples of 100-500 and no observed systemic issues. The different regions often need different prompts, so this basically became an exercise in letting the higher level AI tune the prompt for the lower level AI. The extraction when measured against LIRE produces an F1 score between 0.64 and 0.87, but take this with a grain of salt.<p>Once I had done a few regions, I wanted to see the work, so I threw together a pretty crude website but as I am not a web developer, it was crude in how it accessed its data. It does look cool and I also added summarization, and machine translation to each entry. I wanted to eventually get feedback from an actual team of classicists and make the website work better, so I am rewriting it as we speak but it is broadly functional now with a few extra bugs but substantially improved performance compared to the old one. All entries link back to the proper sources, and the old web app linked to several additional sources where the data was present, but I haven't gotten that working again just yet on the new one. (The old web interface is still available at <a href="https://roman-names.com" rel="nofollow">https://roman-names.com</a>, but I will warn you it is clunky and not mobile friendly at all)<p>Key findings so far:<p>AI supervised AI extraction saved me time. I was manually tuning things for a while and then the runbook became an idea that I feed my instructions in and let the big AI go with sparse oversight from me.<p>The extraction improved significantly (by about 10 F1 points) when I fed the model the raw text including the markers, vs a cleaned up version of the text.<p>I just thought it was a cool little project and wanted to share. If you happen to work in any adjacent space and there is something I could do better etc let me know.
Show HN: Putt.day a daily mini golf game
Show HN: FablePool – pool money behind a prompt, and Fable builds it in public
Show HN: Homebrew 6.0.0
Today, I’m proud to announce Homebrew 6.0.0. The most significant changes since 5.1.0 are a new tap trust security mechanism, the new faster, smaller, default internal Homebrew JSON API, sandboxing on Linux, better defaults informed by our user survey, many brew bundle improvements, improved performance and initial support for macOS 27 (Golden Gate).<p>Happy to discuss any questions here!
Show HN: Extend UI – open-source UI kit for modern document apps
We're open-sourcing 14 components & examples today for PDF, DOCX, and XLSX viewers, plus bounding box citations, file upload, e-signature, and more. It's MIT licensed and fully customizable.<p>Demo video here: <a href="https://share.extend.ai/kRmSGKRF">https://share.extend.ai/kRmSGKRF</a><p>When we started, we tried every file viewer and document component library we could find. Unfortunately, none of them had all the functionality (and polish) that we wanted, so we ended up building our own for <a href="https://extend.ai/">https://extend.ai/</a>. It was only ever meant to be internal, but enough customers kept asking for it that we decided to open source it.<p>It's useful for building document processing agents, real-time user facing document intake flows, or all kinds of internal tooling.<p>We naively thought this would be a solved problem. Turns out, making PDF/XLSX/DOCX viewers that work at scale is not trivial...we use and maintain it for Extend ourselves, so we've fixed a lot of edge cases that came up while running millions of pages / day through our own system. Our hope is that with our resources + community support, it'll keep getting better over time.
Show HN: Gravity – Interactive solar-system simulator, from Newton to Einstein
Just for fun and self education, I've built this over a weekend to teach myself why orbits exist, not just show planets going around. Something that was never clearly explain to me in school.
It opens with a guided tour that builds the idea up step by step: two bodies and the equal/opposite force, inertia (the Sun is removed and Earth just drifts straight), then "an orbit is falling and continuously missing," cosmic velocities with a little rocket, Voyager 1 & 2's real gravity assists (the clock runs the actual 1977–1989 dates so the planets orbit into their grand-tour alignment and the slingshots line up), and it ends on Einstein — gravity as curved spacetime, the classic rubber-sheet well.
What's real: every body uses its real radius/mass and J2000 orbital elements; positions come from solving Kepler's equation each frame. You can toggle to an N-body mode (symplectic leapfrog) that shows live energy drift (~1e-6%) so you can see the integrator is honest. The only thing faked is scale — at true scale you can't see anything — so there's a toggle between true scale and a log-remapped "visual" scale, with physics always running in real AU.
Tech: TypeScript + Three.js + Vite, fully client-side, no backend, works offline (surface textures are generated procedurally from value-noise; only Earth uses a real image). Source: <a href="https://github.com/qunabu/Gravity" rel="nofollow">https://github.com/qunabu/Gravity</a><p>Happy to answer questions — and feedback on the physics or the explanations is very welcome. This project might be totally inaccurate in terms of real physics, this is how i do understand this on my own - i'm happy to confront this with reality
Show HN: Gitdot – A better GitHub. Open-source, written in Rust
What works now: user signups, org creations, private/public repos, and importing GitHub repositories (both as read-only mirrors and full migrations). So basically, you can create, push and pull to a repo, but we don't have many features quite yet (issues, PRs, CI).<p>What is a bit unique is: 1) we built it in Rust and 2) the website is a little odd. Its design is inspired by CLIs (e.g., fzf, broot, vim) instead of web apps, and as such, lacks some affordances that you might typically expect in favor of keyboard-driven instant navigations (we have the very ambitious goal of an FCP of 100ms). In case you're curious, here's how we we built it: <a href="https://gitdot.io/designs">https://gitdot.io/designs</a><p>We recognize that we're making some bold claims here and are also well aware that we have much to learn. Building software is still hard, and that's a fact we seem to relearn everyday.<p>But we wanted to share what we built so far nonetheless.<p>Cheers, thank y'all for reading, and till the next
—paul & mikkel.
Show HN: Performative-UI – A react component library of design tropes
hope you enjoy
Show HN: I Derived a Pancake
After 25 years of making other people's pancake recipes - always yearning for more tang, more fluff, and more predictability - I decided to derive the pancake recipe from the chemistry.<p>You mark checkboxes for what you have on hand (ricotta, sour cream, kefir, buttermilk, yogurt, cottage cheese, lemon, cream of tartar, etc.) and it computes the best recipe based on targets for acid, fat, salt, sugar, and CO2.<p>My particular favorite are the yeast-raised lemon ricotta kefir pancakes - the best I've ever had.<p>The math is done in a small pure-ESM library: ingredient composition to component masses and acid moles, a stoichiometry layer, and a bisection solver for the target deficits.<p>I'm not a chemist, so if something is off, tell me and I will fix it!
Show HN: Lathe – Use LLMs to learn a new domain, not skip past it
Hey HN!<p>Lathe is an experiment in using LLMs to teach me something new, instead of doing the work for me. It generates a hands-on, source-backed tutorial for any technical topic you want to learn. Then you work through it yourself by reading and typing the code by hand (<i>gasp</i>) in a local UI built for exactly that.<p>It's a Go CLI plus LLM agent skills (Claude Code / Cursor / Codex). You prompt something like "/lathe build a 3D slicer in Erlang", run `lathe serve` to spin up a local webapp, and read it in your browser. Every tutorial comes with the things that have made self-learning a pleasant experience for me in the past:<p>- table of contents that follows along as you scroll
- side-notes that nudge you to think
- exercises for the reader
- sources backing up the content that you can use to take you deeper<p>To help make up for the lack of human brainpower behind the tutorial, you can also ask questions about the content, have another LLM verify the tutorial actually compiles and runs, or extend it with another part (no more "Part 4 of 6" that hasn't seen an update since 2021).<p>I didn't build lathe to replace human-written tutorials. I built lathe because I _love_ human-written tutorials, but wanted to learn technical domains where no good human-written tutorial exists yet (building a 3D slicer from scratch, making embedded Zig approachable, etc). There's a longer story in the README about how I got started with programming through PSP homebrew tutorials, and why losing that to LLMs bugged me enough to build this.<p>I'm not here to sell you anything (there's nothing close to a VC-backed startup here :D). It's an LLM, and its output is usually good but not perfect by any means. So far, my experience is that because you're the one typing and actually engaged, you catch the weird stuff (and I'm finding that pushing back on it is its own kind of learning). And yes, it's vibecoded, because it's low scope, low risk, and scratching a personal itch. I run it on Claude Code + macOS personally, other setups should work but I haven't been able to verify them yet.<p>If you can find resources to learn something that was written by a human, read that first. But Lathe is here to fill in the gaps when that isn't the case, and I hope it serves as an example where LLMs can help us think better, rather than less.<p>Repo: <a href="https://github.com/devenjarvis/lathe" rel="nofollow">https://github.com/devenjarvis/lathe</a><p>Would love your feedback if you decide to check it out!
Show HN: Lathe – Use LLMs to learn a new domain, not skip past it
Hey HN!<p>Lathe is an experiment in using LLMs to teach me something new, instead of doing the work for me. It generates a hands-on, source-backed tutorial for any technical topic you want to learn. Then you work through it yourself by reading and typing the code by hand (<i>gasp</i>) in a local UI built for exactly that.<p>It's a Go CLI plus LLM agent skills (Claude Code / Cursor / Codex). You prompt something like "/lathe build a 3D slicer in Erlang", run `lathe serve` to spin up a local webapp, and read it in your browser. Every tutorial comes with the things that have made self-learning a pleasant experience for me in the past:<p>- table of contents that follows along as you scroll
- side-notes that nudge you to think
- exercises for the reader
- sources backing up the content that you can use to take you deeper<p>To help make up for the lack of human brainpower behind the tutorial, you can also ask questions about the content, have another LLM verify the tutorial actually compiles and runs, or extend it with another part (no more "Part 4 of 6" that hasn't seen an update since 2021).<p>I didn't build lathe to replace human-written tutorials. I built lathe because I _love_ human-written tutorials, but wanted to learn technical domains where no good human-written tutorial exists yet (building a 3D slicer from scratch, making embedded Zig approachable, etc). There's a longer story in the README about how I got started with programming through PSP homebrew tutorials, and why losing that to LLMs bugged me enough to build this.<p>I'm not here to sell you anything (there's nothing close to a VC-backed startup here :D). It's an LLM, and its output is usually good but not perfect by any means. So far, my experience is that because you're the one typing and actually engaged, you catch the weird stuff (and I'm finding that pushing back on it is its own kind of learning). And yes, it's vibecoded, because it's low scope, low risk, and scratching a personal itch. I run it on Claude Code + macOS personally, other setups should work but I haven't been able to verify them yet.<p>If you can find resources to learn something that was written by a human, read that first. But Lathe is here to fill in the gaps when that isn't the case, and I hope it serves as an example where LLMs can help us think better, rather than less.<p>Repo: <a href="https://github.com/devenjarvis/lathe" rel="nofollow">https://github.com/devenjarvis/lathe</a><p>Would love your feedback if you decide to check it out!
Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens
Hi HN, not sure if anyone would be interested, but just wanted to share that I've been maintaining my small tool called 'lowfat' that helps me filters some of my verbose CLI output. It's a single binary, works as an agent hook or a shell wrapper. It has a plugin system to customize filters per command.<p>The idea is pretty simple: agents don't need the full kubectl get -o yaml or any 10k-line dump to make decisions.
So that lowfat sits in between, strips the noise, and passes through what matters. Here's my real report after 2 months of personal use:<p><pre><code> lowfat history --all
lowfat plugin candidates
─────────────────────────────────────────────────────────
# command runs avg raw cost savings source status
1 kubectl get 101x 14.4K 1.5M 93.9% plugin good
2 grep 103x 13.5K 1.4M 96.2% plugin good
3 git diff 81x 995 80.6K 57.9% built-in good
4 kubectl 90x 485 43.6K 33.6% plugin good
5 docker 127x 5.5K 693.6K 96.1% built-in good
6 ls 489x 117 57.3K 56.2% built-in good
7 find 30x 16.5K 495.0K 95.5% plugin good
8 git show 63x 490 30.9K 38.0% built-in good
9 git 177x 368 65.2K 76.1% built-in good
10 git log 86x 556 47.8K 78.5% built-in good
11 kubectl logs 5x 3.6K 17.8K 43.0% plugin good
12 git status 86x 152 13.1K 58.0% built-in good
13 docker ps 20x 467 9.3K 52.8% plugin good
14 kubectl describe 6x 656 3.9K 1.2% plugin weak
15 docker images 9x 940 8.5K 61.8% built-in good
16 k get 2x 2.1K 4.2K 35.9% plugin good
17 terraform 10x 395 3.9K 32.1% plugin good
18 git commit 32x 77 2.5K 0.0% built-in weak
19 docker build 8x 487 3.9K 37.6% built-in good
20 docker compose 22x 979 21.5K 89.4% built-in good
total: 4.4M raw → 4.1M saved (91.8%)
</code></pre>
My toolset above is kind limited, but it works pretty well for my usecase without any interruption
Kinda help me not reaching the token limit for my company Bedrock limit usage and keep optimizing the saving on the go for later usage.<p>But, why not alternatives (<a href="https://github.com/zdk/lowfat#alternatives" rel="nofollow">https://github.com/zdk/lowfat#alternatives</a>) ?
The answers are:
- My goal is to make the core lightweight but extensible via plugins i.e. not trying to bundle every command in the installed binary so that people own their output filters.
- Customizable per usecase via plugin or filter pipelines as I am using my own toolset.
- Customizable for non-public CLI tools, for example, some enterprise might have their interal CLI tools that public won't have access.
- People should own their data. So the design is local-first, No telemetry forever.
- I kinda love UNIX-style composible pipes, so lowfat-filter has implemented this style.
- Be able to adjust aggressiveness of the filter, so we can control that we won't strip something the agent needed.<p>GitHub: <a href="https://github.com/zdk/lowfat" rel="nofollow">https://github.com/zdk/lowfat</a><p>Anyway, if anyone is interested, feedbacks and questions are welcome!<p>Thanks!
Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
Hi HN, we’re Nick and Drew, and we’re building boxes.dev – the first cloud-only agentic dev environment (ADE) that gives every Codex and Claude Code agent its own cloud computer.<p>We’re two engineers who previously built Gem (co-founder/CTO and first hire), and we spent the last year coding almost exclusively using Codex and Claude Code. It’s been a huge change to how we code, and it’s been exhilarating seeing the models keep getting better – but we eventually realized that developing on localhost was holding us back:<p>- Git worktrees are clunky to set up and use for parallelizing work
- It’s 2026, but somehow everyone is still walking around with laptops cracked open or SSHing into mac minis in their garage so their agents don’t stop working.
- Mobile is treated like an afterthought even though coding is just texting now
We started hitting resource constraints when multiple parallel agents test their own work by running the full app locally.
- We tried different products, but couldn’t find any that solved all of our pain points – so we pivoted and decided to just build the ADE we wanted for ourselves.<p>Boxes.dev is a desktop and mobile app that lets you run Claude Code, Codex (using your subscription!), and the full dev environment for whatever you’re building, all on remote compute. It’s similar to Conductor or the Codex desktop app, except everything is in the cloud.<p>We use coding agents to scan your local dev setup and port it to the cloud. Then every Claude Code/Codex thread starts from a snapshot of the full setup, with its own filesystem and compute.
No more git worktrees, no more cracked-open laptops, and your coding agents can actually test their work end-to-end because they can run your full app in isolation.<p>We’ve mirrored the Claude Code and Codex UX to feel natural to power users, and also have a fully-featured mobile app (no handoffs or remote control), plus scheduled automations and a Slack integration.<p>We’re obviously biased, but we’ve been building boxes.dev with boxes.dev for months and it’s honestly been a gamechanger. It’s hard to go back once you realize how much localhost has been limiting you; based on early feedback from beta testers, we’re increasingly sure that cloud is the future of agentic coding.<p>We’d love for you to experience it yourselves! Would appreciate any feedback – and happy to answer any questions on this thread.
Show HN: Uruky (EU-based Kagi alternative) now has Image Search and URL Rewrites
You can get a 2h free trial by solving a proof-of-work captcha when topping up your account for the first time.<p>If you'd like to learn more, an independent interview was posted a couple of weeks ago [1], and the FAQ [2] has a lot of information as well.<p>For the source code sharing, we've talked with lawyers and are inclined to no longer require the NDA/NCC for privacy reasons shared with us before (signing requires identification), but instead use a source-available permissive license that doesn't allow competition, like PolyForm Shield [3] (we do still have about 6 months before finalising a decision, here).<p>This does come with a lot more risks for us (it's harder to track down if someone publishes the code or uses it against the license), but given we've already passed 100 monthly active accounts, we're feeling more confident it's an acceptable risk.<p>The plan is to give logged in accounts (who are 12 months old or more) a way to download a ZIP of the current code base that's in the server.<p>Obviously there's no easy way to prove that's the case, but we're open to ideas/suggestions if someone here has them.<p>[1]: <a href="https://theprivacydad.com/interview-with-the-engineer-of-uruky-a-private-search-engine/" rel="nofollow">https://theprivacydad.com/interview-with-the-engineer-of-uru...</a><p>[2]: <a href="https://uruky.com/faq" rel="nofollow">https://uruky.com/faq</a><p>[3]: <a href="https://polyformproject.org/licenses/shield/1.0.0" rel="nofollow">https://polyformproject.org/licenses/shield/1.0.0</a>
Show HN: I reverse-engineered the world maps of Test Drive III (1990 DOS game)
Show HN: Edsger – A handwritten Clojure REPL for the reMarkable 2
Show HN: Eyeball
Show HN: Breathe CLI – Paced resonance breathing in the macOS terminal
I built a terminal app that paces slow breathing at 6 breaths per minute for vagal tone training. It's a single Python file, stdlib only, no dependencies — just run breathe and follow the bar.<p>I'm a cardiology patient (HFrEF). Slow breathing at resonance frequency is one of the few non-pharmacological interventions shown to improve cardiac vagal tone and baroreflex sensitivity (Bernardi et al., Circulation 2002; Lancet 1998). I wanted a frictionless daily habit tool — no app store, no account, no subscription, just open terminal and go.<p>Design constraints, all grounded in the clinical literature:<p>- No breath retention — Valsalva risk in cardiac patients<p>- No rapid breathing — minimum 8-second cycles<p>- Exhale ≤ 2x inhale — no evidence for extreme ratios<p>- Immediate exit, always — q or Ctrl+C restores the terminal even on crash<p>The README includes a resonance frequency measurement protocol for anyone with a chest-strap HRV monitor who wants to find their individual optimum instead of using the 6 bpm default.<p>macOS only (uses afplay for audio cues). MIT licensed.<p>pip install breathe-cli<p>or<p>brew tap marekkowalczyk/breathe && brew install breathe.
Show HN: 500 years of Joseon court omens as an observability dashboard
Show HN: Tiny-vLLM – high performance LLM inference engine in C++ and CUDA