The best Hacker News stories from Show from the past day

from

All Show

from the past*

day week month

with these search terms:

Create follow Go back

Latest posts:

Show HN: I built a fast RSS reader in Zig

Well, I certainly tried. I had to, because it has a certain quirk inspired by "digital minimalism."<p>The quirk is that it only allows you to fetch new articles once per day (or X days).<p>Why? Let me explain...<p>I want my internet content to be like a boring newspaper. You get it in the morning, and you read the whole thing while sipping your morning coffee, and then you're done! No more new information for today. No pings, no alerts, peace, quiet, zen, etc.<p>But with that, I needed it to be able to fetch all articles from my hundreds of feeds in one sitting. This is where Zig and curl optimisations come in. I tried to do all the tricks in the book. If I missed something, let me know!<p>First off, I'm using curl multi for the network layer. The cool thing is it automatically does HTTP/2 multiplexing, which means if your feeds are hosted on the same CDN it reuses the same connection. I've got it configured to handle 50 connections total with up to 6 per host, which seems to be the sweet spot before servers start getting suspicious. Also, conditional GETs. If a feed hasn't changed since last time, the server just says "Not Modified" and we bail immediately.<p>While curl is downloading feeds, I wouldn't want CPU just being idle so the moment curl finishes downloading a single feed, it fires a callback that immediately throws the XML into a worker thread pool for parsing. The main thread keeps managing all the network stuff while worker threads are chewing through XML in parallel. Zig's memory model is perfect for this. Each feed gets its own ArenaAllocator, which is basically a playground where you can allocate strings during parsing, then when we're done, we just nuke the entire arena in one go.<p>For parsing itself, I'm using libexpat because it doesn't load the entire XML into memory like a DOM parser would. This matters because some podcast feeds especially are like 10MB+ of XML. So with smart truncation we download the first few X mb's (configurable), scan backwards to find the last complete item tag, cut it there, and parse just that. Keeps memory usage sane even when feed sizes get massive.<p>And for the UI I just pipe everything to the system's "less" command. You get vim navigation, searching, and paging for free. Plus I'm using OSC 8 hyperlinks, so you can actually click links to open them on your browser. Zero TUI framework needed. I've also included OPML import/export and feed groups as additional features.<p>The result: content from hundreds of RSS feeds retrieved in matter of seconds, and peace of mind for the rest of the day.<p>The code is open source and MIT licensed. If you have ideas on how to make it even faster or better, comment below. Feature requests and other suggestions are also welcome, here or GitHub.

Show HN: I built a fast RSS reader in Zig

Well, I certainly tried. I had to, because it has a certain quirk inspired by "digital minimalism."<p>The quirk is that it only allows you to fetch new articles once per day (or X days).<p>Why? Let me explain...<p>I want my internet content to be like a boring newspaper. You get it in the morning, and you read the whole thing while sipping your morning coffee, and then you're done! No more new information for today. No pings, no alerts, peace, quiet, zen, etc.<p>But with that, I needed it to be able to fetch all articles from my hundreds of feeds in one sitting. This is where Zig and curl optimisations come in. I tried to do all the tricks in the book. If I missed something, let me know!<p>First off, I'm using curl multi for the network layer. The cool thing is it automatically does HTTP/2 multiplexing, which means if your feeds are hosted on the same CDN it reuses the same connection. I've got it configured to handle 50 connections total with up to 6 per host, which seems to be the sweet spot before servers start getting suspicious. Also, conditional GETs. If a feed hasn't changed since last time, the server just says "Not Modified" and we bail immediately.<p>While curl is downloading feeds, I wouldn't want CPU just being idle so the moment curl finishes downloading a single feed, it fires a callback that immediately throws the XML into a worker thread pool for parsing. The main thread keeps managing all the network stuff while worker threads are chewing through XML in parallel. Zig's memory model is perfect for this. Each feed gets its own ArenaAllocator, which is basically a playground where you can allocate strings during parsing, then when we're done, we just nuke the entire arena in one go.<p>For parsing itself, I'm using libexpat because it doesn't load the entire XML into memory like a DOM parser would. This matters because some podcast feeds especially are like 10MB+ of XML. So with smart truncation we download the first few X mb's (configurable), scan backwards to find the last complete item tag, cut it there, and parse just that. Keeps memory usage sane even when feed sizes get massive.<p>And for the UI I just pipe everything to the system's "less" command. You get vim navigation, searching, and paging for free. Plus I'm using OSC 8 hyperlinks, so you can actually click links to open them on your browser. Zero TUI framework needed. I've also included OPML import/export and feed groups as additional features.<p>The result: content from hundreds of RSS feeds retrieved in matter of seconds, and peace of mind for the rest of the day.<p>The code is open source and MIT licensed. If you have ideas on how to make it even faster or better, comment below. Feature requests and other suggestions are also welcome, here or GitHub.

Show HN: I built a fast RSS reader in Zig

Well, I certainly tried. I had to, because it has a certain quirk inspired by "digital minimalism."<p>The quirk is that it only allows you to fetch new articles once per day (or X days).<p>Why? Let me explain...<p>I want my internet content to be like a boring newspaper. You get it in the morning, and you read the whole thing while sipping your morning coffee, and then you're done! No more new information for today. No pings, no alerts, peace, quiet, zen, etc.<p>But with that, I needed it to be able to fetch all articles from my hundreds of feeds in one sitting. This is where Zig and curl optimisations come in. I tried to do all the tricks in the book. If I missed something, let me know!<p>First off, I'm using curl multi for the network layer. The cool thing is it automatically does HTTP/2 multiplexing, which means if your feeds are hosted on the same CDN it reuses the same connection. I've got it configured to handle 50 connections total with up to 6 per host, which seems to be the sweet spot before servers start getting suspicious. Also, conditional GETs. If a feed hasn't changed since last time, the server just says "Not Modified" and we bail immediately.<p>While curl is downloading feeds, I wouldn't want CPU just being idle so the moment curl finishes downloading a single feed, it fires a callback that immediately throws the XML into a worker thread pool for parsing. The main thread keeps managing all the network stuff while worker threads are chewing through XML in parallel. Zig's memory model is perfect for this. Each feed gets its own ArenaAllocator, which is basically a playground where you can allocate strings during parsing, then when we're done, we just nuke the entire arena in one go.<p>For parsing itself, I'm using libexpat because it doesn't load the entire XML into memory like a DOM parser would. This matters because some podcast feeds especially are like 10MB+ of XML. So with smart truncation we download the first few X mb's (configurable), scan backwards to find the last complete item tag, cut it there, and parse just that. Keeps memory usage sane even when feed sizes get massive.<p>And for the UI I just pipe everything to the system's "less" command. You get vim navigation, searching, and paging for free. Plus I'm using OSC 8 hyperlinks, so you can actually click links to open them on your browser. Zero TUI framework needed. I've also included OPML import/export and feed groups as additional features.<p>The result: content from hundreds of RSS feeds retrieved in matter of seconds, and peace of mind for the rest of the day.<p>The code is open source and MIT licensed. If you have ideas on how to make it even faster or better, comment below. Feature requests and other suggestions are also welcome, here or GitHub.

Show HN: Learn Japanese contextually while browsing

Hi HN,<p>Just wanted to share a tool i've been working on to help with my own study routine. It’s a browser extension called Lingoku.<p>The idea is simple: we spend hours browsing the web in English every day. This tool replaces some of the english words with Japanese vocabulary based on your japanese level (Similar to Toucan, but with a better user experience).<p>It’s basically an attempt to make the "i+1" method actually passive, you understand the sentence because it's mostly english, but you pick up Japanese words naturally from the context. It uses an LLM in the backend to make sure the translations fit the context (so it distinguishes between different meanings of the same word).<p>since it uses paid AI APIs for the words replacement, I couldn't make it 100% free (server costs are real, unfortunately). However, there is a "forever free" plan with daily credits that doesn't require a credit card. it should be enough for casual daily browsing.<p>I built this because I struggle with Anki burnout and wanted a way to review words without feeling like i am "studying"<p>It supports Chrome, Edge, and Firefox now. would love any feedback or feature requests!<p><a href="https://lingoku.ai/learn-japanese" rel="nofollow">https://lingoku.ai/learn-japanese</a>

Show HN: My Tizen multiplayer drawing game flopped, but then hit 100M drawings

Hi HN,<p>I built the first version of Drawize back in late 2016 specifically for a Samsung Tizen OS app contest. I crunched and built the whole thing (including the real-time multiplayer engine) in under 4 weeks.<p>It didn’t win anything in the contest.<p>Since it was built with web tech anyway, I published it on the open web in early 2017 just to see what would happen. It started living its own life, and today — 8 years later — the database processed the 100,000,000th drawing.<p>On the busiest days it’s been 30k+ active users, and storing 100M drawings currently sits at ~3.16 TB.<p>The milestone moment: I was watching live logs today, terrified the 100Mth drawing would be NSFW. Luckily, the RNG gods smiled and it turned out to be a Red Balloon (You can see the 100Mth drawing here: <a href="https://www.drawize.com/blog/100-million-drawings-milestone" rel="nofollow">https://www.drawize.com/blog/100-million-drawings-milestone</a>)<p>Tech stack (boring but fast):<p>Backend: .NET + WebSockets (real-time sync)<p>Frontend: hand-coded HTML/JS + jQuery (no React, no bundlers)<p>Data: PostgreSQL & MongoDB<p>Storage: Wasabi Cloud (moved there to save on S3 costs)<p>Scaling as a solo dev: real-time lobbies + reconnection edge cases + moderation/content filtering. I use content classification models trained in 2021 to filter bad content, and the real-time multiplayer side is mostly highly optimized .NET code.<p>Happy to answer questions about the “failed” Tizen origin, real-time multiplayer on the web, moderation, or how .NET handles the load.

Show HN: Zenflow – orchestrate coding agents without "you're right" loops

Hi HN, I’m Andrew, Founder of Zencoder.<p>While building our IDE extensions and cloud agents, we ran into the same issue many of you likely face when using coding agents in complex repos: agents getting stuck in loops, apologizing, and wasting time.<p>We tried to manage this with scripts, but juggling terminal windows and copy-paste prompting was painful. So we built Zenflow, a free desktop tool to orchestrate AI coding workflows.<p>It handles the things we were missing in standard chat interfaces:<p>Cross-Model Verification: You can have Codex review Claude’s code, or run them in parallel to see which model handles the specific context better.<p>Parallel Execution: Run five different approaches on a backlog item simultaneously—mix "Human-in-the-Loop" for hard problems with "YOLO" runs for simple tasks.<p>Dynamic Workflows: Configured via simple .md files. Agents can actually "rewire" the next steps of the workflow dynamically based on the problem at hand.<p>Project list/kanban views across all workload<p>What we learned building this<p>To tune Zenflow, we ran 100+ experiments across public benchmarks (SWE-Bench-*, T-Bench) and private datasets. Two major takeaways that might interest this community:<p>Benchmark Saturation: Models are becoming progressively overtrained on all versions of SWE-Bench (even Pro). We found public results are diverging significantly from performance on private datasets. If you are building workflows, you can't rely on public benches.<p>The "Goldilocks" Workflow: In autonomous mode, heavy multi-step processes often multiply errors rather than fix them. Massive, complex prompt templates look good on paper but fail in practice. The most reliable setups landed in a narrow “Goldilocks” zone of just enough structure without over-orchestration.<p>The app is free to use and supports Claude Code, Codex, Gemini, and Zencoder.<p>We’ve been dogfooding this heavily, but I'd love to hear your thoughts on the default workflows and if they fit your mental model for agentic coding.<p>Download: <a href="https://zencoder.ai/zenflow" rel="nofollow">https://zencoder.ai/zenflow</a> YT flyby: <a href="https://www.youtube.com/watch?v=67Ai-klT-B8" rel="nofollow">https://www.youtube.com/watch?v=67Ai-klT-B8</a>

Show HN: Solving the ~95% legislative coverage gap using LLM's

Hi HN, I'm Jacek, the solo founder behind this project (Lustra).<p>The Problem: 95% of legislation goes unnoticed because raw legal texts are unreadable. Media coverage is optimized for outrage, not insight.<p>The Solution. I built a digital public infrastructure that:<p>1. Ingests & Sterilizes: Parses raw bills (PDF/XML) from US & PL APIs. Uses LLMs (Vertex AI, temp=0, strict JSON) to strip political spin.<p>2. Civic Algorithm: The main feed isn't sorted by an editorial board. It's sorted by user votes ("Shadow Parliament"). What the community cares about rises to the top.<p>3. Civic Projects: An incubator for citizen legislation. Users submit drafts (like our <i>Human Preservation Act</i>), which are vetted by AI scoring and displayed with visual parity alongside government bills.<p>Tech Stack:<p>Frontend: Flutter (Web & Mobile Monorepo),<p>Backend: Firebase + Google Cloud Run,<p>AI: Vertex AI (Gemini 2.5 Flash),<p>License: PolyForm Noncommercial — source is available for inspection, learning, and non-commercial civic use. Commercial use would require a separate agreement.<p>I am looking for contributors. I have the US and Poland live. EU, UK, FR, DE in pipeline, partially available. I need help building Data Adapters for other parliaments (the core logic is country-agnostic). If you want to help audit the code or add a country, check the repo. The goal is to complete the database as much as possible with current funding.<p>Live App: <a href="https://lustra.news" rel="nofollow">https://lustra.news</a><p>Repo: <a href="https://github.com/fokdelafons/lustra" rel="nofollow">https://github.com/fokdelafons/lustra</a><p>Dev Log: <a href="https://lustrainitiative.substack.com" rel="nofollow">https://lustrainitiative.substack.com</a>

Show HN: Solving the ~95% legislative coverage gap using LLM's

Hi HN, I'm Jacek, the solo founder behind this project (Lustra).<p>The Problem: 95% of legislation goes unnoticed because raw legal texts are unreadable. Media coverage is optimized for outrage, not insight.<p>The Solution. I built a digital public infrastructure that:<p>1. Ingests & Sterilizes: Parses raw bills (PDF/XML) from US & PL APIs. Uses LLMs (Vertex AI, temp=0, strict JSON) to strip political spin.<p>2. Civic Algorithm: The main feed isn't sorted by an editorial board. It's sorted by user votes ("Shadow Parliament"). What the community cares about rises to the top.<p>3. Civic Projects: An incubator for citizen legislation. Users submit drafts (like our <i>Human Preservation Act</i>), which are vetted by AI scoring and displayed with visual parity alongside government bills.<p>Tech Stack:<p>Frontend: Flutter (Web & Mobile Monorepo),<p>Backend: Firebase + Google Cloud Run,<p>AI: Vertex AI (Gemini 2.5 Flash),<p>License: PolyForm Noncommercial — source is available for inspection, learning, and non-commercial civic use. Commercial use would require a separate agreement.<p>I am looking for contributors. I have the US and Poland live. EU, UK, FR, DE in pipeline, partially available. I need help building Data Adapters for other parliaments (the core logic is country-agnostic). If you want to help audit the code or add a country, check the repo. The goal is to complete the database as much as possible with current funding.<p>Live App: <a href="https://lustra.news" rel="nofollow">https://lustra.news</a><p>Repo: <a href="https://github.com/fokdelafons/lustra" rel="nofollow">https://github.com/fokdelafons/lustra</a><p>Dev Log: <a href="https://lustrainitiative.substack.com" rel="nofollow">https://lustrainitiative.substack.com</a>

Show HN: Interactive Common Lisp: An Enhanced REPL

I created this because sometimes I want more than rlwrap but less than emacs. icl aims to hit that middle sweet spot.<p>It's a terminal application with context-aware auto-complete, an interactive object inspector, auto-indentation, syntax colouring, persistent history, and much more. It uses sly to communicate with the child lisp process and aims to be compatible with any sly-supporting implementation. I hope others find it useful!

Show HN: Interactive Common Lisp: An Enhanced REPL

I created this because sometimes I want more than rlwrap but less than emacs. icl aims to hit that middle sweet spot.<p>It's a terminal application with context-aware auto-complete, an interactive object inspector, auto-indentation, syntax colouring, persistent history, and much more. It uses sly to communicate with the child lisp process and aims to be compatible with any sly-supporting implementation. I hope others find it useful!

Show HN: Interactive Common Lisp: An Enhanced REPL

I created this because sometimes I want more than rlwrap but less than emacs. icl aims to hit that middle sweet spot.<p>It's a terminal application with context-aware auto-complete, an interactive object inspector, auto-indentation, syntax colouring, persistent history, and much more. It uses sly to communicate with the child lisp process and aims to be compatible with any sly-supporting implementation. I hope others find it useful!

Show HN: Sqlit – A lazygit-style TUI for SQL databases

I work mostly in the terminal but found myself constantly switching to bloated GUIs like SSMS only for the simple task of browsing tables and run queries. And I didn't find Existing SQL TUIs intuitive, having to read documentation to learn keybindings and CLI flags to connect. Given I had recently switched to linux, I found myself using vs code's sql database extension. Something was awfully wrong.<p>I wanted something like lazygit for databases – run it, connect, and query and frankly just make it enjoyable to access data.<p><pre><code> Sqlit is a keyboard-driven SQL TUI with: - Context-based keybindings (always visible) - Neovim-like interface with normal and insert mode for query editing - Browse databases, tables, views, stored procedures - Adapters for SQL Server, SQLite, PostgreSQL, Turso & more - SSH tunneling support - Themes (Tokyo Night, Nord, Gruvbox etc.) Inspired by lazygit, neovim and lazysql. Built with Python/Textual. </code></pre> Feedback welcome – especially on which adapters to prioritize next. My vision of sqlit is to make a tool that makes it easy to connect and query data, and to do that, and that thing only, really well.<p><a href="https://github.com/Maxteabag/sqlit" rel="nofollow">https://github.com/Maxteabag/sqlit</a>

Show HN: Sqlit – A lazygit-style TUI for SQL databases

I work mostly in the terminal but found myself constantly switching to bloated GUIs like SSMS only for the simple task of browsing tables and run queries. And I didn't find Existing SQL TUIs intuitive, having to read documentation to learn keybindings and CLI flags to connect. Given I had recently switched to linux, I found myself using vs code's sql database extension. Something was awfully wrong.<p>I wanted something like lazygit for databases – run it, connect, and query and frankly just make it enjoyable to access data.<p><pre><code> Sqlit is a keyboard-driven SQL TUI with: - Context-based keybindings (always visible) - Neovim-like interface with normal and insert mode for query editing - Browse databases, tables, views, stored procedures - Adapters for SQL Server, SQLite, PostgreSQL, Turso & more - SSH tunneling support - Themes (Tokyo Night, Nord, Gruvbox etc.) Inspired by lazygit, neovim and lazysql. Built with Python/Textual. </code></pre> Feedback welcome – especially on which adapters to prioritize next. My vision of sqlit is to make a tool that makes it easy to connect and query data, and to do that, and that thing only, really well.<p><a href="https://github.com/Maxteabag/sqlit" rel="nofollow">https://github.com/Maxteabag/sqlit</a>

Show HN: Sqlit – A lazygit-style TUI for SQL databases

I work mostly in the terminal but found myself constantly switching to bloated GUIs like SSMS only for the simple task of browsing tables and run queries. And I didn't find Existing SQL TUIs intuitive, having to read documentation to learn keybindings and CLI flags to connect. Given I had recently switched to linux, I found myself using vs code's sql database extension. Something was awfully wrong.<p>I wanted something like lazygit for databases – run it, connect, and query and frankly just make it enjoyable to access data.<p><pre><code> Sqlit is a keyboard-driven SQL TUI with: - Context-based keybindings (always visible) - Neovim-like interface with normal and insert mode for query editing - Browse databases, tables, views, stored procedures - Adapters for SQL Server, SQLite, PostgreSQL, Turso & more - SSH tunneling support - Themes (Tokyo Night, Nord, Gruvbox etc.) Inspired by lazygit, neovim and lazysql. Built with Python/Textual. </code></pre> Feedback welcome – especially on which adapters to prioritize next. My vision of sqlit is to make a tool that makes it easy to connect and query data, and to do that, and that thing only, really well.<p><a href="https://github.com/Maxteabag/sqlit" rel="nofollow">https://github.com/Maxteabag/sqlit</a>

Show HN: Sub-microsecond (890 ns) trading execution research system

I am sharing a research-grade, open-source trading execution framework that achieves a median end-to-end decision latency of 890 nanoseconds on commodity hardware.<p>The project is designed for education, systems research, and latency instrumentation, not for live trading. It focuses on understanding exactly where every nanosecond goes in a trading execution path.<p>Key features:<p>- Kernel-bypass networking: Direct userspace access to NICs via custom drivers, 20-50 ns RX latency - Lock-free SPSC/MPSC queues: Zero-copy architecture - SIMD feature extraction: About 40 ns per update using AVX-512 - Deterministic replay: Bit-identical execution paths, SHA-256 verified - Nanosecond-level metrics: Full audit logs and performance dashboard<p>Technical stack: C++17 and Rust, NUMA-aware memory allocation, cache-line alignment, inline assembly for hot paths.<p>The framework is modular, allowing experimentation with different NIC drivers, feature extraction pipelines, or order-flow models such as Hawkes processes or Avellaneda-Stoikov logic. Everything is open source and documented.<p>Links:<p>Live demo: <a href="https://submicro.krishnabajpai.me/" rel="nofollow">https://submicro.krishnabajpai.me/</a> Source code: <a href="https://github.com/krish567366/submicro-execution-engine" rel="nofollow">https://github.com/krish567366/submicro-execution-engine</a> Bare-metal NIC drivers: <a href="https://baremetalnic.krishnabajpai.me/" rel="nofollow">https://baremetalnic.krishnabajpai.me/</a><p>I would welcome feedback from anyone working on low-latency systems, networking, or HFT research.<p>Some questions for discussion:<p>- Which part of the execution path is typically hardest to optimize? - What measurement techniques do you trust for sub-microsecond systems?<p>This project is for research and educational purposes only. It does not connect to exchanges or execute real trades. It is intended as a sandbox for understanding ultra-low-latency execution.<p>I am happy to answer questions about methodology, performance, or design trade-offs.

Show HN: Cordon – Reduce large log files to anomalous sections

Cordon uses transformer embeddings and density scoring to identify what's semantically unique in log files, filtering out repetitive noise.<p>The core insight: a critical error repeated 1000x is "normal" (semantically dense). A strange one-off event is anomalous (semantically isolated).<p>Outputs XML-tagged blocks with anomaly scores. Designed to reduce large logs as a form of pre-processing for LLM analysis.<p>Architecture: <a href="https://github.com/calebevans/cordon/blob/main/docs/architecture.md" rel="nofollow">https://github.com/calebevans/cordon/blob/main/docs/architec...</a><p>Benchmark: <a href="https://github.com/calebevans/cordon/blob/main/benchmark/results/README.md" rel="nofollow">https://github.com/calebevans/cordon/blob/main/benchmark/res...</a><p>Trade-offs: intentionally ignores repetitive patterns, uses percentile-based thresholds (relative, not absolute).

Show HN: Dograh – an OSS Vapi alternative to quickly build and test voice agents

Hi HN, I have been building voice agents for sometime now. I was earlier automating parts of visa processing, and we needed real-time, multilingual voice calling.<p>I assumed the hard work was just wiring LiveKit/Pipecat + STT/TTS + an LLM. It wasn’t.<p>Even with solid OSS (Pipecat/LiveKit), we still had to do a lot of plumbing- variable extraction, tracing, testing etc and any workflow changes required constant redeploys.<p>We eventually realized we’d spent more time building infrastructure than building the actual agents. Everything felt custom. We hit every possible pain with Pipecat and VAPI style systems.<p>So we built Dograh - a fully open-source voice agent framework that includes all the boring, painful pieces by default.<p>What’s different:<p>- Pipecat-based engine, but forked - custom event model, and concurrency fixes<p>- One-click start template generated by an LLM Agent for a quick get start template for any use case<p>- Drag-and-drop visual agent builder for quick iteration (the thing we wished existed earlier)<p>- Variable extraction layer (name/order/date/etc.) baked into the LLM loop<p>- Built in Telephony integration (Twilio/ Vonage/ Vobiz/ Cloudonix)<p>- Multilingual support end-to-end<p>- Select any LLM TTS STT (add their credits, if any)<p>- AI-to-AI call testing: automatically stress-test an agent before shipping (still a work in progress- so patchy as of now)<p>- Fully Open Source<p>It's built and maintained by YC alumni / exit founders who got tired of rebuilding the same plumbing.<p>Why we open-sourced it: We kept feeling that the space was drifting toward closed SaaS abstractions (VAPI, Retell). Those are good for demos, but once you need data controls, privacy or self/offline deployment, you end up stuck. We wanted a stack where you can see every part, fork it, self-host it, and patch it as needed.<p>Try it:<p>- Repo: <a href="https://github.com/dograh-hq/dograh" rel="nofollow">https://github.com/dograh-hq/dograh</a><p>This spins up a basic multilingual agent with everything pre-wired.<p>Who this is for:<p>- If you are looking for self hosting a Vapi like platform for Data Privacy etc.<p>- Anyone trying to build production-grade voice agents without reinventing audio plumbing.<p>- If you’ve tried to glue STT→LLM→TTS manually, you probably know the exact pain this is built for<p>Happy to answer technical questions, show the architecture, or hear how we can improve the product.

Show HN: Open-source customizable AI voice dictation built on Pipecat

Tambourine is an open source, fully customizable voice dictation system that lets you control STT/ASR, LLM formatting, and prompts for inserting clean text into any app.<p>I have been building this on the side for a few weeks. What motivated it was wanting a customizable version of Wispr Flow where I could fully control the models, formatting, and behavior of the system, rather than relying on a black box.<p>Tambourine is built directly on top of Pipecat and relies on its modular voice agent framework. The back end is a local Python server that uses Pipecat to stitch together STT and LLM models into a single pipeline. This modularity is what makes it easy to swap providers, experiment with different setups, and maintain fine-grained control over the voice AI.<p>I shared an early version with friends and recently presented it at my local Claude Code meetup. The response was overwhelmingly positive, and I was encouraged to share it more widely.<p>The desktop app is built with Tauri. The front end is written in TypeScript, while the Tauri layer uses Rust to handle low level system integration. This enables the registration of global hotkeys, management of audio devices, and reliable text input at the cursor on both Windows and macOS.<p>At a high level, Tambourine gives you a universal voice interface across your OS. You press a global hotkey, speak, and formatted text is typed directly at your cursor. It works across emails, documents, chat apps, code editors, and terminals.<p>Under the hood, audio is streamed from the TypeScript front end to the Python server via WebRTC. The server runs real-time transcription with a configurable STT provider, then passes the transcript through an LLM that removes filler words, adds punctuation, and applies custom formatting rules and a personal dictionary. STT and LLM providers, as well as prompts, can be switched without restarting the app.<p>The project is still under active development. I am working through edge cases and refining the UX, and there will likely be breaking changes, but most core functionality already works well and has become part of my daily workflow.<p>I would really appreciate feedback, especially from anyone interested in the future of voice as an interface.

Show HN: I wrote a book – Debugging TypeScript Applications (in beta)

Show HN: 100 Million splats, a whole town, rendered in M2 MacBook Air

Written natively from scratch in Metal and Swift. Build for AirVis app.