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

Show HN (score: 9)
Found: December 14, 2025
ID: 2672

Description

Other
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.

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.

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.

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.

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.

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.

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.

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.

I would really appreciate feedback, especially from anyone interested in the future of voice as an interface.

More from Show

Show HN: I made R/place for LLMs

Show HN: I made R/place for LLMs I built AI Place, a vLLM-controlled pixel canvas inspired by r&#x2F;place. Instead of users placing pixels, an LLM paints the grid continuously and you can watch it evolve live.<p>The theme rotates daily. Currently, the canvas is scored using CLIP ViT-B&#x2F;32 against a prompt (e.g., Pixelart of ${theme}). The highest-scoring snapshot is saved to the archive at the end of each day.<p>The agents work in a simple loop:<p>Input: Theme + image of current canvas<p>Output: Python code to update specific pixel coordinates + One word description<p>Tech: Next.js, SSE realtime updates, NVIDIA NIM (Mistral Large 3&#x2F;GPT-OSS&#x2F;Llama 4 Maverick) for the painting decisions<p>Would love feedback! (or ideas for prompts&#x2F;behaviors to try)

Show HN: Hurry – Fast Rust build caching

Show HN: Hurry – Fast Rust build caching Hey HN, we’re Eliza and Xin. We’re working on Hurry, an open source drop-in tool that adds distributed build caching to Cargo with (almost) zero configuration. Wherever you run cargo build, you can run hurry cargo build instead, and expect around 2-5x (our best benchmark is 22x) faster builds.<p>We built this because we were dissatisfied with the current build caching options available for Rust. Buck and Bazel require learning a new tool. GitHub Actions and swatinem are too coarse-grained (either the whole cache hits, or none of it does) and finicky to debug, and cargo-chef and Docker layer caching have the same problems.<p>We wanted something that could restore cache at the package level, did not require integration-specific setup, and worked everywhere.<p>Hurry is fully open source under Apache 2. You can try it out now with our cloud hosted caching service at <a href="https:&#x2F;&#x2F;hurry.build" rel="nofollow">https:&#x2F;&#x2F;hurry.build</a> or self-host your own build cache service from <a href="https:&#x2F;&#x2F;github.com&#x2F;attunehq&#x2F;hurry" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;attunehq&#x2F;hurry</a>. Sorry in advance for the rough edges - we have some customers already exercising the hot paths, but build tools are pretty large surfaces. We’ve got a list of known limitations at <a href="https:&#x2F;&#x2F;github.com&#x2F;attunehq&#x2F;hurry?tab=readme-ov-file#known-limitations" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;attunehq&#x2F;hurry?tab=readme-ov-file#known-l...</a>.<p>We’d love for folks here to try it out (maybe on your next Rust winter side project?) and let us know what you think. We’ll be in the comments here, or you can email us at founders@attunehq.com.<p>Our goal is to make all parts of software engineering faster. If you have some part of your coding workflow that you want faster, please feel free to reach out. We’d love to chat.

Show HN: RenderCV – Open-source CV/resume generator, YAML → PDF

Show HN: RenderCV – Open-source CV/resume generator, YAML → PDF I built RenderCV because Word kept breaking my layout and LaTeX was overkill. I wanted my CV as a single YAML file (content, design, margins, everything) that I could render with one command.<p>Run <i>rendercv render cv.yaml</i> → get a perfectly typeset PDF.<p>Highlights:<p>1. <i>Version-controllable:</i> Your CV is just text. Diff it, tag it.<p>2. <i>LLM-friendly:</i> Paste into ChatGPT, tailor to a job description, paste back, render. Batch-produce variants with terminal AI agents.<p>3. <i>Perfect typography:</i> Typst under the hood handles pixel-perfect alignment and spacing.<p>4. <i>Full design control:</i> Margins, fonts, colors, and more; tweak everything in YAML.<p>5. <i>Comes with JSON Schema:</i> Autocompletion and inline docs in your editor.<p>Battle-tested for 2+ years, thousands of users, 120k+ total PyPI downloads, 100% test coverage, actively maintained.<p>GitHub: <a href="https:&#x2F;&#x2F;github.com&#x2F;rendercv&#x2F;rendercv" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rendercv&#x2F;rendercv</a><p>Docs: <a href="https:&#x2F;&#x2F;docs.rendercv.com" rel="nofollow">https:&#x2F;&#x2F;docs.rendercv.com</a><p>Overview on RenderCV&#x27;s software design (Pydantic + Jinja2 + Typst): <a href="https:&#x2F;&#x2F;docs.rendercv.com&#x2F;developer_guide&#x2F;understanding_rendercv&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.rendercv.com&#x2F;developer_guide&#x2F;understanding_rend...</a><p>I also wrote up the internals as an educational resource on maintaining Python projects (GitHub Actions, packaging, Docker, JSON Schema, deploying docs, etc.): <a href="https:&#x2F;&#x2F;docs.rendercv.com&#x2F;developer_guide&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.rendercv.com&#x2F;developer_guide&#x2F;</a>

Show HN: A community-curated list of BYOC (Bring Your Own Cloud) vendors

Show HN: A community-curated list of BYOC (Bring Your Own Cloud) vendors Hi HN,<p>I’m from the team at Nuon. While building in the Bring Your Own Cloud (BYOC) space, we realized there wasn&#x27;t a centralized, community-driven resource like awesome-selfhosted.net for managed software that lives in the customer&#x27;s VPC.<p>We hope software vendors will open a PR and add their BYOC offerings.

No other tools from this source yet.