Skip to main content
Credentials control which coding agents and integrations are available to your workspaces.

​
Coding Agents

Configure coding agents in Organization → Coding Agents. Every model Replicas supports for Claude, Codex, and Cursor is available in workspace, automation, and default-setting pickers, including models added later; expand Models under a harness to hide individual models for the whole organization, leaving at least one visible. Organization admins can also add further Cursor model IDs when an organization Cursor API key is connected. OpenRouter models under Opencode or Pi remain a fully configurable selection. Models under Inference providers → OpenCode Go lets organization admins add or remove models from the four-model default selection, shared by both harnesses. Organization admins can also choose which coding agents can handle delegated tasks. Each selected agent must have credentials available in the workspace. At least one coding agent must be configured before creating workspaces. See the Claude Code, Codex, Cursor, Muse Code, Opencode, and Pi guides for agent-specific setup and usage.

​
Anthropic API Key Alternative

Create an Anthropic API key (starts with sk-ant-) if you do not want to connect Claude OAuth.

​
Ollama

Open Inference providers → Ollama at the bottom of organization or personal Coding Agents settings. Add your Ollama API key and base URL (defaults to https://ollama.com). The credential is shared across these harnesses within the same scope. For your own Ollama server, use an HTTPS endpoint reachable from the workspace; localhost on your computer is not reachable from a cloud workspace. Enter ollama as the key if your server does not require authentication. Under Ollama → Models, choose suggested models or add model IDs, then save. Use Use all models to show the full endpoint catalog. The selection applies to that personal or organization connection. Before creating a workspace, choose Inference below the home page prompt, then choose one of that provider’s models in the model picker. The inference selector appears only when an alternative to native inference is connected for the selected agent. Choose a model per chat; coding agents need tool support and at least 64k context. Replicas reads capabilities and context from /api/show and defaults to gpt-oss:20b when that metadata confirms compatibility; otherwise choose a model explicitly. For custom servers, configure sufficient context in Ollama itself. Pi requires model details with context and tool support. Access to listed cloud models depends on your Ollama plan. In Claude Code and Codex workspaces, open the composer’s model menu and choose Inference provider → Ollama. Switch back to Native to restore your previous model. This applies to every chat using that agent in the workspace; stop running chats and clear their queues before switching. Connecting Ollama alone keeps native credentials preferred, including organization credentials when your Ollama key is personal. The provider chosen during creation is retained when the workspace wakes. Use the fallback chain to configure defaults for other workspaces. Claude Code uses Ollama’s Anthropic-compatible endpoint; Codex uses Responses, and the other harnesses use Chat Completions. Provider compatibility limits still apply: Codex web search is disabled with Ollama, and hosted Claude WebSearch and advanced tool controls are not fully supported.

​
OpenAI API Key Alternative

Create an OpenAI API key if you do not want to connect OpenAI OAuth for Codex.

​
OpenAI-Compatible Alternative

Configure a Responses API-compatible endpoint with an API key or exact Authorization header. This is separate from direct OpenAI API key authentication.

​
OpenRouter API Key

Use one OpenRouter API key (starts with sk-or-) for Opencode and Pi. The shared credential appears under each agent’s OpenRouter API Key method. Create one from the OpenRouter keys page.

​
OpenCode Go

Open Inference providers → OpenCode Go under Coding Agents and paste an API key from OpenCode Zen. Configure it at the organization level for shared access or at the personal level for one user.

​
Aster API Key

Use one Aster API key (starts with sk_aster_) for Opencode and Pi. Create one in the Aster console and paste it under either agent. Within a scope, Opencode and Pi prefer OpenCode Go, then Aster, then OpenRouter.

​
Opencode

Use Opencode with an OpenCode Go, Aster, or OpenRouter API key. See the Opencode agent guide for setup details, models, and usage.

​
Pi

Use Pi when you want its SDK-backed tool and skill harness with OpenCode Go, Aster, or OpenRouter models. See the Pi agent guide for setup details and usage.

​
Cursor API Key

Use a Cursor API key to run Cursor agents. Cursor proxies many models (Composer, Claude, GPT, Gemini, Grok, and more); admins pick which appear in the picker. When an organization Cursor API key is connected, Replicas loads that key’s available model catalog for the picker. See the Cursor agent guide for setup details and usage.

​
Microsoft Foundry Alternative

Use Microsoft Foundry to run Claude Code or Codex against Azure-hosted deployments:
  • Claude Code requires a Foundry API key and resource name, plus optional Sonnet, Haiku, and Opus deployment names.
  • Codex requires an Azure OpenAI API key, a base URL (for example https://your-resource.openai.azure.com/openai/v1), and a model deployment name.

​
Bedrock Alternative

If you prefer AWS Bedrock for Claude, provide your AWS credentials instead of Claude OAuth. Bedrock credentials require:

​
Scopes

Credentials can be set at two levels: Scope is checked before authentication method. If you have any personal credential for an agent, Replicas uses it, even when the organization has one the agent would otherwise prefer. A personal Anthropic API key beats an organization Claude account. Method order only decides between credentials in the same scope. Only organization admins can add, replace, or remove organization-level credentials. Organization members are trusted users who can access shared coding-agent credential values. Replicas injects these credentials into workspaces, where members can retrieve them through their coding agent or terminal. Set personal credentials under Personal: coding agent keys in Coding Agents and provider connections in Connections. replicas claude-auth, replicas codex-auth, and replicas muse-auth save at the user level unless an admin passes --org. During onboarding, an admin’s first connection also becomes the organization default. Each command prints the scope for confirmation before saving.

​
How Credentials Are Used

When a workspace is created, Replicas identifies the user and uses their credentials if available, falling back to organization credentials. Every agent resolves credentials the same way, so scope precedence and method order behave identically for all of them.

​
Coding Agent Auth Fallback

Scope is decided before auth method: every credential you own is tried first, and the organization’s are used only if you have none. Method order breaks ties within a single scope. The default order per agent: So if the organization has a Claude account and you have your own Anthropic API key, your key wins and your work bills you rather than the organization. When a workspace reports that its credential was rejected, Replicas force-rotates that credential first if it is OAuth, and moves on only if the provider rejects the refresh. Only the rejected credential is skipped: the same method in the other scope stays available, and a personal token failing never rotates the organization’s shared one. OAuth token refreshes are serialized per credential, so concurrent workspaces crossing the expiry threshold together no longer invalidate each other’s tokens. Refreshing Claude OAuth retries through provider rate limits and server errors rather than counting them as a rejection, so a temporary Anthropic outage does not prompt a reconnect or move the chat along its fallback chain. Only a refresh the provider actually rejects, such as invalid_grant on a revoked or superseded token, marks the credential as needing reconnection. Workspaces also re-resolve credentials when waking from hibernation, so a workspace that was sleeping while the OAuth token rotated upstream picks up the latest credentials on wake instead of failing the first message. A workspace that resolves to a non-OAuth credential has any account login file from a previous owner removed, so a reused sandbox never authenticates as someone else.

​
Mothership

Each member’s Mothership is a workspace they own, so it resolves credentials like any of their workspaces: their own first, then the organization’s, following their fallback chain. The organization-scoped Mothership that triages Linear teams and Slack messages from bots and non-members uses organization credentials.

​
Fallback Chains

Each harness has a fallback chain: the order its credentials are tried, with optional fork steps to other harnesses in between. Edit chains on the Fallbacks tab of Coding Agents, in Personal or, for admins, Organization. An organization with committed Bedrock spend can put AWS Bedrock first; a member who prefers their own API key can rank it above the shared account; a team that would rather switch tools than pay per token can put Codex right after the Claude subscription, ahead of the API key. The first step is always a credential: it is where a chat starts, and fork steps can only follow it. Credential steps switch the running chat to another credential of the same harness. Harness steps fork the chat to that harness with its sanitized transcript and resend the interrupted request; they are skipped when the harness has no credentials in the workspace or is already in the chat’s fork ancestry. Harness steps fire for Claude Code, Codex, Muse Code, and OpenCode, the harnesses that report usage limits. A new chain applies to every workspace created after the change. A running workspace keeps the credential it already resolved until it wakes from hibernation or moves along its chain. Each harness step has a model menu. A chosen model is the one the fork runs on, and the step is skipped if that model is no longer available. With Default model, Replicas uses your saved default model if the target supports it, then the organization’s default, then the target’s built-in default or an available model; OpenRouter picker visibility does not restrict these defaults. Targets whose catalogs cannot be loaded are skipped. Ollama and OpenAI-compatible endpoints serve their own models, so on Claude and Codex chains those credential steps also show a model menu once the credential is connected. When a chat switches to one, it moves to the chosen model for the retried message and later ones. Without a choice, the chat keeps its current model, which the endpoint may not serve. A member’s chain replaces the organization’s for that harness only, so changing Claude personally leaves the organization’s Codex chain in place. Scope still comes first: your credentials are tried before the organization’s no matter how the chain is arranged. Remove a credential from the chain and Replicas never falls back to it; a chain holding only its first credential means no fallback at all. A chain always keeps at least one credential, and a workspace can still start on a removed credential when nothing in the chain is configured. Organization admins can turn off Automatic fallback at the top of the Fallbacks tab under Organization → Coding Agents. Replicas still uses the first configured credential in chain order and can refresh that same OAuth credential, but it stops the turn instead of walking the chain when authentication or quota fails. The setting applies to every member and workspace in the organization.

​
Quota Exhaustion Fallback

When Claude, Codex, Muse, or OpenCode reports a usage limit or an empty credit balance, the workspace walks that harness’s fallback chain from the exhausted credential on. A credential step moves the same chat to that credential and retries the message; a harness step forks the chat. Nothing is recreated on a credential switch: same workspace, same chat. You are told twice: a note in the chat where it happened, and a Fell back marker beside that agent in the workspace Info panel showing which credential is live now. Both name the account, such as a member’s personal Claude account or the organization’s ChatGPT account, with the login email for organization credentials. If the chain runs out, the turn stops, names the account that hit the limit, and says that nothing further is configured; a Slack thread or Linear issue that started the turn gets the same message. If the next credential is configured but cannot be used, the error says so instead. In either case, open Coding Agents: the Fallbacks tab to adjust the chain, or the Agents tab to add or reconnect a credential. Only the exhausted credential is skipped, because the same method in the other scope is a separate account and stays eligible. Exhausted OAuth is never force-rotated, since refreshing it would return the same empty account. The routine credential refresh skips it too, so the workspace stays on the fallback until it next wakes or you switch credentials manually.

​
Authentication Retry Behavior

If Claude, Codex, or Cursor returns an authentication error mid-conversation (for example, an access token that expired between messages, a ChatGPT session that ended on Codex, or a revoked Cursor API key), the workspace pauses the chat instead of surfacing the raw error. An amber re-authentication pill appears above the composer and the textarea and Send button stay disabled while credentials are refreshed and your message is replayed automatically. If every retry fails, Codex and Cursor chats show a “Couldn’t authenticate” message for the selected agent. Claude chats show guidance for the selected credential method: reconnecting Claude OAuth, checking Anthropic API key validity, credits, and model access, or checking Bedrock credentials, region, IAM permissions, and model access. Check your credentials in Personal → Coding Agents, or Organization → Coding Agents if you are an admin, and try again.

​
From Linear

When you assign an issue to Replicas, it uses your connected Linear account to find your Replicas account. Connect it under Personal → Connections. Email matching remains a fallback. Your personal agent credentials and preferences are used if configured.

​
From Slack

When you mention Replicas in Slack, it uses your connected Slack account to find your Replicas account. Connect it under Personal → Connections. Email matching remains a fallback.

​
From GitHub

Your personal GitHub account is automatically connected when an admin connects GitHub at the organization level. When you mention @tryreplicas on a PR, Replicas identifies you by your GitHub login and uses your personal credentials. If your saved GitHub credential is unavailable when you create a dashboard workspace, Replicas prompts you to reconnect and links directly to GitHub under Personal → Connections. You can also use Connections to reconnect or switch your GitHub or GitLab account manually.

​
From GitLab

When you mention @tryreplicas on a merge request or issue, Replicas identifies you by your GitLab username and uses your personal credentials. Connect your personal GitLab account from Personal → Connections to attribute merge requests to you. See GitLab integration.