> ## Documentation Index
> Fetch the complete documentation index at: https://unmute.ai/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Unmute compiles to exactly three targets. Pipecat and LiveKit are code targets: compile writes a Python project you run. SLNG is a hosted target: compile writes a deployment body and SLNG runs the agent, so it has no `unmute dev`. Those three are the only values `provider` accepts in `targets.yaml`. Deepgram and ElevenLabs appear in these docs as model vendors, which is not the same thing as a target, and `slng` is both.
> The Go structs in `internal/spec` and `internal/ir` are the schema truth. Check a field against them, or run `unmute validate`, rather than against what you remember.

# The LiveKit project

> What unmute compile writes for a LiveKit target, and how to run it without Unmute.

This page describes the generated LiveKit project and its target settings.

<Card title="Deploy to LiveKit Cloud" icon="rocket" href="/deploy/livekit-cloud">
  Start here to create a deployment, choose its destination, supply credentials,
  and update its code or secrets.
</Card>

```sh theme={null}
unmute compile my-agent --target livekit
```

```text theme={null}
my-agent/build/livekit/
├── agent.py              # the agent worker
├── tools/                # your local handlers, copied
│   ├── __init__.py
│   └── <name>.py         # one per local tool
├── knowledge.py          # present when the package sets knowledge
├── knowledge/            # present when the package sets knowledge
│   └── <name>/           # one directory per knowledge source, its documents copied in
├── tracing.py            # present when the package sets tracing
├── dev_metrics.py        # per-turn latency for `unmute dev`, inert elsewhere
├── pyproject.toml        # pinned dependencies
├── Dockerfile
├── .dockerignore
├── compose.dev.yaml      # what `unmute dev` runs, including a local LiveKit server
├── .env.example          # exactly the variables you supply
├── README.md             # the runbook for this build
└── compile-report.json   # what the compiler decided
```

A target with an inbound SIP route writes three more files.
`sip-inbound-trunk.json` and `sip-dispatch-rule.json` are the records that
create the inbound trunk and the dispatch rule, which sends calls on your
number to this agent. `telephony-setup.sh` creates both. [Inbound
calls](/telephony/inbound-calls) covers them.

## Target fields

Write these inside `targets.<name>` in `targets.yaml`. The name is your target
instance name, used by `--target` and the `build/<name>/` output folder.

<ParamField path="provider" type="string" required>
  Use `livekit` for this target. Omission is refused.
</ParamField>

<ParamField path="version" type="string" required>
  An exact `x.y.z` framework version from the
  [supported window](/reference/targets-yaml#framework-versions-are-exact).
  Omission and unsupported versions are refused; there is no automatic upgrade.
</ParamField>

<ParamField path="sdk_language" type="string">
  Accepts `python`. If omitted, the generated project still uses Python.
</ParamField>

<ParamField path="connection" type="string">
  Required for telephony: the stem of a file under `connections/`, using
  `sip` or `connector` with a supported carrier.
  See [connection fields](/reference/connections-yaml#all-keys).
  Omit for a browser-only package; a connection without phone use is refused.
</ParamField>

<ParamField path="deployment_region" type="string or list of strings">
  Accepts `us-east`, `eu-central`, or `ap-south`, as one region or a list with
  no empty or duplicate entries. Unknown names are refused at validation. If omitted, no region is passed and platform placement
  applies. The region is chosen at first create and cannot be changed by a redeploy.
  See [deployment regions](/deploy/livekit-cloud#region-is-chosen-once).
</ParamField>

<ParamField path="models" type="map of model definitions">
  Overrides keyed by existing model names from `agent.yaml`, using the
  [model fields](/reference/agent-yaml#models). Omit to use the package's models.
  An override replaces the entry, except that omitted `pace`, `endpointing_delay`,
  `semantic_endpointing`, and `prompt_suffix` carry forward. An override cannot
  author `pace` or a different `prompt_suffix`.
</ParamField>

<ParamField path="pins" type="map of strings">
  Known LiveKit package names mapped to semantic versions. Unknown names and versions below the catalog floor are refused. Omit to use the catalog pins.
</ParamField>

<ParamField path="warm_instances" type="integer">
  Positive values are refused on LiveKit. Omit this Pipecat setting; Unmute configures no LiveKit warm-instance count. Zero also emits no setting.
</ParamField>

## agent.py

One worker file: your prompts, the agent classes, the tasks and task groups if
you declared any, the tool functions, and the session wiring. The entry agent
becomes a class, named after your agent, and the generated README says which
one it is.

It imports LiveKit and your handlers. Nothing from Unmute.

## Run it without Unmute

```sh theme={null}
cd my-agent/build/livekit
uv sync                       # or: pip install -e .
cp .env.example .env          # then fill in the required values
uv run python -m livekit.agents start agent.py    # the worker
```

`start` needs a running LiveKit server and its `LIVEKIT_URL`,
`LIVEKIT_API_KEY`, and `LIVEKIT_API_SECRET` in the environment. Add `--log-format colored`
for readable logs while developing, which is what the generated development
Compose file does.

## Dependencies are pinned

The generated `pyproject.toml` follows your target's framework version, selected
providers, and tracing settings. Use the [target fields](#target-fields) to
change supported pins, then compile again.

## Deploy

Follow [Deploy to LiveKit Cloud](/deploy/livekit-cloud) for the complete sequence:
package preparation, destination selection, runtime values, first deployment,
updates, and a test interaction. The guide also covers secrets-only changes.

Use the generated `build/livekit/` directory as the build context. Keep secret
values out of the image. Supply the runtime values listed by its `.env.example`
and runbook through the platform's secret store.

### The worker's agent name

The worker registers under the package's
[`name:`](/reference/agent-yaml#name) joined to the target it was compiled for,
so `name: acme-support` on a target called `livekit` registers
`acme-support-livekit`. A SIP dispatch rule matches a worker by that string, and
the emitted `sip-dispatch-rule.json` and `telephony-setup.sh` both name the same
one.

Renaming the package changes the worker name. Follow the
[rename steps](/deploy/livekit-cloud#renaming-the-agent-breaks-that-rule) to
update the SIP dispatch rule too.

<Warning>
  Do not edit files in `build/`. Change the source package and compile again.
</Warning>

## Where to go next

<Columns cols={2}>
  <Card title="The SLNG deployment body" icon="cloud" href="/targets/slng">
    The third target: a hosted deployment body instead of a project.
  </Card>

  <Card title="Going live" icon="rocket" href="/deploy/going-live">
    What to do with the project you were handed.
  </Card>
</Columns>