Settings

The Settings page is where ORG Admins configure the organisation's LLM API keys and view the coding agent's SSH public key. These settings control how the platform accesses AI providers and how the coding agent authenticates with your git remotes.

Who can use it

ORG Admins only. ORG Members who navigate to /settings are redirected away.

Navigate to Settings in the Organisation section of the sidebar, or go directly to /settings.

Organisation API Keys

What they are

The platform supports two AI providers: OpenAI and Anthropic. The organisation-level API keys are the default credentials used for all LLM calls across the platform. Discover chat, Define workflow layers, Design workflow layers, and Build agent tasks all use these keys.

When an API key is saved, it is stored encrypted and displayed masked in the UI (only a partial preview is shown on subsequent visits).

Setting your API keys

1. Navigate to Settings in the sidebar.
2. In the OpenAI API Key field, enter your OpenAI API key (beginning with sk-).
3. In the Anthropic API Key field, enter your Anthropic API key.
4. Click Save to persist both keys.

You do not need to set both keys. If you only use one provider, enter only that key. The platform will use whichever keys are available.

If no organisation-level key is configured for a provider, the platform falls back to the environment-level keys configured by your platform operator.

API Key Resolution Priority

When the platform makes an LLM call, it resolves which API key to use in the following order:

1. Project Run override — if the specific project has a per-project API key configured (set from within the Design interface), that key is used.
2. Organisation key — if no project override exists, the organisation-level key from Settings is used.
3. Environment default — if neither of the above is set, the platform uses the keys configured by the platform operator in the environment.

This priority system means you can:

• Use a single shared key for most projects (set at the org level)
• Override the key for specific projects that should be billed separately or routed to a different account
• Have the platform operator provide a fallback key that applies when no org-level key is set

For instructions on setting a per-project override, see Design.

Worker SSH Public Key

What it is

The coding agent (Layer 8 worker) needs to push code commits to your git repository. To authenticate, the agent uses an SSH key pair. The Worker SSH Public Key displayed in Settings is the public half of that key pair.

You need to add this public key to the git hosting service (GitHub, GitLab, Bitbucket, etc.) for the repository the agent will be writing to. This allows the agent to authenticate and push code without a username and password.

Adding the SSH key to your repository

1. Navigate to Settings in the sidebar.
2. Copy the full contents of the Worker SSH Public Key field.
3. Go to your git hosting service:
   • GitHub: Settings → SSH and GPG keys → New SSH key. Paste the key and save.
   • GitLab: User Settings → SSH Keys → Add key. Paste the key and save.
   • Bitbucket: Personal settings → SSH keys → Add key. Paste the key and save.
4. The agent can now push to any repository that account has access to.

The SSH key is generated once by the platform and is fixed for your installation. You only need to add it to a repository once.

How it fits the broader picture

Settings is foundational infrastructure for the entire platform. Without valid API keys, LLM calls across Discover, Define, Design, and Build will fail. Without the SSH key added to your repository, the Build agent cannot commit or push code.

Getting Settings configured correctly should be one of the first things an ORG Admin does after registering and subscribing.

For subscription management, see Billing.