| 1 | # Muse Code |
| 2 | |
| 3 | Muse Code is a beta integration and is disabled by default. Install |
| 4 | [Muse Code](https://dev.meta.ai/docs/muse-code) on the machine hosting your |
| 5 | environment, then run `muse login` as the account that runs T3 Code. |
| 6 | |
| 7 | Open **Settings → Providers** in the web or desktop app, select the environment, |
| 8 | and enable **Muse Code**. Set **Binary path** if Muse is not on the host's `PATH`. |
| 9 | Refresh provider status after installation or login, then select Muse in a |
| 10 | thread's model picker. |
| 11 | |
| 12 | Provider status does not check your login. If you are signed out, messages |
| 13 | fail until you run `muse login` on the host. |
| 14 | |
| 15 | ## Sign-in and API keys |
| 16 | |
| 17 | T3 Code ignores a `META_API_KEY` that the T3 server inherits from its own |
| 18 | environment, so Muse uses the credential saved on the host by `muse login`. To |
| 19 | use an API key instead, add `META_API_KEY` to the Muse instance's environment |
| 20 | variables in **Settings → Providers**. Muse gives that key priority over the |
| 21 | saved login. |
| 22 | |
| 23 | ## Remote access and instances |
| 24 | |
| 25 | Connect from web, desktop, or mobile through [remote access](./remote-access.md). |
| 26 | Muse uses the selected environment's files and login; connecting devices do not |
| 27 | need Muse installed. Install and sign in separately on each host where you want |
| 28 | Muse to run. |
| 29 | |
| 30 | Add a provider instance for a separate configuration. Instances on the same host |
| 31 | share its Muse login; give an instance its own `META_API_KEY` to bill it |
| 32 | separately. Existing conversations retain their instance when its model catalog |
| 33 | becomes unavailable. |
| 34 | |
| 35 | ## Models |
| 36 | |
| 37 | Models and reasoning choices come from Muse on the selected host. After changing |
| 38 | Muse configuration, refresh provider status in **Settings → Providers**. On |
| 39 | mobile, pull down in thread settings to refresh models. If a saved model becomes |
| 40 | unavailable, select an available model before sending another message. |
| 41 | |
| 42 | Muse can list models that your account cannot use. If a message fails with |
| 43 | "does not exist or you lack access", pick another model, or add one your account |
| 44 | can use under **Custom models** in the instance settings. |
| 45 | |
| 46 | ## Permissions and limitations |
| 47 | |
| 48 | Muse offers two [permission modes](./permission-modes.md): **Supervised** asks |
| 49 | before commands and edits, and **Full access** runs them without asking. Muse has |
| 50 | no equivalent of **Auto-accept edits** or **Auto**, so they are not offered. Muse |
| 51 | does not offer a separate Plan mode in T3 Code. |
| 52 | |
| 53 | Muse can use T3 Code's tools. If Muse cannot reach them, the turn continues |
| 54 | without them. Switching providers can pass conversation context as a handoff. |
| 55 | |
| 56 | Muse skills do not appear in the composer's `$` menu. Muse still loads them |
| 57 | itself. Manage them with `muse skills` on the host. |
| 58 | |
| 59 | Forking a Muse conversation starts a new session with a copy of the conversation |
| 60 | context. Conversation rewind is unavailable. |
| 61 | |
| 62 | Install Muse and sign in on the host; in-app installation and sign-in are not |
| 63 | available. Updates can run from **Settings → Providers** when T3 Code recognizes |
| 64 | the Muse launcher; otherwise update Muse on that host manually. |
| 65 | |
| 66 | To stop using Muse in an environment, disable it in **Settings → Providers**. |
| 67 | This keeps the host's Muse login, thread history, and workspace files. |