8a4ab611be
Does not (yet) touch `InputParams`, to avoid scope creep and touching something currently part of the public API. But there is a lot of overlap between `*Settings` object fields and `InputParams` fields. Other than discoverability/typing, these are some other improvements brought by this refactor: - There is now a single code path (see `_update_settings_from_typed`) where services can respond to settings changes (by, say, reconnecting if needed), improving maintainability and guaranteeing one and only one reconnection no matter which settings changed - `set_language`/`set_model`/`set_voice`—which we're assuming are usable as public methods, though *not* recommended over `*UpdateSettingsFrame`—all use the same code path as settings updates. They're also now all consistent in that, if a service needs to respond to a change (by, say, reconnecting if needed), any of these methods will kick off that process. Note that this is technically a behavior change. - Several services now properly react to changed settings by reconnecting: - `AWSTranscribeSTTService` - `AzureSTTService` - `SonioxSTTService` - `GladiaSTTService` - `SpeechmaticsSTTService` - `AssemblyAISTTService` - `CartesiaSTTService` - `FishAudioTTSService` (would previously only reconnect when `model` changed) - `GoogleSTTService` - `SpeechmaticsSTTService` (which previously only handled *some* settings updates through a nonstandard public `update_params` method) - `GradiumSTTService` - `NvidiaSegmentedSTTService` (which previously only handled changes to language) - Bookkeeping across various services has been reduced, mostly by deduping ivars; the `self._settings` ivar is treated as the source of truth NOTE: I pretty much guarantee that there are services missed in this PR in terms of bringing to consistency with how updates are handled (like whether changes in certain fields trigger reconnects when they need to). We can squash remaining inconsistencies as we stumble onto them, service by service. The goal here is to get things *mostly* in order, and establish the infrastructure and patterns we'll need going forward.
🎙️ Pipecat: Real-Time Voice & Multimodal AI Agents
Pipecat is an open-source Python framework for building real-time voice and multimodal conversational agents. Orchestrate audio and video, AI services, different transports, and conversation pipelines effortlessly—so you can focus on what makes your agent unique.
Want to dive right in? Try the quickstart.
🚀 What You Can Build
- Voice Assistants – natural, streaming conversations with AI
- AI Companions – coaches, meeting assistants, characters
- Multimodal Interfaces – voice, video, images, and more
- Interactive Storytelling – creative tools with generative media
- Business Agents – customer intake, support bots, guided flows
- Complex Dialog Systems – design logic with structured conversations
🧠 Why Pipecat?
- Voice-first: Integrates speech recognition, text-to-speech, and conversation handling
- Pluggable: Supports many AI services and tools
- Composable Pipelines: Build complex behavior from modular components
- Real-Time: Ultra-low latency interaction with different transports (e.g. WebSockets or WebRTC)
🌐 Pipecat Ecosystem
📱 Client SDKs
Building client applications? You can connect to Pipecat from any platform using our official SDKs:
JavaScript | React | React Native | Swift | Kotlin | C++ | ESP32
🧭 Structured conversations
Looking to build structured conversations? Check out Pipecat Flows for managing complex conversational states and transitions.
🪄 Beautiful UIs
Want to build beautiful and engaging experiences? Checkout the Voice UI Kit, a collection of components, hooks and templates for building voice AI applications quickly.
🛠️ Create and deploy projects
Create a new project in under a minute with the Pipecat CLI. Then use the CLI to monitor and deploy your agent to production.
🔍 Debugging
Looking for help debugging your pipeline and processors? Check out Whisker, a real-time Pipecat debugger.
🖥️ Terminal
Love terminal applications? Check out Tail, a terminal dashboard for Pipecat.
📺️ Pipecat TV Channel
Catch new features, interviews, and how-tos on our Pipecat TV channel.
🎬 See it in action
🧩 Available services
📚 View full services documentation →
⚡ Getting started
You can get started with Pipecat running on your local machine, then move your agent processes to the cloud when you're ready.
-
Install uv
curl -LsSf https://astral.sh/uv/install.sh | shNeed help? Refer to the uv install documentation.
-
Install the module
# For new projects uv init my-pipecat-app cd my-pipecat-app uv add pipecat-ai # Or for existing projects uv add pipecat-ai -
Set up your environment
cp env.example .env -
To keep things lightweight, only the core framework is included by default. If you need support for third-party AI services, you can add the necessary dependencies with:
uv add "pipecat-ai[option,...]"
Using pip? You can still use
pip install pipecat-aiandpip install "pipecat-ai[option,...]"to get set up.
🧪 Code examples
- Foundational — small snippets that build on each other, introducing one or two concepts at a time
- Example apps — complete applications that you can use as starting points for development
🛠️ Contributing to the framework
Prerequisites
Minimum Python Version: 3.10 Recommended Python Version: 3.12
Setup Steps
-
Clone the repository and navigate to it:
git clone https://github.com/pipecat-ai/pipecat.git cd pipecat -
Install development and testing dependencies:
uv sync --group dev --all-extras \ --no-extra gstreamer \ --no-extra krisp \ --no-extra local \ -
Install the git pre-commit hooks:
uv run pre-commit install
Note
: Some extras (local, gstreamer) require system dependencies. See documentation if you encounter build errors.
Running tests
To run all tests, from the root directory:
uv run pytest
Run a specific test suite:
uv run pytest tests/test_name.py
🤝 Contributing
We welcome contributions from the community! Whether you're fixing bugs, improving documentation, or adding new features, here's how you can help:
- Found a bug? Open an issue
- Have a feature idea? Start a discussion
- Want to contribute code? Check our CONTRIBUTING.md guide
- Documentation improvements? Docs PRs are always welcome
Before submitting a pull request, please check existing issues and PRs to avoid duplicates.
We aim to review all contributions promptly and provide constructive feedback to help get your changes merged.