Sharing a project I help maintain — Flowcat, an Apache-2.0 native-Rust runtime for real-time voice AI agents (phone + WebRTC). It runs the whole voice pipeline (STT → LLM → TTS, or a single speech-to-speech model) as one self-contained binary you host yourself — in your own VPC or fully air-gapped. No hosted control plane, bring your own keys, and a call’s audio never leaves your infra.
It’s a clean-room counterpart to pipecat’s architecture, but native Rust:
- each pipeline stage is its own tokio task behind a bounded mpsc channel (natural backpressure)
- the hot audio frame is an
Arc<AudioFrame>, so each hop moves a pointer, not a PCM copy - no GIL, so one process uses all cores and holds a flat tail under load (measured: flat ~0.6ms p99 framework overhead from 10 to 2,000 concurrent calls on one box)
- native SIP/RTP, so a single binary can terminate phone calls with no FreeSWITCH
The linked writeup has the full Rust design + a reproducible benchmark vs pipecat (with the honest caveat that it’s framework overhead, not end-to-end voice latency — that’s provider-bound).
Repo: https://github.com/AreevAI/flowcat
Apache-2.0, pre-1.0, built in the open. Disclosure: I help maintain it — happy to talk architecture or the SIP stack.
runtime for real-time voice AI agents (phone + WebRTC)
Oh boy, my favorite…
It’s a clean-room counterpart to pipecat’s architecture, but native Rust
If by “clean-room” you mean “I had an AI extract the API and another reimplement it” solely with the intent of changing the license (which was already BSD-2 anyway), then you give credibility to the “they rewrote in Rust to change the license” crowd, which might actually bother me more than anything else. Plus, there’s no guarantee that the LLM didn’t know anything of the original implementation (which is a public GitHub repo… no chance in hell the LLM wasn’t trained on it), and I find it unlikely that you didn’t reference Pipecat if you did this by hand (something tells me that’s not the case).
not end-to-end voice latency — that’s provider-bound
Genuine question, though somewhat off-topic: I have a method of doing this on my phone keyboard and, via a certain key combination, my desktop, but I’m curious about your method. What method do you use to type an emdash?
@suriyan Are you a bot, or rely on automation to submit comments or posts?
If so, please honor Automation guidelines, including disclosure. https://legal.programming.dev/docs/automation-guidelines/
So that’s how spam bots are making tons of calls to sell their scams and harrass people.
I receive multiple calls everyday for the same scam despite being on a no-marketing list. The same AI agents are cycling through numbers to make themselves hard to block. Virturtally everyone I talk to got these calls, and increasingly avoid answering the phone.
It makes having a phone more annoying, less useful. Just like spam ruined emails.
That’s a fair concern and I won’t pretend it away. Robocall spam predates AI by decades — predictive dialers and prerecorded scams already made billions of calls a year — but AI absolutely makes it cheaper and more convincing, and I get calls like that too.
Two honest observations from working in this space: the scam operations don’t need open-source projects — they already run on cheap hosted APIs and have for years. And the actual fix lives at the carrier layer, not the software layer: STIR/SHAKEN attestation, enforcement against the VoIP providers who knowingly sell to spammers, and liability for carriers that terminate that traffic. Software bans won’t stop them; making unverified caller ID worthless will.
What a self-hosted runtime does change is who legitimate users have to trust — a clinic or a bank running voice agents on-prem instead of streaming call audio to a third party. That’s the use case I care about. But yeah, the spam problem is real, and it’s going to get worse before regulation catches up.
Hi @suriyan
A lot of your messages appear to be LLM written. Are you an automated bot?
Please familiarise yourself with the p.d automation guidelines:
https://legal.programming.dev/docs/automation-guidelines/
Please reach out to us as soon as possible, or we will be forced to assume you are a bot.
Scammers may not use this specific project yet, but do use tools like This with LLM integration. They absolutely will use an OSS tool if it’s good enough and cheap enough.
STIR/SHAKEN would help, but it would remain a game of cat and mouse. SPF/DKIM/… is widely deployed and enrorfced and yet spam email continue. There’s financial insentives to keep spamming one way or another.
LLMs enable spam call at a much larger scale with few to no human involved. They won’t quit nor blow the whistle on their shitty boss. LLMs are the least useful, most harmful kind of AI. It should be abandonned and/or regulated to death.
High chance you’re talking to an AI, by the way. Starts with an affirmation, has lots of em-dashes…
For fuck’s sake. If that’s an undisclosed bot then it should be banned.
deleted by creator
Ew. Get your slop adverts out of here.
Putting vibe negativity aside, I checked what the local STT and TTS “support” looked like.
STT is based on rust bindings for
whisper.cpp(2024 called!). And the three local TTS models claim is total bullshit. One is using an external service from a docker image, and the other two are trivial web clients that are not even wired. I also loved the circular reasoning at the start of the three TTS modules. Even an LLM is not something I would have pegged as that bad at logic. But maybe they got that way because of the prompter.So ZERO interesting shit is happening here, vibed or otherwise. Nothing even close to using rust-based ML engines (candle, burn, tract), not even in a completely broken untested way.