Skip to main content
Match the binding, core SDK and model file format before upgrading. Binding versions are independent of the core SDK version. For example, Python 3.4.0 embeds core SDK 0.26.0. A model’s product version is also separate from its file format version.

​
Versions used by the quickstarts

Use each language guide for runtime and platform prerequisites. Test audio processing on your deployment target and lock transitive dependencies. The ai-coustics LiveKit extras plugin and LiveKit’s official plugin are different packages with different capabilities and authentication. See plugin scope. The Pipecat quickstart uses the highest compatible Python SDK release published by Pipecat 1.15.0: 3.3.2, which embeds core SDK 0.25.2. Keep the LiveKit and Pipecat dependency sets separate. The LiveKit extras plugin pins the SDK binding exactly, and its version matches the core SDK version.

​
Release history

The tables below preserve historical release mappings. They do not extend an old dependency pin to every later framework release. Before core SDK 0.13.0, models were embedded in the SDK and had no separate file format version.
This table applies to ai-coustics’ ai-coustics-livekit-extras and @ai-coustics/livekit-extras packages.This table applies to ai-coustics’ deprecated ai-coustics-livekit-plugin and @ai-coustics/livekit-plugin packages.This table applies to LiveKit’s livekit-plugins-ai-coustics and @livekit/plugins-ai-coustics packages.

​
Upgrade without mixing artifacts

Keep the old application lockfile, SDK binary and model files together until the candidate passes your audio and operational checks. If the new core requires a different model file format, download compatible models into a separate cache location. See SDK and model versions for how these versions fit together. Repeat your checks when the package, model hash, runtime, operating system, CPU architecture or dependency lockfile changes.