# SDKs Overview

> Select a language. All six SDKs give the same five-modality surface.

All six SDKs are thin wrappers over the same C++ core. Every language exposes
the **five modalities** as sub-imports (or sub-namespaces / sub-packages):
voice, streams, robotics, games, and data. Method names align across languages
in the idiomatic case of each language. When you know one SDK, the other SDKs
are familiar.

  - **[TypeScript](/sdks/typescript/quickstart)** — `npm i clutchcall_connect`
  - **[Python](/sdks/python/quickstart)** — `pip install clutchcall-sdk`
  - **[Go](/sdks/go/quickstart)** — `go get github.com/clutchcall/clutchcall-sdk/go`
  - **[Rust](/sdks/rust/quickstart)** — `clutchcall = "0.1"`
  - **[Java](/sdks/java/quickstart)** — `com.clutchcall:clutchcall-sdk`
  - **[.NET / C#](/sdks/dotnet/quickstart)** — `dotnet add package ClutchCall.SDK`

A **Unity UPM** transport is also available for Netcode for GameObjects /
Entities. See [Netcode (Unity)](/modalities/netcode/details).

## The five modalities

Each SDK exposes the same five modalities as separate sub-imports:

| Modality       | TypeScript                       | Python                       | Go                       | Rust                    | Java                                 | .NET                  |
| -------------- | -------------------------------- | ---------------------------- | ------------------------ | ----------------------- | ------------------------------------ | --------------------- |
| **Voice**      | `clutchcall_connect/voice`           | `clutchcall.voice`           | `github.com/clutchcall/clutchcall-sdk/go/pkg/voice`   | `clutchcall::voice`     | `com.clutchcall.sdk.voice`           | `ClutchCall.SDK.Voice` |
| **Streams**    | `clutchcall_connect/streams`         | `clutchcall.streams`         | `github.com/clutchcall/clutchcall-sdk/go/pkg/streams` | `clutchcall::streams`   | `com.clutchcall.sdk.streams`         | `ClutchCall.SDK.Streams` |
| **Robotics**   | `clutchcall_connect/robotics`        | `clutchcall.robotics`        | `github.com/clutchcall/clutchcall-sdk/go/pkg/robotics` | `clutchcall::robotics` | `com.clutchcall.sdk.robotics`        | `ClutchCall.SDK.Robotics` |
| **Games**      | `clutchcall_connect/games`           | `clutchcall.games`           | `github.com/clutchcall/clutchcall-sdk/go/pkg/games`   | `clutchcall::games`     | `com.clutchcall.sdk.games`           | `ClutchCall.SDK.Games` |
| **Data**      | `clutchcall_connect/data`            | `clutchcall.data`            | `github.com/clutchcall/clutchcall-sdk/go/pkg/data`    | `clutchcall::data`      | `com.clutchcall.sdk.data`            | `ClutchCall.SDK.Data` |
| **MoQT (raw)** | `clutchcall_connect/moqt`            | `clutchcall.moqt`            | `github.com/clutchcall/clutchcall-sdk/go/pkg/moqt`    | `clutchcall::moqt`      | `com.clutchcall.sdk.Moqt`            | `ClutchCall.SDK.Moqt` |

You can mix the modalities in one app. They share the same QUIC connection,
auth, and relay. The substrate (raw MoQT) is always available. See
[Realtime Tracks](/concepts/realtime-tracks).

## Common shape

Every modality client follows the same shape:

| Concept               | Pattern                                                |
| --------------------- | ------------------------------------------------------ |
| Construct             | `new <Modality>({ relayHost / baseUrl, token, ... })`  |
| Publish               | `.publish<Kind>({ topic / namespace, ... })` returns a publication handle |
| Subscribe             | `.subscribe<Kind>({ topicFilter / namespace }, callback)` |
| Control plane (HTTP)  | tRPC procedure calls (`.calls.originate`, `.liveInputs.create`, ...) |
| Close                 | `.close()` — stops the underlying connection      |

The publication and subscription handles wrap the underlying MoQT track.
The handles reconnect automatically and replay subscribes on reconnect.
The handles show backpressure if the relay falls behind.

## Realtime tracks (the substrate)

Sometimes the five modalities do not fit your use case. Examples: a custom
protocol, a research experiment, or a transport that another codebase already
uses. In these cases, import the `MoqtClient` directly. See
[Realtime Tracks](/concepts/realtime-tracks). You get the same auto-reconnect,
capability routing, and relay fan-out, without the modality-specific
conventions.

## Choosing a language

| If you're …                                                  | Pick this        |
| ------------------------------------------------------------ | ---------------- |
| Building a browser dashboard, broadcast viewer, game client  | **TypeScript**   |
| Writing an LLM voice agent, robot fleet publisher, IoT pub/sub | **Python**     |
| Running a high-throughput batch service alongside K8s infra  | **Go**           |
| Embedding into an edge service or hot path                   | **Rust**         |
| Plugging into a JVM monolith / Spring stack                  | **Java**         |
| Integrating with Windows tooling or Unity .NET runtime       | **.NET / C#**    |
| Shipping a Unity game (Netcode for GameObjects / Entities)   | **Unity UPM** (`com.clutchcall.transport`) |

You can mix languages. By design, a Python publisher and a browser subscriber
can share the same MoQT track.