Running in Operaide Studio

Open the integrated terminal in your Studio workspace and run operaide-code. The workspace is already wired up: the binary is on PATH, and .operaide-code/config.toml points at Studio's LLM proxy with your workspace's Personal Access Key.

Prerequisites

• A Studio workspace created from the Studio UI.
• At least one active AIProvider in your organization. See AI Provider for the admin side.
• Studio set up with an OpenAI-compatible LLM gateway (LiteLLM or any provider with providerRegistryId: "openai").

What gets bootstrapped

When the workspace is created, Studio runs a setup script that does three things:

1. Calls GET /api/v1/llm/providers with your workspace Personal Access Key, getting back the active AIProviders and the chat models each one exposes.
2. Generates .operaide-code/config.toml in the workspace root with one [providers.<readableId>] block per AIProvider.
3. Picks a default model: mistral/mistral-medium-latest if available, else devAzure/4o-mini, else the first model of the alphabetically-first provider.

The generated file looks like this:

# Auto-generated by Operaide Studio.
# Re-run via the "Operaide Code: Refresh Config" task to update.

default_provider = "mistral"
default_model    = "mistral-medium-latest"

[providers.mistral]
type     = "openai"
api_key  = "operaide_pak_workspace"
base_url = "https://studio.example.com/api/v1/llm/mistral/v1"
models   = ["mistral-medium-latest", "mistral-large-latest"]

[providers.devAzure]
type     = "openai"
api_key  = "operaide_pak_workspace"
base_url = "https://studio.example.com/api/v1/llm/devAzure/v1"
models   = ["4o-mini"]

Two things matter for security and trust:

• Every block uses type = "openai" because every call routes through Studio's OpenAI-compatible proxy.
• Every api_key is your workspace Personal Access Key, not a real provider key. Real Anthropic, OpenAI, Mistral, and LiteLLM master keys never leave the platform server. Each call is authenticated against your PAK, permission-checked with permToUseAIProvider, and forwarded to the upstream provider on your behalf.

The file has mode 0600 so other workspace users cannot read it. The workspace .gitignore excludes .operaide-code/, so the PAK does not land in commits.

What the model picker shows

Open the picker with /model. It lists exactly the providers in your .operaide-code/config.toml, which mirrors the active AIProviders in your org. If your org has LiteLLM, an Ollama gateway, an Azure deployment, and a Mistral key registered, all four appear. No synthetic Anthropic or Ollama defaults sneak in.

Inside the picker:

1. Pick the provider.
2. Pick the model from that provider's models list.
3. Optionally, type a custom model id if you know the provider supports it.

The status line shows the active provider and model.

Switching the default

The picker change applies to the current session only. To make a different provider or model the default for new sessions, edit .operaide-code/config.toml and change default_provider and default_model. The next session reads the new values.

When to edit the config by hand

Edit .operaide-code/config.toml directly when you want to:

• Pin a different default model.
• Add a non-Studio provider block (for example, a direct Mistral key for offline experiments).
• Set the UI theme without using the picker ([ui] theme = "dark").

You do not need to edit it to add new platform AIProviders. Run the refresh task instead (next section).

Refreshing the config

Run the Operaide Code: Refresh Config task to re-fetch the AIProvider list and rewrite .operaide-code/config.toml. Open the task from View > Command Palette > Run Task > Operaide Code: Refresh Config.

Use it when:

• New providers added. Your admin registered an AIProvider after the workspace was created.
• File deleted. You removed .operaide-code/config.toml and want it back.
• Initial fetch failed. The auto-bootstrap could not reach the platform.

The task reuses the workspace Personal Access Key. It looks for the key in this order:

1. ~/.config/operaide-code/keys/<workspace-name>.key, persisted at workspace setup.
2. The existing .operaide-code/config.toml, parsed from any api_key line.
3. The OPERAIDE_WORKSPACE_API_KEY env var, set only during initial bootstrap.

If none of these is present, the task exits with an error. Recreate the workspace from Studio to mint a fresh key.

The refresh keeps the same PAK. To rotate the key, recreate the workspace.

Local Studio dev

If you run Studio natively (cd shared && make), the _dev_dependencies target builds the operaide-code binary at operaide-code/bin/operaide-code for you. To make the workspace terminal find it, symlink it onto PATH once:

ln -s "$(pwd)/operaide-code/bin/operaide-code" /usr/local/bin/operaide-code
# or, user-local:
mkdir -p ~/.local/bin && ln -s "$(pwd)/operaide-code/bin/operaide-code" ~/.local/bin/operaide-code

In a Studio container deployment the symlink is unnecessary. The container build copies the binary into /usr/local/bin/operaide-code automatically.

Common mistakes

• Editing .operaide-code/config.toml and adding new platform providers there. The workspace TOML is a snapshot of platform AIProviders at workspace creation time. New AIProviders added later in the admin UI do not appear in old workspaces until you regenerate the file. Run the Operaide Code: Refresh Config task to refresh.
• Using a real provider key in a workspace. The proxy is the authentication boundary. If you put a real Anthropic key into [providers.anthropic] api_key, it sits in a workspace file alongside team members' code. Use the workspace PAK and the Studio proxy.
• Expecting default_model changes to take effect mid-session. They do not. Either use /model for the current session, or restart operaide-code.