Model catalog

The same model registry backs every inference API on api.kindo.ai. Whichever model ID you discover via /v1/models works as the model parameter on /v1/chat/completions, /v1/responses, and /v1/messages — Kindo routes to the correct upstream provider for you.

Discover available models

curl https://api.kindo.ai/v1/models \
  -H "Authorization: Bearer $KINDO_API_KEY"

The response uses the standard OpenAI models-list format, enriched with the human-readable display_name:

{
  "object": "list",
  "data": [
    {
      "id": "claude-sonnet-4-5-20250929",
      "object": "model",
      "created": 0,
      "owned_by": "kindo",
      "display_name": "Claude Sonnet 4.5"
    },
    {
      "id": "gpt-4o-2024-11-20",
      "object": "model",
      "created": 0,
      "owned_by": "kindo",
      "display_name": "GPT-4o"
    }
  ]
}

You only see models your organization has access to — model visibility is governed by your user-group configuration.

Model display name

Beyond the four OpenAI fields (id, object, created, owned_by), each proxied-model entry carries one additive Kindo field:

Field	Type	Description
`display_name`	string	Human-readable model name, as shown in the Kindo Terminal.

This field is additive — id is still the model ID you pass back as the model parameter, and OpenAI SDK clients ignore the extra field, so existing integrations are unaffected. Agent entries (include_agents=true, below) do not carry it.

You can also inspect the same list under Settings > Kindo API > Available Models in the Kindo Terminal.

Listing agents as models

Your stored Kindo agents are invocable as models on /v1/responses (see Invoke Kindo agents with the Responses API). Add include_agents=true to list them alongside the model catalog:

curl "https://api.kindo.ai/v1/models?include_agents=true" \
  -H "Authorization: Bearer $KINDO_API_KEY"

Agent entries use the same models-list shape:

{
  "id": "agent/8e051857-978c-4207-8916-28a3d4c4d605",
  "object": "model",
  "created": 1748736000,
  "owned_by": "Acme Inc"
}

id is agent/<agent-id> — pass it directly as the model parameter on POST /v1/responses.
owned_by is your organization’s name (or its ID when the org has no display name), distinguishing agents from "kindo"-owned models.
created is the agent’s actual creation timestamp.
Only agents you can access are listed, scoped the same way as GET /v1/agents/list. Trigger-driven agents are excluded because they cannot be invoked directly.

The agents portion is paginated. Pass limit (1–1000, default 500) and after (an offset, default 0) to page through them; the response carries has_more and a next_after offset to request the next page:

# First page
curl "https://api.kindo.ai/v1/models?include_agents=true&limit=2" \
  -H "Authorization: Bearer $KINDO_API_KEY"
# → "has_more": true, "next_after": 2

# Next page
curl "https://api.kindo.ai/v1/models?include_agents=true&limit=2&after=2" \
  -H "Authorization: Bearer $KINDO_API_KEY"

Repeat with after = next_after until has_more is false to walk the complete set. Proxied ("kindo"-owned) models are not paginated — they are returned in full on the first page (after=0) only and omitted from later pages, so concatenating pages yields exactly one copy of each.

Offsets are stable as long as the agent set is unchanged between page requests; an agent created or deleted mid-walk shifts the window and can skip or duplicate an entry across page boundaries (inherent to offset pagination).

Without the parameter (the default), the response is unchanged except for an added "has_more": false — existing /v1/models consumers are unaffected. Agent IDs are only valid on /v1/responses; the other inference endpoints treat them as an unknown model.

Naming conventions

Model IDs follow the upstream provider’s published name with the date suffix the provider uses. A few representative examples:

Family	Example IDs
Anthropic Claude	`claude-sonnet-4-5-20250929`, `claude-opus-4-20251125`
OpenAI GPT	`gpt-4o-2024-11-20`, `gpt-4o-mini-2024-07-18`
OpenAI o-series	`o1-2024-12-17`, `o3-mini-2025-01-31`

Kindo does not rename models. If you’ve used these IDs against the upstream provider directly, the same string works against api.kindo.ai.

The exact set evolves — GET /v1/models is the source of truth. Hard-coding a model ID into your client is fine; assuming a model will exist forever is not. Inference endpoints return 400 for an unknown model.

Cross-API model use

You can use the same model ID on whichever inference protocol your client speaks:

A claude-* model works on /v1/chat/completions, /v1/responses, and /v1/messages — Kindo translates the wire format for you.
A gpt-* model works on all of them — same translation.

In practice, pick the protocol that matches your SDK; pick the model based on capability, latency, and cost.

Errors

Status	Meaning
`403` `model_access_denied`	The model exists but your organization is not entitled to call it.
`400` `model_not_found`	The model ID is not registered on inference endpoints. Check `GET /v1/models`. Emitted by `/v1/chat/completions` and `/v1/responses`. `/v1/messages` returns `400 invalid_request_error` without a code field — see Messages errors.

If your client returns a model error, hit /v1/models first. Most “unknown model” reports trace back to a stale model ID.