See attached.

@Dan Quixote glad it helped. On the caching, what's the refresh logic there? Do you do an uncached check if a booking attempt fails? Fair enough if so. Without caching it's an edge case where two people call at the same time and request the same slot (usually the next available) and one secures it first.

@Dan Quixote you're welcome. And thank you too since you gave me a nice idea for a local caching service/proxy I can use for something else I'm building 🫡

@Dan Quixote appreciate the kind words. What's wild is that since I've open-sourced this a lot more developers have called it to test out its capabilities, and through that I learned of a couple of things the model can do I didn't know about: 1. It can whisper 2. It can rap "like Kevin Gates" 😂

@Dan Quixote I had to Google him too! Just listened to the recording. Oasis was my favourite band growing up :)

Give this one a go if you want to try Gemini Live tuned for being a snappy demo: https://askjohngeorge.com/demo Built with Pipecat and hosted on Pipecat Cloud.

@Nour aka Sanava thank you 🙏 Fully vibe coded it chatting to Claude Code over the xmas holidays 😁

What's your autoscaling plan for the workers?

I'm more referring to the process management side of the speech-to-speech pipeline. Even without local GPU inference, every active call requires a persistent Python worker to bridge the WebRTC stream to OpenAI's WebSocket. If you just use standard EC2 autoscaling, how are you handling scale-in events? When AWS spins down an instance to save costs, it will kill the process, which means dropping active calls mid-sentence. You'd need custom lifecycle hooks to implement connection draining so the server waits for the call to finish before terminating. LiveKit Cloud (or a custom K8s operator) handles that stateful orchestration. Raw EC2 autoscaling groups don't afaik.