The best Hacker News stories from Show from the past day
Latest posts:
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: 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: 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: 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!
Show HN: Hackerbrief – Top posts on Hacker News summarized daily
Show HN: Thermal Receipt Printers – Markdown and Web UI
Show HN: Thermal Receipt Printers – Markdown and Web UI
Show HN: Oxyde – Pydantic-native async ORM with a Rust core
Hi HN! I built Oxyde because I was tired of duplicating my models.<p>If you use FastAPI, you know the drill. You define Pydantic models for your API, then define separate ORM models for your database, then write converters between them. SQLModel tries to fix this but it's still SQLAlchemy underneath. Tortoise gives you a nice Django-style API but its own model system. Django ORM is great but welded to the framework.<p>I wanted something simple: your Pydantic model IS your database model. One class, full validation on input and output, native type hints, zero duplication. The query API is Django-style (.objects.filter(), .exclude(), Q/F expressions) because I think it's one of the best designs out there.<p><i>Explicit over implicit.</i> I tried to remove all the magic. Queries don't touch the database until you call a terminal method like .all(), .get(), or .first(). If you don't explicitly call .join() or .prefetch(), related data won't be loaded. No lazy loading, no surprise N+1 queries behind your back. You see exactly what hits the database by reading the code.<p><i>Type safety</i> was a big motivation. Python's weak spot is runtime surprises, so Oxyde tackles this on three levels: (1) when you run makemigrations, it also generates .pyi stub files with fully typed queries, so your IDE knows that filter(age__gte=...) takes an int, that create() accepts exactly the fields your model has, and that .all() returns list[User] not list[Any]; (2) Pydantic validates data going into the database; (3) Pydantic validates data coming back out via model_validate(). You get autocompletion, red squiggles on typos, and runtime guarantees, all from the same model definition.<p><i>Why Rust?</i> Not for speed as a goal. I don't do "language X is better" debates. Each one is good at what it was made for. Python is hard to beat for expressing business logic. But infrastructure stuff like SQL generation, connection pooling, and row serialization is where a systems language makes sense. So I split it: Python handles your models and business logic, Rust handles the database plumbing. Queries are built as an IR in Python, serialized via MessagePack, sent to Rust which generates dialect-specific SQL, executes it, and streams results back. Speed is a side effect of this split, not the goal. But since you're not paying a performance tax for the convenience, here are the benchmarks if curious: <a href="https://oxyde.fatalyst.dev/latest/advanced/benchmarks/" rel="nofollow">https://oxyde.fatalyst.dev/latest/advanced/benchmarks/</a><p>What's there today: Django-style migrations (makemigrations / migrate), transactions with savepoints, joins and prefetch, PostgreSQL + SQLite + MySQL, FastAPI integration, and an auto-generated admin panel that works with FastAPI, Litestar, Sanic, Quart, and Falcon (<a href="https://github.com/mr-fatalyst/oxyde-admin" rel="nofollow">https://github.com/mr-fatalyst/oxyde-admin</a>).<p>It's v0.5, beta, active development, API might still change. This is my attempt to build the ORM I personally wanted to use. Would love feedback, criticism, ideas.<p>Docs: <a href="https://oxyde.fatalyst.dev/" rel="nofollow">https://oxyde.fatalyst.dev/</a><p>Step-by-step FastAPI tutorial (blog API from scratch): <a href="https://github.com/mr-fatalyst/fastapi-oxyde-example" rel="nofollow">https://github.com/mr-fatalyst/fastapi-oxyde-example</a>
Show HN: Oxyde – Pydantic-native async ORM with a Rust core
Hi HN! I built Oxyde because I was tired of duplicating my models.<p>If you use FastAPI, you know the drill. You define Pydantic models for your API, then define separate ORM models for your database, then write converters between them. SQLModel tries to fix this but it's still SQLAlchemy underneath. Tortoise gives you a nice Django-style API but its own model system. Django ORM is great but welded to the framework.<p>I wanted something simple: your Pydantic model IS your database model. One class, full validation on input and output, native type hints, zero duplication. The query API is Django-style (.objects.filter(), .exclude(), Q/F expressions) because I think it's one of the best designs out there.<p><i>Explicit over implicit.</i> I tried to remove all the magic. Queries don't touch the database until you call a terminal method like .all(), .get(), or .first(). If you don't explicitly call .join() or .prefetch(), related data won't be loaded. No lazy loading, no surprise N+1 queries behind your back. You see exactly what hits the database by reading the code.<p><i>Type safety</i> was a big motivation. Python's weak spot is runtime surprises, so Oxyde tackles this on three levels: (1) when you run makemigrations, it also generates .pyi stub files with fully typed queries, so your IDE knows that filter(age__gte=...) takes an int, that create() accepts exactly the fields your model has, and that .all() returns list[User] not list[Any]; (2) Pydantic validates data going into the database; (3) Pydantic validates data coming back out via model_validate(). You get autocompletion, red squiggles on typos, and runtime guarantees, all from the same model definition.<p><i>Why Rust?</i> Not for speed as a goal. I don't do "language X is better" debates. Each one is good at what it was made for. Python is hard to beat for expressing business logic. But infrastructure stuff like SQL generation, connection pooling, and row serialization is where a systems language makes sense. So I split it: Python handles your models and business logic, Rust handles the database plumbing. Queries are built as an IR in Python, serialized via MessagePack, sent to Rust which generates dialect-specific SQL, executes it, and streams results back. Speed is a side effect of this split, not the goal. But since you're not paying a performance tax for the convenience, here are the benchmarks if curious: <a href="https://oxyde.fatalyst.dev/latest/advanced/benchmarks/" rel="nofollow">https://oxyde.fatalyst.dev/latest/advanced/benchmarks/</a><p>What's there today: Django-style migrations (makemigrations / migrate), transactions with savepoints, joins and prefetch, PostgreSQL + SQLite + MySQL, FastAPI integration, and an auto-generated admin panel that works with FastAPI, Litestar, Sanic, Quart, and Falcon (<a href="https://github.com/mr-fatalyst/oxyde-admin" rel="nofollow">https://github.com/mr-fatalyst/oxyde-admin</a>).<p>It's v0.5, beta, active development, API might still change. This is my attempt to build the ORM I personally wanted to use. Would love feedback, criticism, ideas.<p>Docs: <a href="https://oxyde.fatalyst.dev/" rel="nofollow">https://oxyde.fatalyst.dev/</a><p>Step-by-step FastAPI tutorial (blog API from scratch): <a href="https://github.com/mr-fatalyst/fastapi-oxyde-example" rel="nofollow">https://github.com/mr-fatalyst/fastapi-oxyde-example</a>
Show HN: Claude Code skills that build complete Godot games
I’ve been working on this for about a year through four major rewrites. Godogen is a pipeline that takes a text prompt, designs the architecture, generates 2D/3D assets, writes the GDScript, and tests it visually. The output is a complete, playable Godot 4 project.<p>Getting LLMs to reliably generate functional games required solving three specific engineering bottlenecks:<p>1. The Training Data Scarcity: LLMs barely know GDScript. It has ~850 classes and a Python-like syntax that will happily let a model hallucinate Python idioms that fail to compile. To fix this, I built a custom reference system: a hand-written language spec, full API docs converted from Godot's XML source, and a quirks database for engine behaviors you can't learn from docs alone. Because 850 classes blow up the context window, the agent lazy-loads only the specific APIs it needs at runtime.<p>2. The Build-Time vs. Runtime State: Scenes are generated by headless scripts that build the node graph in memory and serialize it to .tscn files. This avoids the fragility of hand-editing Godot's serialization format. But it means certain engine features (like `@onready` or signal connections) aren't available at build time—they only exist when the game actually runs. Teaching the model which APIs are available at which phase — and that every node needs its owner set correctly or it silently vanishes on save — took careful prompting but paid off.<p>3. The Evaluation Loop: A coding agent is inherently biased toward its own output. To stop it from cheating, a separate Gemini Flash agent acts as visual QA. It sees only the rendered screenshots from the running engine—no code—and compares them against a generated reference image. It catches the visual bugs text analysis misses: z-fighting, floating objects, physics explosions, and grid-like placements that should be organic.<p>Architecturally, it runs as two Claude Code skills: an orchestrator that plans the pipeline, and a task executor that implements each piece in a `context: fork` window so mistakes and state don't accumulate.<p>Everything is open source: <a href="https://github.com/htdt/godogen" rel="nofollow">https://github.com/htdt/godogen</a><p>Demo video (real games, not cherry-picked screenshots): <a href="https://youtu.be/eUz19GROIpY" rel="nofollow">https://youtu.be/eUz19GROIpY</a><p>Blog post with the full story (all the wrong turns) coming soon. Happy to answer questions.
Show HN: Claude Code skills that build complete Godot games
I’ve been working on this for about a year through four major rewrites. Godogen is a pipeline that takes a text prompt, designs the architecture, generates 2D/3D assets, writes the GDScript, and tests it visually. The output is a complete, playable Godot 4 project.<p>Getting LLMs to reliably generate functional games required solving three specific engineering bottlenecks:<p>1. The Training Data Scarcity: LLMs barely know GDScript. It has ~850 classes and a Python-like syntax that will happily let a model hallucinate Python idioms that fail to compile. To fix this, I built a custom reference system: a hand-written language spec, full API docs converted from Godot's XML source, and a quirks database for engine behaviors you can't learn from docs alone. Because 850 classes blow up the context window, the agent lazy-loads only the specific APIs it needs at runtime.<p>2. The Build-Time vs. Runtime State: Scenes are generated by headless scripts that build the node graph in memory and serialize it to .tscn files. This avoids the fragility of hand-editing Godot's serialization format. But it means certain engine features (like `@onready` or signal connections) aren't available at build time—they only exist when the game actually runs. Teaching the model which APIs are available at which phase — and that every node needs its owner set correctly or it silently vanishes on save — took careful prompting but paid off.<p>3. The Evaluation Loop: A coding agent is inherently biased toward its own output. To stop it from cheating, a separate Gemini Flash agent acts as visual QA. It sees only the rendered screenshots from the running engine—no code—and compares them against a generated reference image. It catches the visual bugs text analysis misses: z-fighting, floating objects, physics explosions, and grid-like placements that should be organic.<p>Architecturally, it runs as two Claude Code skills: an orchestrator that plans the pipeline, and a task executor that implements each piece in a `context: fork` window so mistakes and state don't accumulate.<p>Everything is open source: <a href="https://github.com/htdt/godogen" rel="nofollow">https://github.com/htdt/godogen</a><p>Demo video (real games, not cherry-picked screenshots): <a href="https://youtu.be/eUz19GROIpY" rel="nofollow">https://youtu.be/eUz19GROIpY</a><p>Blog post with the full story (all the wrong turns) coming soon. Happy to answer questions.
Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300
Show HN: GDSL – 800 line kernel: Lisp subset in 500, C subset in 1300
Show HN: Lux – Drop-in Redis replacement in Rust. 5.6x faster, ~1MB Docker image