The best Hacker News stories from Show from the past week
Latest posts:
Show HN: LemonSlice – Upgrade your voice agents to real-time video
Hey HN, we're the co-founders of LemonSlice (try our HN playground here: <a href="https://lemonslice.com/hn">https://lemonslice.com/hn</a>). We train interactive avatar video models. Our API lets you upload a photo and immediately jump into a FaceTime-style call with that character. Here's a demo: <a href="https://www.loom.com/share/941577113141418e80d2834c83a5a0a9" rel="nofollow">https://www.loom.com/share/941577113141418e80d2834c83a5a0a9</a><p>Chatbots are everywhere and voice AI has taken off, but we believe video avatars will be the most common form factor for conversational AI. Most people would rather watch something than read it. The problem is that generating video in real-time is hard, and overcoming the uncanny valley is even harder.<p>We haven’t broken the uncanny valley yet. Nobody has. But we’re getting close and our photorealistic avatars are currently best-in-class (judge for yourself: <a href="https://lemonslice.com/try/taylor">https://lemonslice.com/try/taylor</a>). Plus, we're the only avatar model that can do animals and heavily stylized cartoons. Try it: <a href="https://lemonslice.com/try/alien">https://lemonslice.com/try/alien</a>. Warning! Talking to this little guy may improve your mood.<p>Today we're releasing our new model* - Lemon Slice 2, a 20B-parameter diffusion transformer that generates infinite-length video at 20fps on a single GPU - and opening up our API.<p>How did we get a video diffusion model to run in real-time? There was no single trick, just a lot of them stacked together. The first big change was making our model causal. Standard video diffusion models are bidirectional (they look at frames both before and after the current one), which means you can't stream.<p>From there it was about fitting everything on one GPU. We switched from full to sliding window attention, which killed our memory bottleneck. We distilled from 40 denoising steps down to just a few - quality degraded less than we feared, especially after using GAN-based distillation (though tuning that adversarial loss to avoid mode collapse was its own adventure).<p>And the rest was inference work: modifying RoPE from complex to real (this one was cool!), precision tuning, fusing kernels, a special rolling KV cache, lots of other caching, and more. We kept shaving off milliseconds wherever we could and eventually got to real-time.<p>We set up a guest playground for HN so you can create and talk to characters without logging in: <a href="https://lemonslice.com/hn">https://lemonslice.com/hn</a>. For those who want to build with our API (we have a new LiveKit integration that we’re pumped about!), grab a coupon code in the HN playground for your first Pro month free ($100 value). See the docs: <a href="https://lemonslice.com/docs">https://lemonslice.com/docs</a>. Pricing is usage-based at $0.12-0.20/min for video generation.<p>Looking forward to your feedback!<p>EDIT: Tell us what characters you want to see in the comments and we can make them for you to talk to (e.g. Max Headroom)<p>*We did a Show HN last year for our V1 model: <a href="https://news.ycombinator.com/item?id=43785044">https://news.ycombinator.com/item?id=43785044</a>. It was technically impressive but so bad compared to what we have today.
Show HN: LemonSlice – Upgrade your voice agents to real-time video
Hey HN, we're the co-founders of LemonSlice (try our HN playground here: <a href="https://lemonslice.com/hn">https://lemonslice.com/hn</a>). We train interactive avatar video models. Our API lets you upload a photo and immediately jump into a FaceTime-style call with that character. Here's a demo: <a href="https://www.loom.com/share/941577113141418e80d2834c83a5a0a9" rel="nofollow">https://www.loom.com/share/941577113141418e80d2834c83a5a0a9</a><p>Chatbots are everywhere and voice AI has taken off, but we believe video avatars will be the most common form factor for conversational AI. Most people would rather watch something than read it. The problem is that generating video in real-time is hard, and overcoming the uncanny valley is even harder.<p>We haven’t broken the uncanny valley yet. Nobody has. But we’re getting close and our photorealistic avatars are currently best-in-class (judge for yourself: <a href="https://lemonslice.com/try/taylor">https://lemonslice.com/try/taylor</a>). Plus, we're the only avatar model that can do animals and heavily stylized cartoons. Try it: <a href="https://lemonslice.com/try/alien">https://lemonslice.com/try/alien</a>. Warning! Talking to this little guy may improve your mood.<p>Today we're releasing our new model* - Lemon Slice 2, a 20B-parameter diffusion transformer that generates infinite-length video at 20fps on a single GPU - and opening up our API.<p>How did we get a video diffusion model to run in real-time? There was no single trick, just a lot of them stacked together. The first big change was making our model causal. Standard video diffusion models are bidirectional (they look at frames both before and after the current one), which means you can't stream.<p>From there it was about fitting everything on one GPU. We switched from full to sliding window attention, which killed our memory bottleneck. We distilled from 40 denoising steps down to just a few - quality degraded less than we feared, especially after using GAN-based distillation (though tuning that adversarial loss to avoid mode collapse was its own adventure).<p>And the rest was inference work: modifying RoPE from complex to real (this one was cool!), precision tuning, fusing kernels, a special rolling KV cache, lots of other caching, and more. We kept shaving off milliseconds wherever we could and eventually got to real-time.<p>We set up a guest playground for HN so you can create and talk to characters without logging in: <a href="https://lemonslice.com/hn">https://lemonslice.com/hn</a>. For those who want to build with our API (we have a new LiveKit integration that we’re pumped about!), grab a coupon code in the HN playground for your first Pro month free ($100 value). See the docs: <a href="https://lemonslice.com/docs">https://lemonslice.com/docs</a>. Pricing is usage-based at $0.12-0.20/min for video generation.<p>Looking forward to your feedback!<p>EDIT: Tell us what characters you want to see in the comments and we can make them for you to talk to (e.g. Max Headroom)<p>*We did a Show HN last year for our V1 model: <a href="https://news.ycombinator.com/item?id=43785044">https://news.ycombinator.com/item?id=43785044</a>. It was technically impressive but so bad compared to what we have today.
Show HN: One Human + One Agent = One Browser From Scratch in 20K LOC
Related: <a href="https://simonwillison.net/2026/Jan/27/one-human-one-agent-one-browser/" rel="nofollow">https://simonwillison.net/2026/Jan/27/one-human-one-agent-on...</a>
Show HN: One Human + One Agent = One Browser From Scratch in 20K LOC
Related: <a href="https://simonwillison.net/2026/Jan/27/one-human-one-agent-one-browser/" rel="nofollow">https://simonwillison.net/2026/Jan/27/one-human-one-agent-on...</a>
Show HN: Only 1 LLM can fly a drone
Show HN: Only 1 LLM can fly a drone
Show HN: Bonsplit – Tabs and splits for native macOS apps
Show HN: Bonsplit – Tabs and splits for native macOS apps
Show HN: Coi – A language that compiles to WASM, beats React/Vue
I usually build web games in C++, but using Emscripten always felt like overkill for what I was doing. I don't need full POSIX emulation or a massive standard library just to render some stuff to a canvas and handle basic UI.<p>The main thing I wanted to solve was the JS/WASM interop bottleneck. Instead of using the standard glue code for every call, I moved everything to a Shared Memory architecture using Command and Event buffers.<p>The way it works is that I batch all the instructions in WASM and then just send a single "flush" signal to JS. The JS side then reads everything directly out of Shared Memory in one go. It’s way more efficient, I ran a benchmark rendering 10k rectangles on a canvas and the difference was huge: Emscripten hit around 40 FPS, while my setup hit 100 FPS.<p>But writing DOM logic in C++ is painful, so I built Coi. It’s a component-based language that statically analyzes changes at compile-time to enable O(1) reactivity. Unlike traditional frameworks, there is no Virtual DOM overhead; the compiler maps state changes directly to specific handles in the command buffer.<p>I recently benchmarked this against React and Vue on a 1,000-row table: Coi came out on top for row creation, row updating and element swapping because it avoids the "diffing" step entirely and minimizes bridge crossings. Its bundle size was also the smallest of the three.<p>One of the coolest things about the architecture is how the standard library works. If I want to support a new browser API (like Web Audio or a new Canvas feature), I just add the definition to my WebCC schema file. When I recompile the Coi compiler, the language automatically gains a new standard library function to access that API. There is zero manual wrapping involved.<p>I'm really proud of how it's coming along. It combines the performance of a custom WASM stack with a syntax that actually feels good to write (for me atleast :P). Plus, since the intermediate step is C++, I’m looking into making it work on the server side too, which would allow for sharing components across the whole stack.<p>Example (Coi Code):<p>component Counter(string label, mut int& value) {<p><pre><code> def add(int i) : void {
value += i;
}
style {
.counter {
display: flex;
gap: 12px;
align-items: center;
}
button {
padding: 8px 16px;
cursor: pointer;
}
}
view {
<div class="counter">
<span>{label}: {value}</span>
<button onclick={add(1)}>+</button>
<button onclick={add(-1)}>-</button>
</div>
}</code></pre>
}<p>component App {
mut int score = 0;<p><pre><code> style {
.app {
padding: 24px;
font-family: system-ui;
}
h1 {
color: #1a73e8;
}
.win {
color: #34a853;
font-weight: bold;
}
}
view {
<div class="app">
<h1>Score: {score}</h1>
<Counter label="Player" &value={score} />
<if score >= 10>
<p class="win">You win!</p>
</if>
</div>
}</code></pre>
}<p>app {
root = App;
title = "My Counter App";
description = "A simple counter built with Coi";
lang = "en";
}<p>Live Demo: <a href="https://io-eric.github.io/coi" rel="nofollow">https://io-eric.github.io/coi</a><p>Coi (The Language): <a href="https://github.com/io-eric/coi" rel="nofollow">https://github.com/io-eric/coi</a><p>WebCC: <a href="https://github.com/io-eric/webcc" rel="nofollow">https://github.com/io-eric/webcc</a><p>I'd love to hear what you think. It's still far from finished, but as a side project I'm really excited about :)
Show HN: Coi – A language that compiles to WASM, beats React/Vue
I usually build web games in C++, but using Emscripten always felt like overkill for what I was doing. I don't need full POSIX emulation or a massive standard library just to render some stuff to a canvas and handle basic UI.<p>The main thing I wanted to solve was the JS/WASM interop bottleneck. Instead of using the standard glue code for every call, I moved everything to a Shared Memory architecture using Command and Event buffers.<p>The way it works is that I batch all the instructions in WASM and then just send a single "flush" signal to JS. The JS side then reads everything directly out of Shared Memory in one go. It’s way more efficient, I ran a benchmark rendering 10k rectangles on a canvas and the difference was huge: Emscripten hit around 40 FPS, while my setup hit 100 FPS.<p>But writing DOM logic in C++ is painful, so I built Coi. It’s a component-based language that statically analyzes changes at compile-time to enable O(1) reactivity. Unlike traditional frameworks, there is no Virtual DOM overhead; the compiler maps state changes directly to specific handles in the command buffer.<p>I recently benchmarked this against React and Vue on a 1,000-row table: Coi came out on top for row creation, row updating and element swapping because it avoids the "diffing" step entirely and minimizes bridge crossings. Its bundle size was also the smallest of the three.<p>One of the coolest things about the architecture is how the standard library works. If I want to support a new browser API (like Web Audio or a new Canvas feature), I just add the definition to my WebCC schema file. When I recompile the Coi compiler, the language automatically gains a new standard library function to access that API. There is zero manual wrapping involved.<p>I'm really proud of how it's coming along. It combines the performance of a custom WASM stack with a syntax that actually feels good to write (for me atleast :P). Plus, since the intermediate step is C++, I’m looking into making it work on the server side too, which would allow for sharing components across the whole stack.<p>Example (Coi Code):<p>component Counter(string label, mut int& value) {<p><pre><code> def add(int i) : void {
value += i;
}
style {
.counter {
display: flex;
gap: 12px;
align-items: center;
}
button {
padding: 8px 16px;
cursor: pointer;
}
}
view {
<div class="counter">
<span>{label}: {value}</span>
<button onclick={add(1)}>+</button>
<button onclick={add(-1)}>-</button>
</div>
}</code></pre>
}<p>component App {
mut int score = 0;<p><pre><code> style {
.app {
padding: 24px;
font-family: system-ui;
}
h1 {
color: #1a73e8;
}
.win {
color: #34a853;
font-weight: bold;
}
}
view {
<div class="app">
<h1>Score: {score}</h1>
<Counter label="Player" &value={score} />
<if score >= 10>
<p class="win">You win!</p>
</if>
</div>
}</code></pre>
}<p>app {
root = App;
title = "My Counter App";
description = "A simple counter built with Coi";
lang = "en";
}<p>Live Demo: <a href="https://io-eric.github.io/coi" rel="nofollow">https://io-eric.github.io/coi</a><p>Coi (The Language): <a href="https://github.com/io-eric/coi" rel="nofollow">https://github.com/io-eric/coi</a><p>WebCC: <a href="https://github.com/io-eric/webcc" rel="nofollow">https://github.com/io-eric/webcc</a><p>I'd love to hear what you think. It's still far from finished, but as a side project I'm really excited about :)
Show HN: Whosthere: A LAN discovery tool with a modern TUI, written in Go
Show HN: Whosthere: A LAN discovery tool with a modern TUI, written in Go
Show HN: Sweep, Open-weights 1.5B model for next-edit autocomplete
Hey HN, we trained and open-sourced a 1.5B model that predicts your next edits, similar to Cursor. You can download the weights here (<a href="https://huggingface.co/sweepai/sweep-next-edit-1.5b" rel="nofollow">https://huggingface.co/sweepai/sweep-next-edit-1.5b</a>) or try it in our JetBrains plugin (<a href="https://plugins.jetbrains.com/plugin/26860-sweep-ai-autocomplete--coding-agent" rel="nofollow">https://plugins.jetbrains.com/plugin/26860-sweep-ai-autocomp...</a>).<p>Next-edit autocomplete differs from standard autocomplete by using your recent edits as context when predicting completions. The model is small enough to run locally while outperforming models 4x its size on both speed and accuracy.<p>We tested against Mercury (Inception), Zeta (Zed), and Instinct (Continue) across five benchmarks: next-edit above/below cursor, tab-to-jump for distant changes, standard FIM, and noisiness. We found exact-match accuracy correlates best with real usability because code is fairly precise and the solution space is small.<p>Prompt format turned out to matter more than we expected. We ran a genetic algorithm over 30+ diff formats and found simple `original`/`updated` blocks beat unified diffs. The verbose format is just easier for smaller models to understand.<p>Training was SFT on ~100k examples from permissively-licensed repos (4hrs on 8xH100), then RL for 2000 steps with tree-sitter parse checking and size regularization. The RL step fixes edge cases SFT can’t like, generating code that doesn’t parse or overly verbose outputs.<p>We're open-sourcing the weights so the community can build fast, privacy-preserving autocomplete for any editor. If you're building for VSCode, Neovim, or something else, we'd love to see what you make with it!
Show HN: isometric.nyc – giant isometric pixel art map of NYC
Hey HN! I wanted to share something I built over the last few weeks: isometric.nyc is a massive isometric pixel art map of NYC, built with nano banana and coding agents.<p>I didn't write a single line of code.<p>Of course no-code doesn't mean no-engineering. This project took a lot more manual labor than I'd hoped!<p>I wrote a deep dive on the workflow and some thoughts about the future of AI coding and creativity:<p><a href="http://cannoneyed.com/projects/isometric-nyc" rel="nofollow">http://cannoneyed.com/projects/isometric-nyc</a>
Show HN: Rails UI
Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps)
Creator here. I built ChartGPU because I kept hitting the same wall: charting libraries that claim to be "fast" but choke past 100K data points.<p>The core insight: Canvas2D is fundamentally CPU-bound. Even WebGL chart libraries still do most computation on the CPU. So I moved everything to the GPU via WebGPU:<p>- LTTB downsampling runs as a compute shader
- Hit-testing for tooltips/hover is GPU-accelerated
- Rendering uses instanced draws (one draw call per series)<p>The result: 1M points at 60fps with smooth zoom/pan.<p>Live demo: <a href="https://chartgpu.github.io/ChartGPU/examples/million-points/" rel="nofollow">https://chartgpu.github.io/ChartGPU/examples/million-points/</a><p>Currently supports line, area, bar, scatter, pie, and candlestick charts. MIT licensed, available on npm: `npm install chartgpu`<p>Happy to answer questions about WebGPU internals or architecture decisions.
Show HN: Mastra 1.0, open-source JavaScript agent framework from the Gatsby devs
Hi HN, we're Sam, Shane, and Abhi.<p>Almost a year ago, we first shared Mastra here (<a href="https://news.ycombinator.com/item?id=43103073">https://news.ycombinator.com/item?id=43103073</a>). It’s kind of fun looking back since we were only a few months into building at the time. The HN community gave a lot of enthusiasm and some helpful feedback.<p>Today, we released Mastra 1.0 in stable, so we wanted to come back and talk about what’s changed.<p>If you’re new to Mastra, it's an open-source TypeScript agent framework that also lets you create multi-agent workflows, run evals, inspect in a local studio, and emit observability.<p>Since our last post, Mastra has grown to over 300k weekly npm downloads and 19.4k GitHub stars. It’s now Apache 2.0 licensed and runs in prod at companies like Replit, PayPal, and Sanity.<p>Agent development is changing quickly, so we’ve added a lot since February:<p>- Native model routing: You can access 600+ models from 40+ providers by specifying a model string (e.g., `openai/gpt-5.2-codex`) with TS autocomplete and fallbacks.<p>- Guardrails: Low-latency input and output processors for prompt injection detection, PII redaction, and content moderation. The tricky thing here was the low-latency part.<p>- Scorers: An async eval primitive for grading agent outputs. Users were asking how they should do evals. We wanted to make it easy to attach to Mastra agents, runnable in Mastra studio, and save results in Mastra storage.<p>- Plus a few other features like AI tracing (per-call costing for Langfuse, Braintrust, etc), memory processors, a `.network()` method that turns any agent into a routing agent, and server adapters to integrate Mastra within an existing Express/Hono server.<p>(That last one took a bit of time, we went down the ESM/CJS bundling rabbithole, ran into lots of monorepo issues, and ultimately opted for a more explicit approach.)<p>Anyway, we'd love for you to try Mastra out and let us know what you think. You can get started with `npm create mastra@latest`.<p>We'll be around and happy to answer any questions!
Show HN: Pdfwithlove – PDF tools that run 100% locally (no uploads, no back end)
Most PDF web tools make millions by uploading documents that never needed to leave your computer.<p>pdfwithlove does the opposite:<p>1. 100% local processing
2. No uploads, no backend, no tracking<p>Features include merge/split/edit/compress PDFs, watermarks & signatures, and image/HTML/Office → PDF conversion.
Show HN: Pdfwithlove – PDF tools that run 100% locally (no uploads, no back end)
Most PDF web tools make millions by uploading documents that never needed to leave your computer.<p>pdfwithlove does the opposite:<p>1. 100% local processing
2. No uploads, no backend, no tracking<p>Features include merge/split/edit/compress PDFs, watermarks & signatures, and image/HTML/Office → PDF conversion.
Show HN: I quit coding years ago. AI brought me back
Quick background: I used to code. Studied it in school, wrote some projects, but eventually convinced myself I wasn't cut out for it. Too slow, too many bugs, imposter syndrome — the usual story. So I pivoted, ended up as an investment associate at an early-stage angel fund, and haven't written real code in years.<p>Fast forward to now. I'm a Buffett nerd — big believer in compound interest as a mental model for life. I run compound interest calculations constantly. Not because I need to, but because watching numbers grow over 30-40 years keeps me patient when markets get wild. It's basically meditation for long-term investors.<p>The problem? Every compound interest calculator online is terrible. Ugly interfaces, ads covering half the screen, can't customize compounding frequency properly, no year-by-year breakdowns. I've tried so many. They all suck.<p>When vibe coding started blowing up, something clicked. Maybe I could actually build the calculators I wanted? I don't have to be a "real developer" anymore — I just need to describe what I want clearly.<p>So I tried it.<p>Two weeks and ~$100（Opus 4.5 thinking model） in API costs later: I somehow have 60+ calculators. Started with compound interest, naturally. Then thought "well, while I'm here..." and added mortgage, loan amortization, savings goals, retirement projections. Then it spiraled — BMI calculator, timezone converter, regex tester. Oops.<p>The AI (I'm using Claude via Windsurf) handled the grunt work beautifully. I'd describe exactly what I wanted — "compound interest calculator with monthly/quarterly/yearly options, year-by-year breakdown table, recurring contribution support" — and it delivered. With validation, nice components, even tests.<p>What I realized: my years away from coding weren't wasted. I still understood architecture, I still knew what good UX looked like, I still had domain expertise (financial math). I just couldn't type it all out efficiently. AI filled that gap perfectly.<p>Vibe coding didn't make me a 10x engineer. But it gave me permission to build again. Ideas I've had for years suddenly feel achievable. That's honestly the bigger win for me.<p>Stack: Next.js, React, TailwindCSS, shadcn/ui, four languages (EN/DE/FR/JA). The AI picked most of this when I said "modern and clean."<p>Site's live at <a href="https://calquio.com" rel="nofollow">https://calquio.com</a> . The compound interest calculator is still my favorite page — finally exactly what I wanted.<p>Curious if others have similar stories. Anyone else come back to building after stepping away?