Use Dome as a model broker

Your assistant already calls a model every time you chat with it. That call carries its own problems: a provider key sitting in the client's config, spend nobody notices until the invoice, and a model locked to whatever provider the client shipped with.

In this tutorial, you will hold a provider key in Dome, register your assistant, and repoint its own inference (not a script, the assistant itself) at the Dome gateway. The provider never learns Dome is in front of it; it just sees a different caller.

Prerequisites

For this tutorial, you will need:

• The Dome CLI. Refer to Install for Homebrew and direct-download instructions.
• A role that can provision a sandbox and deploy rules: admin, operator, or equivalent.
• An API key for OpenAI, Anthropic, or both. Dome calls the provider on your behalf, so the spend lands on your provider account. A key for each provider lets you try swapping which model answers a given client, later in this tutorial.
• Cursor, Claude Code, or Codex, each configurable with a custom model base URL and key.

Prepare your environment

Sign in and provision a throwaway sandbox:

dome auth login
dome sandbox provision --scope=workspace --workspace-name connect-assistant
dome context sync
dome context use sandbox-connect-assistant

If you already have sandbox-connect-assistant from Use Dome as an MCP gateway, reuse it. This tutorial does not touch that Gateway's tools.

Confirm the workspace before continuing:

dome context current

Add a model connection

A model connection is one upstream LLM endpoint and the credential Dome uses to reach it. The endpoint a client points at is a wire protocol, not a provider. Dome's Anthropic-shaped endpoint and its OpenAI-compatible endpoint can each resolve to any connection you name. The model behind a connection does not have to match the client calling it.

Add whichever provider you have a key for. Add both if you want to try the swap later in this tutorial:

dome models add claude-broker \
  --provider anthropic \
  --model claude-3-5-sonnet-20241022 \
  --api-key "$ANTHROPIC_API_KEY" \
  --gateway Default

dome models add openai-broker \
  --provider openai \
  --model gpt-4o \
  --api-key "$OPENAI_API_KEY" \
  --gateway Default

--gateway Default attaches it directly, without a pool. A pool buys you failover and weighted routing across several connections. Reach for one once you have more than one model to route across; a single connection does not need it.

Confirm the connection is registered:

dome models get claude-broker   # or openai-broker

Create the agent

Every call through a Gateway is authorized and audited against this agent identity, not against Cursor, Claude Code, or Codex as a product.

Register an agent for your assistant, then mint a credential:

dome agents register --name code-assistant --if-not-exists
dome agents create-key code-assistant --name model-client

The Token: dome_… value is shown once. Save it. You paste it into your client's model configuration in a few steps.

Authorize inference

Grant access to the Gateway if you have not already:

dome gateways access grant Default code-assistant

llm:invoke is a separate action from mcp:call, so a tool-calling permit does not cover inference.

Create code-assistant-llm.cedar:

permit(
  principal is Dome::Agent,
  action == Dome::Action::"llm:invoke",
  resource is Dome::LLMModel
);

resource is Dome::LLMModel scopes the permit to this workspace's model connections, not a specific one, so adding a second model later needs no rule change.

Deploy it scoped to this agent:

dome rules apply code-assistant-llm.cedar --agent code-assistant --name code-assistant-llm

Point your assistant at Dome

Each client reads its base URL and key differently.

One call resolves both base URLs, so there is nothing to assemble by hand:

dome gateways get Default --json

Copy endpoints.anthropic_base_url for Claude Code, or endpoints.openai_base_url for Cursor and Codex. {AGENT_API_KEY} is the dome_… token from the previous step.

export DOME_AGENT_TOKEN="AGENT_API_KEY"

[model_providers.dome]
name = "Dome"
base_url = "OPENAI_BASE_URL"
env_key = "DOME_AGENT_TOKEN"
wire_api = "chat"

model_provider = "dome"
model = "openai-broker"   # or "claude-broker"

# macOS
launchctl setenv DOME_AGENT_TOKEN "AGENT_API_KEY"

export ANTHROPIC_BASE_URL="ANTHROPIC_BASE_URL_VALUE"
export ANTHROPIC_API_KEY="AGENT_API_KEY"
export ANTHROPIC_MODEL="claude-broker"   # or "openai-broker"

{
  "env": {
    "ANTHROPIC_BASE_URL": "ANTHROPIC_BASE_URL_VALUE",
    "ANTHROPIC_API_KEY": "AGENT_API_KEY",
    "ANTHROPIC_MODEL": "claude-broker"
  }
}

Verify the results

Restart your client, then ask it anything.

The response itself proves nothing about the path, so check audit instead:

dome audit query --limit 5

Expect a completed model.call event naming claude-broker or openai-broker, attributed to code-assistant, with token usage. If you set ANTHROPIC_MODEL=openai-broker or pointed Codex at claude-broker, that event is the proof. The client's native provider and the model that actually answered are different, and Dome is what bridged them.

Next steps

Your assistant's own inference (not just a demo script) now runs through Dome. Continue with:

• Set Usage Limits to cap what your assistant can spend per day or month before it becomes a surprise invoice
• Call a model through a pool to add failover across two models behind the same name
• Use Dome as an MCP gateway if you have not governed this assistant's tool calls yet