Your Own Models

Every provider's own models are already in the model lists. They work as soon as the provider's key or account is in the vault.

Studio's Models page is for one thing: adding a model that runs on your own server, such as your vLLM or Ollama server. For each model you add, it shows its status, the price record tagged to it, and which agents use it.

Before you add a model: its connection

The server's address and sign-in live in the vault, on one record:

Infrastructure → add a Custom connection.
Choose the service type Model.
Enter the server's base URL. It is required: it is the model's address. http://gpu-box:8000 is enough; the interface adds the rest.
If the server needs authentication, add the headers it expects, for example Authorization (mark it secret).
Save.

Add a model

Add a model once and every agent can name it in model:.

You give	What it means
Name	What agents write: `model: acme-fast`.
Interface	How the server is spoken to: vLLM, SGLang, Ollama, llama.cpp, LM Studio, TGI, LocalAI, Triton, or any OpenAI-compatible server. Ollama's native API, Text Generation Web UI and the Hugging Face Inference API also work, without tools.
Connection	Required: the Model connection that holds the server's base URL and any sign-in headers, picked from a list. Add one on Infrastructure if it isn't there.
Timeout	Optional: how long a call may take.
Fixed query values	Optional: values the server needs on every call, for example `api-version`. Keys never go here.
Price	Optional: a price record from Pricing.
Model id	Optional: the id the server knows it by, when that differs from the name (for example `meta-llama/Llama-3.1-8B-Instruct`).

agents:
  triage_agent:
    agent_type: llm
    model: acme-fast        # added on the Models page

Press Test to make one tiny call and see that it answers. A model's status (ok, degraded, down or untested) comes from its Tests and from its real calls. Nothing is checked in the background.

From 2.4.460 a model can no longer be added "on a provider": a provider's models are already listed. An older entry of that kind is skipped at start, with a warning.

How calls are routed

A model you added goes exactly where you said. Its own server gets its own address and its own key, never another server's.
A provider model whose provider is not set up fails with a message naming the provider. It is never sent to another provider instead.
The list flags models your agents name that can't run, or that have no price.

Status page

GET /api/status (Studio's Status page) shows, on one scale (ok, degraded, down, untested, needs setup), whether everything the mesh uses is working:

every model an agent uses, and every model you added
API tools and Tools-page entries
vault connections

It puts what the mesh uses and what's down first. summary.in_use_down is the number to watch.

Price

Pricing is its own page. You create a price record (a name and its prices), then tag it to a model, from either page. One record can price many models. A tagged model's every cost uses its record:

budgets
the budgets page
each trace's per-loop cost

Untag it to go back to the standard price. See Budgets.

API

Endpoint	Purpose
`GET /api/models`	The models you added, each with its status, whether it is ready, its tools and the agents that use it. Filter with `q`, `used`, `state`; page with `offset`, `limit`.
`GET /api/models/connections`	The Model connections a model can use.
`GET /api/models/interfaces`	How a server can be spoken to.
`POST /api/models`	Add: `{name, server: {interface, timeout?}, connection, query?, model_id?, label?, price_id?}`. `runs_on`, if sent, must be `server`.
`PUT /api/models/{name}` · `DELETE /api/models/{name}`	Change (including `price_id`; `null` untags), or remove (its price tag goes; the record stays).
`POST /api/models/{name}/test`	One tiny call: does it answer?
`POST /api/pricing/{id}/models` · `DELETE /api/pricing/{id}/models/{model}`	Tag a price record to a model (`{"model": "<name>"}`), or untag it.