• Choosing a model
• Providers
• Endpoint overrides
• Icons
• Availability
• Priority
• Capabilities
• Ratings
• Usage tracking
• Records API
• Search Query Fields

An agent model configures a single LLM model that automations and AI agents can use. It holds the provider, the model ID, an optional API endpoint override, the connected account supplying credentials, the size of the model's context window, a block of provider-specific parameters, and a description of what the model can do and how it compares to the others you've configured.

Once a model exists, an automation references it by name rather than repeating a provider block inline:

llm.chat:
  output: results
  inputs:
    model: haiku
    messages:
      0:
        role: user
        content: Summarize this conversation in one sentence.

Choosing a model

You don't need to know a provider's model IDs. Once the provider and its connected account are set, the record's editor asks the provider which models that key can actually use and offers the live list.

This matters most for self-hosted OpenAI-compatible endpoints – llama.cpp, LM Studio, vLLM, or a local Ollama – where no hardcoded list could know what's currently loaded. For hosted providers, the live list is simply the current one.

A provider whose endpoint doesn't offer a model list falls back to a built-in set of known IDs.

Providers

The provider field is one of: anthropic, aws_bedrock, docker, gemini, groq, huggingface, ollama, openai, openrouter, pinecone, qwen, together, voyage, or zai.

A local provider such as ollama or docker needs no credentials, so connected_account_id is optional.

That list isn't a limit. Any service that speaks the OpenAI API or Anthropic API protocol works: set provider to openai or anthropic to match the protocol, then point api_endpoint_url at the service.

Endpoint overrides

api_endpoint_url overrides the provider's default endpoint. Leave it blank to use the provider's own. When set, it wins over any api_endpoint_url: left in params_kata.

This is what makes an unlisted provider usable – a self-hosted runtime like llama.cpp, LM Studio, or vLLM, or a hosted gateway, proxy, or vendor that emulates either protocol.

The field suggests endpoints as you type, drawn from the ones the selected provider is known to use. It stays free text, so an endpoint that isn't in the list still works. This matters most on aws_bedrock, which is addressed by region – the suggestions save looking up the hostname for the region your models are in.

Icons

Most models arrive over an OpenAI-compatible API, so the provider ID often can't name the actual vendor. icon and icon_color override the brand mark this model displays with; blank falls back to the provider's own icon. The icon must be a name from the shipped icon set – an unknown name renders as an empty box.

Availability

Every model has one of three availability statuses, set under Status in the editor:

Unlisted is the state for a model you want reachable by name without it turning up wherever something asks for "a model" – an expensive model kept for one script, or one you're still evaluating.

Availability is re-checked against each record every time a pool resolves, so unlisting or disabling a model takes it out of every pool immediately. Because unlisted and disabled models are excluded before a caller's own search runs, no search ever has to mention status, and no automation can widen a pool past what an admin allowed.

Priority

priority is the admin's fixed default order for a resolved pool, ascending – 0 is offered first and 255 last. Set it on the models you prefer and every automation that doesn't name a model follows that order.

It's the same priority convention used by automation event listeners, mail routing rules, and search indexes. Any explicit sort: in a search overrides it entirely.

Capabilities

Capabilities are facts about the model. They're yes-or-no, and they filter – a model that can't accept images isn't eligible for work that sends one, because sending it one is an error rather than a degraded result.

Attaching an image to a model without vision fails the request rather than quietly dropping the image, and the error names the model.

Ratings

Ratings are comparisons rather than facts. Each is a four-tier scale you fill in like a star rating, and each tier has a name you can type in a search query:

They work as floors and as sort orders, so one query can express several different kinds of requirement:

intelligence:>=advanced privacy:>=zdr cost:<=cheap

Privacy is a ladder where each step includes the ones below it, so privacy:>=zdr picks up self-hosted models too without naming them. It's a hard requirement rather than a preference on purpose: a retention rule that was requested and quietly ignored looks exactly like one that was honored.

Cost is the one rating where less is better, and the editor says so: the other three fields are hinted "Higher is better", while Cost reads "Lower is better. Price per token and caching." It's a rough tier for routing, not billing.

Ratings start blank, and an unrated model sorts last. An installation that never fills them in behaves exactly as it did before.

Each rating stores a sparse tier value – 10, 20, 30, 40, with 0 meaning unrated – rather than 1 through 4. The decade gaps leave room to insert a tier without a migration, and they keep the name separate from the value behind it, so the scale can move as the field does. When today's frontier models become ordinary, frontier is repointed and existing records read as the tier below it without a row being rewritten.

Queries and bulk updates use the lowercase names above; the interface capitalizes them for display, so zdr reads as ZDR and no-training reads as No-training.

Usage tracking

Agent Model worklists offer two sparklines columns – Usage and Tokens – each with a 2h/1d/30d range toggle, drawn from the agent turn metrics. They're two columns rather than two series in one, because turns and tokens differ by orders of magnitude and bars sharing a stack share one scale.

Matching usage: and tokens: quick search filters query the same data. Each takes its own series names in parentheses:

usage:(rate_limited:>0 since:today)
tokens:(output:>1000000 since:-30 days)

Token counts are their own key rather than a series inside usage: so that one autocomplete list never mixes token counts with millisecond durations.

Records API

These fields are available in the Records API and packages:

Search Query Fields

These filters are available in agent model search queries: