For the complete documentation index, see llms.txt. This page is also available as Markdown.

LLM Models

The LLMs section governs which models are available to agents, and which model a Workspace, Project, or the platform as a whole uses by default. It's reached from AI Admin → LLMs, and has three tabs: Agent SDKs, LLMs, and LLM Mappings.

LLMs tab — the model registry

Agent SDKs

An Agent SDK is a connection to a deployed agent runtime — the same entity described in Adding a Custom Agent: a Name, Description, Endpoint, and Path. It's listed here because every model in the registry is registered under one.

Agent SDKs tab

Click + Add to register another one.

Add Agent SDK form
Add Agent SDK form filled in
Agent SDK added

LLMs

The LLMs tab is the model registry itself — every model an agent is allowed to use, paired with the Agent SDK(s) that can run it.

Click + Add and fill in:

  • Agent SDKs* — which SDK(s) this model can run under

  • Model ID* — the underlying model identifier (e.g. claude-sonnet-5)

  • Display Name* — a human-readable name shown in ticket creation and elsewhere (e.g. Sonnet 5)

  • Description — optional

  • Enabled — toggle it off to keep a model registered but unavailable for selection

Add Model form
Add Model form filled in
New model in the registry

This registry doesn't have a "Provider" field — it doesn't matter here whether a model runs on AWS Bedrock, GCP Vertex AI, Azure AI Foundry, or directly against the Anthropic API. That's determined by environment variables on the Agent SDK's own deployment, not by anything you configure in this UI.

LLM Mappings

A Mapping controls which registered models are actually usable — and which one is the default — for a given scope. This is what makes the registry an allow-list: if no mapping covers a workspace, no models are available to it at all.

LLM Mappings tab

Click + Add and fill in:

  • Name* and Description — a label for this mapping

  • Models* — the model + SDK pairs this mapping allows

  • Scope*System, Workspace, or Project

  • Default model — required for System scope; optional for Workspace/Project (falls back to the next broader scope's default if unset)

  • Target Workspace(s)* / Target Project(s)* — shown only for Workspace/Project scope; select one or more

Add Model Mapping form
Add Model Mapping form filled in
New mapping added

Resolution order is Project → Workspace → System — the most specific mapping that covers a given ticket wins. A fresh install seeds one System-scope mapping ("default models") automatically, so every workspace has a working default even before you add your own mappings.

Last updated

Was this helpful?