Agents and Models

On most OpenAI-compatible hosts, model picks a foundation model from a catalog. On TAIBLES, model selects what runs: an agent you (or your org) built, or a chat LLM URL routed through the default assistant.

List available models

GET /v1/models
Authorization: Bearer sk-tbl-<your-key>

The response is an OpenAI-style list. Each entry has at least:

Field	Meaning
id	Value to send as model in chat completions
owned_by	taibles
display_name	Human-readable name (agents and LLMs)
description	Optional description

The list includes:

1. All AGENT taibles in your organization — id is a slug derived from the agent name (lowercase, hyphenated), or the agent UUID if the name cannot be slugified
2. Configured chat LLMs — id is a URL of the form {provider}://{alias|modelName} (for example openai://gpt-5.4)

default-assistant is always valid as a model id even when you do not see a separate catalog entry for it; it resolves to your organization's default assistant.

Resolution order

When you send model on POST /chat/completions:

1. default-assistant → organization default assistant
2. UUID → that AGENT taible (must exist in your org)
3. Slug → AGENT whose name slugifies to that string
4. Known chat model URL → default assistant with that LLM for the turn (modelUrl override)
5. Otherwise → 404 (model_not_found)

Slug rule: trim, lowercase, replace non-alphanumeric runs with -, strip leading/trailing hyphens. Example: Support Bot → support-bot.

Because the slug comes from the agent name, it changes when the agent is renamed. The agent UUID never changes, so prefer the UUID for long-lived integrations.

Finding the values in the product

Open the agent, then use "Connect via API" in the publish section. That dialog shows the base URL and the model id for this specific agent, lets you create an API key on the spot, and gives you a ready-to-paste snippet for cURL, Python, or Node.js.

What you get when you call an agent

Calling an agent is not the same as calling a bare LLM. The agent runs inside TAIBLES with whatever you equipped it with in the product, for example:

• Direct use of connected tools / nodes
• Access to knowledge collections
• Memory and files (subject to builtin tool settings)
• Ability to build or trigger automations (when enabled for that assistant)

API keys act as you: the same agents, memories, and files you see in the UI are available over the API.

Calling a custom agent

# By slug (from GET /models)
curl "$BASE_URL/chat/completions" \
  -H "Authorization: Bearer $YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "support-bot",
    "messages": [{"role": "user", "content": "Summarize open tickets"}]
  }'

# By UUID
curl "$BASE_URL/chat/completions" \
  -H "Authorization: Bearer $YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "01234567-89ab-cdef-0123-456789abcdef",
    "messages": [{"role": "user", "content": "Summarize open tickets"}]
  }'

Plain LLMs

When model is a chat LLM URL from GET /models, TAIBLES still routes through the default assistant and applies that model for the turn. You get OpenAI-compatible completions without selecting a specialized agent by id.

See Chat completions for streaming, client tools, and TAIBLES-specific options.