The best Hacker News stories from Show from the past day
Latest posts:
Show HN: Browser grand strategy game for hundreds of players on huge maps
Hi HN,<p>I've been building a browser-based multiplayer strategy game called Borderhold.<p>Matches run on large maps designed for hundreds of players. Players expand territory, attack neighbors, and adapt as borders shift across the map. You can put buildings down, build ships, and launch nukes.<p>The main thing I wanted to explore was scale: most strategy games are small matches, modest maps, or modest player counts, but here maps are large and game works well with hundreds of players.<p>Matches are relatively short so you can jump in and see a full game play out.<p>Curious what people think.<p><a href="https://borderhold.io/play" rel="nofollow">https://borderhold.io/play</a><p>Gameplay:<p><a href="https://youtu.be/nrJTZEP-Cw8" rel="nofollow">https://youtu.be/nrJTZEP-Cw8</a><p>Discord:<p><a href="https://discord.gg/xVDNt2G5" rel="nofollow">https://discord.gg/xVDNt2G5</a>
Show HN: Playing LongTurn FreeCiv with Friends
Show HN: Duplicate 3 layers in a 24B LLM, logical deduction .22→.76. No training
I replicated David Ng's RYS method (<a href="https://dnhkng.github.io/posts/rys/" rel="nofollow">https://dnhkng.github.io/posts/rys/</a>) on consumer AMD GPUs
(RX 7900 XT + RX 6950 XT) and found something I didn't expect.<p>Transformers appear to have discrete "reasoning circuits" — contiguous blocks of 3-4 layers that
act as indivisible cognitive units. Duplicate the right block and the model runs its reasoning
pipeline twice. No weights change. No training. The model just thinks longer.<p>The results on standard benchmarks (lm-evaluation-harness, n=50):<p>Devstral-24B, layers 12-14 duplicated once:
- BBH Logical Deduction: 0.22 → 0.76
- GSM8K (strict): 0.48 → 0.64
- MBPP (code gen): 0.72 → 0.78
- Nothing degraded<p>Qwen2.5-Coder-32B, layers 7-9 duplicated once:
- Reasoning probe: 76% → 94%<p>The weird part: different duplication patterns create different cognitive "modes" from the same
weights. Double-pass boosts math. Triple-pass boosts emotional reasoning. Interleaved doubling
(13,13,14,14,15,15,16) creates a pure math specialist. Same model, same VRAM, different routing.<p>The circuit boundaries are sharp — shift by one layer and the effect disappears or inverts.
Smaller models (24B) have tighter circuits (3 layers) than larger ones (Ng found 7 layers in 72B).<p>Tools to find circuits in any GGUF model and apply arbitrary layer routing are in the repo.
The whole thing — sweep, discovery, validation — took one evening.<p>Happy to answer questions.
Show HN: Three new Kitten TTS models – smallest less than 25MB
Kitten TTS (<a href="https://github.com/KittenML/KittenTTS" rel="nofollow">https://github.com/KittenML/KittenTTS</a>) is an open-source series of tiny and expressive text-to-speech models for on-device applications. We had a thread last year here: <a href="https://news.ycombinator.com/item?id=44807868">https://news.ycombinator.com/item?id=44807868</a>.<p>Today we're releasing three new models with 80M, 40M and 14M parameters.<p>The largest model (80M) has the highest quality. The 14M variant reaches new SOTA in expressivity among similar sized models, despite being <25MB in size. This release is a major upgrade from the previous one and supports English text-to-speech applications in eight voices: four male and four female.<p>Here's a short demo: <a href="https://www.youtube.com/watch?v=ge3u5qblqZA" rel="nofollow">https://www.youtube.com/watch?v=ge3u5qblqZA</a>.<p>Most models are quantized to int8 + fp16, and they use ONNX for runtime. Our models are designed to run anywhere eg. raspberry pi, low-end smartphones, wearables, browsers etc. No GPU required! This release aims to bridge the gap between on-device and cloud models for tts applications. Multi-lingual model release is coming soon.<p>On-device AI is bottlenecked by one thing: a lack of tiny models that actually perform. Our goal is to open-source more models to run production-ready voice agents and apps entirely on-device.<p>We would love your feedback!
Show HN: Tmux-IDE, OSS agent-first terminal IDE
Hey HN,<p>Small OSS project that i created for myself and want to share with the community. It's a declarative, scriptable, terminal-based IDE focussed on agentic engineering.<p>That's a lot of jargon, but essentially its a multi-agent IDE that you start in your terminal.<p>Why is that relevant? Thanks to tmux and SSH, it means that you have a really simple and efficient way to create your own always-on coding setup.<p>Boot into your IDE through ssh, give a prompt to claude and close off your machine. In tmux-ide claude will keep working.<p>The tool is intentionally really lightweight, because I think the power should come from the harnesses that you are working with.<p>I'm hoping to share this with the community and get feedback and suggestions to shape this project! I think that "remote work" is directionally correct, because we can now have extremely long-running coding tasks. But I also think we should be able to control and orchstrate that experience according to what we need.<p>The project is 100% open-source, and i hope to shape it together with others who like to work in this way too!<p>Github: <a href="https://github.com/wavyrai/tmux-ide" rel="nofollow">https://github.com/wavyrai/tmux-ide</a>
Docs: <a href="https://tmux.thijsverreck.com/docs" rel="nofollow">https://tmux.thijsverreck.com/docs</a>
Show HN: Tmux-IDE, OSS agent-first terminal IDE
Hey HN,<p>Small OSS project that i created for myself and want to share with the community. It's a declarative, scriptable, terminal-based IDE focussed on agentic engineering.<p>That's a lot of jargon, but essentially its a multi-agent IDE that you start in your terminal.<p>Why is that relevant? Thanks to tmux and SSH, it means that you have a really simple and efficient way to create your own always-on coding setup.<p>Boot into your IDE through ssh, give a prompt to claude and close off your machine. In tmux-ide claude will keep working.<p>The tool is intentionally really lightweight, because I think the power should come from the harnesses that you are working with.<p>I'm hoping to share this with the community and get feedback and suggestions to shape this project! I think that "remote work" is directionally correct, because we can now have extremely long-running coding tasks. But I also think we should be able to control and orchstrate that experience according to what we need.<p>The project is 100% open-source, and i hope to shape it together with others who like to work in this way too!<p>Github: <a href="https://github.com/wavyrai/tmux-ide" rel="nofollow">https://github.com/wavyrai/tmux-ide</a>
Docs: <a href="https://tmux.thijsverreck.com/docs" rel="nofollow">https://tmux.thijsverreck.com/docs</a>
Show HN: Pgit – A Git-like CLI backed by PostgreSQL
Show HN: Pgit – A Git-like CLI backed by PostgreSQL
Show HN: I built 48 lightweight SVG backgrounds you can copy/paste
Show HN: I built 48 lightweight SVG backgrounds you can copy/paste
Show HN: Sub-millisecond VM sandboxes using CoW memory forking
I wanted to see how fast an isolated code sandbox could start if I never had to boot a fresh VM.<p>So instead of launching a new microVM per execution, I boot Firecracker once with Python and numpy already loaded, then snapshot the full VM state. Every execution after that creates a new KVM VM backed by a `MAP_PRIVATE` mapping of the snapshot memory, so Linux gives me copy-on-write pages automatically.<p>That means each sandbox starts from an already-running Python process inside a real VM, runs the code, and exits.<p>These are real KVM VMs, not containers: separate guest kernel, separate guest memory, separate page tables. When a VM writes to memory, it gets a private copy of that page.<p>The hard part was not CoW itself. The hard part was resuming the snapshotted VM correctly.<p>Rust, Apache 2.0.
Show HN: Sub-millisecond VM sandboxes using CoW memory forking
I wanted to see how fast an isolated code sandbox could start if I never had to boot a fresh VM.<p>So instead of launching a new microVM per execution, I boot Firecracker once with Python and numpy already loaded, then snapshot the full VM state. Every execution after that creates a new KVM VM backed by a `MAP_PRIVATE` mapping of the snapshot memory, so Linux gives me copy-on-write pages automatically.<p>That means each sandbox starts from an already-running Python process inside a real VM, runs the code, and exits.<p>These are real KVM VMs, not containers: separate guest kernel, separate guest memory, separate page tables. When a VM writes to memory, it gets a private copy of that page.<p>The hard part was not CoW itself. The hard part was resuming the snapshotted VM correctly.<p>Rust, Apache 2.0.
Show HN: Will my flight have Starlink?
Hey HN, If you’ve been lucky enough to be on a flight with Starlink, you understand the hype. It actually works!<p>However, its availability on flights is patchy and hard to predict. So we built a database of all airlines that have rolled out Starlink (beyond just a trial), and a flight search tool to predict it. Plug in a flight number and date, and we'll estimate the likelihood of Starlink on-board based on aircraft type and tail number.<p>If you don’t have any trips coming up, you can also look up specific routes to see what flights offer Starlink. You can find it here: <a href="https://stardrift.ai/starlink">https://stardrift.ai/starlink</a> .<p>-<p>I wanted to add a few notes on how this works too. There are three things we check, in order, when we answer a query:<p>- Does this airline have Starlink?<p>- Does this aircraft body have Starlink?<p>- Does <i>this specific aircraft</i> have Starlink?<p>Only a few airlines at all have Starlink right now: United, Hawaiian, Alaskan, Air France, Qatar, JSX, and a handful of others. So if an aircraft is operated by any other airline, we can issue a blanket no immediately.<p>Then, we check the actual body that's flying on the plane. Airlines usually publish equipment assignments in advance, and they're also rolling out Starlink body-by-body. So we know, for instance, that all JSX E145s have Starlink and that none of Air France's A320s have Starlink. (You can see a summary of our data at <a href="https://stardrift.ai/starlink/fleet-summary">https://stardrift.ai/starlink/fleet-summary</a>, though the live logic has a few rules not encoded there.)<p>If there's a complete match at the body type level, we can confidently tell you your flight will have Starlink. However, in most cases, the airline has only rolled out a <i>partial</i> upgrade to that aircraft type. In that case, we need to drill down a little more and figure out exactly <i>which</i> plane is flying on your route.<p>We can do this by looking up the 'tail number' (think of it as a license plate for the plane). <i>Unfortunately</i>, the tail number is usually only assigned a few days before a flight. So, before that, the best we can do is calculate the probability that your plane will be assigned an aircraft with Starlink enabled.<p>To do this, we had to build a mapping of aircraft tails to Starlink status. Here, I have to thank online airline enthusiasts who maintain meticulous spreadsheets and forum threads to track this data! As I understand it, <i>they</i> usually get this data from airline staff who are enthusiastic about Starlink rollouts, so it's a reliable, frequently updated source. Most of <i>our</i> work was finding each source, normalizing their formats, building a reliable & responsible system to pull them in, and then tying them together with our other data sources.<p>Basically, it's a data normalization problem! I used to work on financial data systems and I was surprised how similar this problem was.<p>-<p>Starlink itself is also a pretty cool technology. I also wrote a blog post (<a href="https://stardrift.ai/blog/why-is-starlink-so-good">https://stardrift.ai/blog/why-is-starlink-so-good</a>) on why it's so much better than all the other aircraft wifi options out there. At a high level, it's only possible because rocket launches are so cheap nowadays, which is incredibly cool.<p>The performance is great, so it's well worth planning your flights around it where possible. Right now, your best bet in the US is on United regional flights and JSX/Hawaiian. Internationally, Qatar is the best option (though obviously not right now), with Air France a distance second. This will change throughout the year as more airlines roll it out though, and we'll keep our database updated!
Show HN: Will my flight have Starlink?
Hey HN, If you’ve been lucky enough to be on a flight with Starlink, you understand the hype. It actually works!<p>However, its availability on flights is patchy and hard to predict. So we built a database of all airlines that have rolled out Starlink (beyond just a trial), and a flight search tool to predict it. Plug in a flight number and date, and we'll estimate the likelihood of Starlink on-board based on aircraft type and tail number.<p>If you don’t have any trips coming up, you can also look up specific routes to see what flights offer Starlink. You can find it here: <a href="https://stardrift.ai/starlink">https://stardrift.ai/starlink</a> .<p>-<p>I wanted to add a few notes on how this works too. There are three things we check, in order, when we answer a query:<p>- Does this airline have Starlink?<p>- Does this aircraft body have Starlink?<p>- Does <i>this specific aircraft</i> have Starlink?<p>Only a few airlines at all have Starlink right now: United, Hawaiian, Alaskan, Air France, Qatar, JSX, and a handful of others. So if an aircraft is operated by any other airline, we can issue a blanket no immediately.<p>Then, we check the actual body that's flying on the plane. Airlines usually publish equipment assignments in advance, and they're also rolling out Starlink body-by-body. So we know, for instance, that all JSX E145s have Starlink and that none of Air France's A320s have Starlink. (You can see a summary of our data at <a href="https://stardrift.ai/starlink/fleet-summary">https://stardrift.ai/starlink/fleet-summary</a>, though the live logic has a few rules not encoded there.)<p>If there's a complete match at the body type level, we can confidently tell you your flight will have Starlink. However, in most cases, the airline has only rolled out a <i>partial</i> upgrade to that aircraft type. In that case, we need to drill down a little more and figure out exactly <i>which</i> plane is flying on your route.<p>We can do this by looking up the 'tail number' (think of it as a license plate for the plane). <i>Unfortunately</i>, the tail number is usually only assigned a few days before a flight. So, before that, the best we can do is calculate the probability that your plane will be assigned an aircraft with Starlink enabled.<p>To do this, we had to build a mapping of aircraft tails to Starlink status. Here, I have to thank online airline enthusiasts who maintain meticulous spreadsheets and forum threads to track this data! As I understand it, <i>they</i> usually get this data from airline staff who are enthusiastic about Starlink rollouts, so it's a reliable, frequently updated source. Most of <i>our</i> work was finding each source, normalizing their formats, building a reliable & responsible system to pull them in, and then tying them together with our other data sources.<p>Basically, it's a data normalization problem! I used to work on financial data systems and I was surprised how similar this problem was.<p>-<p>Starlink itself is also a pretty cool technology. I also wrote a blog post (<a href="https://stardrift.ai/blog/why-is-starlink-so-good">https://stardrift.ai/blog/why-is-starlink-so-good</a>) on why it's so much better than all the other aircraft wifi options out there. At a high level, it's only possible because rocket launches are so cheap nowadays, which is incredibly cool.<p>The performance is great, so it's well worth planning your flights around it where possible. Right now, your best bet in the US is on United regional flights and JSX/Hawaiian. Internationally, Qatar is the best option (though obviously not right now), with Air France a distance second. This will change throughout the year as more airlines roll it out though, and we'll keep our database updated!
Show HN: Hacker News archive (47M+ items, 11.6GB) as Parquet, updated every 5m
Show HN: Hacker News archive (47M+ items, 11.6GB) as Parquet, updated every 5m
Show HN: March Madness Bracket Challenge for AI Agents Only
I built a March Madness bracket challenge for AI agents, not humans. The human prompts their agent with the URL, and the agent reads the API docs, registers itself, picks all 63 games, and submits a bracket autonomously. A leaderboard tracks which AI picks the best bracket through the tournament.<p>The interesting design problem was building for an agent-first user. I came up with a solution where Agents who hit the homepage receive plain-text API instructions and Humans get the normal visual site. Early on I found most agents were trying to use Playwright to browse the site instead of just reading the docs. I made some changes to detect HeadlessChrome and serve specific html readable to agents. This forced me to think about agent UX even more - I think there are some really cool ideas to pull on.<p>The timeline introduced an interesting dynamic. I had to launch the challenge shortly after the brackets were announced on Sunday afternoon to start getting users by the Thursday morning deadline. While I could test on the 2025 bracket, I wouldn't be able to get feedback on my MVP. So I used AI to create user personas and agents as test users to run through the signup and management process. It gave me valuable reps to feel confident launching.<p>The stack is Next.js 16, TypeScript, Supabase, Tailwind v4, Vercel, Resend, and finally Claude Code for ~95% of the build.<p>Works with any model that can call an API — Claude, GPT, Gemini, open source, whatever. Brackets are due Thursday morning before the First Round tips off.<p>Bracketmadness.ai
Show HN: Crust – A CLI framework for TypeScript and Bun
We've been building Crust (<a href="https://crustjs.com/" rel="nofollow">https://crustjs.com/</a>), a TypeScript-first, Bun-native CLI framework with zero dependencies. It's been powering our core product internally for a while, and we're now open-sourcing it.<p>The problem we kept running into: existing CLI frameworks in the JS ecosystem are either minimal arg parsers where you wire everything yourself, or heavyweight frameworks with large dependency trees and Node-era assumptions. We wanted something in between.<p>What Crust does differently:<p>- Full type inference from definitions — args and flags are inferred automatically. No manual type annotations, no generics to wrangle. You define a flag as type: "string" and it flows through to your handler.<p>- Compile-time validation — catches flag alias collisions and variadic arg mistakes before your code runs, not at runtime.<p>- Zero runtime dependencies — @crustjs/core is ~3.6kB gzipped (21kB install). For comparison: yargs is 509kB, oclif is 411kB.<p>- Composable modules — core, plugins, prompts, styling, validation, and build tooling are all separate packages. Install only what you need.<p>- Plugin system — middleware-based with lifecycle hooks (preRun/postRun). Official plugins for help, version, and shell autocompletion.<p>- Built for Bun — no Node compatibility layers, no legacy baggage.<p>Quick example:<p><pre><code> import { Crust } from "@crustjs/core";
import { helpPlugin, versionPlugin } from "@crustjs/plugins";
const main = new Crust("greet")
.args([{ name: "name", type: "string", default: "world" }])
.flags({ shout: { type: "boolean", short: "s" } })
.use(helpPlugin())
.use(versionPlugin("1.0.0"))
.run(({ args, flags }) => {
const msg = `Hello, ${args.name}!`;
console.log(flags.shout ? msg.toUpperCase() : msg);
});
await main.execute();
</code></pre>
Scaffold a new project:<p><pre><code> bun create crust my-cli
</code></pre>
Site: <a href="https://crustjs.com" rel="nofollow">https://crustjs.com</a>
GitHub: <a href="https://github.com/chenxin-yan/crust" rel="nofollow">https://github.com/chenxin-yan/crust</a><p>Happy to answer any questions about the design decisions or internals.
Show HN: Antfly: Distributed, Multimodal Search and Memory and Graphs in Go
Hey HN, I’m excited to share Antfly: a distributed document database and search engine written in Go that combines full-text, vector, and graph search. Use it for distributed multimodal search and memory, or for local dev and small deployments.<p>I built this to give developers a single-binary deployment with native ML inference (via a built-in service called Termite), meaning you don't need external API calls for vector search unless you want to use them.<p>Some things that might interest this crowd:<p>Capabilities: Multimodal indexing (images, audio, video), MongoDB-style in-place updates, and streaming RAG.<p>Distributed Systems: Multi-Raft setup built on etcd's library, backed by Pebble (CockroachDB's storage engine). Metadata and data shards get their own Raft groups.<p>Single Binary: antfly swarm gives you a single-process deployment with everything running. Good for local dev and small deployments. Scale out by adding nodes when you need to.<p>Ecosystem: Ships with a Kubernetes operator and an MCP server for LLM tool use.<p>Native ML inference: Antfly ships with Termite. Think of it like a built-in Ollama for non-generative models too (embeddings, reranking, chunking, text generation). No external API calls needed, but also supports them (OpenAI, Ollama, Bedrock, Gemini, etc.)<p>License: I went with Elastic License v2, not an OSI-approved license. I know that's a topic with strong feelings here. The practical upshot: you can use it, modify it, self-host it, build products on top of it, you just can't offer Antfly itself as a managed service. Felt like the right tradeoff for sustainability while still making the source available.<p>Happy to answer questions about the architecture, the Raft implementation, or anything else. Feedback welcome!
Show HN: Antfly: Distributed, Multimodal Search and Memory and Graphs in Go
Hey HN, I’m excited to share Antfly: a distributed document database and search engine written in Go that combines full-text, vector, and graph search. Use it for distributed multimodal search and memory, or for local dev and small deployments.<p>I built this to give developers a single-binary deployment with native ML inference (via a built-in service called Termite), meaning you don't need external API calls for vector search unless you want to use them.<p>Some things that might interest this crowd:<p>Capabilities: Multimodal indexing (images, audio, video), MongoDB-style in-place updates, and streaming RAG.<p>Distributed Systems: Multi-Raft setup built on etcd's library, backed by Pebble (CockroachDB's storage engine). Metadata and data shards get their own Raft groups.<p>Single Binary: antfly swarm gives you a single-process deployment with everything running. Good for local dev and small deployments. Scale out by adding nodes when you need to.<p>Ecosystem: Ships with a Kubernetes operator and an MCP server for LLM tool use.<p>Native ML inference: Antfly ships with Termite. Think of it like a built-in Ollama for non-generative models too (embeddings, reranking, chunking, text generation). No external API calls needed, but also supports them (OpenAI, Ollama, Bedrock, Gemini, etc.)<p>License: I went with Elastic License v2, not an OSI-approved license. I know that's a topic with strong feelings here. The practical upshot: you can use it, modify it, self-host it, build products on top of it, you just can't offer Antfly itself as a managed service. Felt like the right tradeoff for sustainability while still making the source available.<p>Happy to answer questions about the architecture, the Raft implementation, or anything else. Feedback welcome!