List Models - Kyma API

No authentication required.

The three axes

Every model is described on three independent axes. They answer different questions, and keeping them apart is what makes the catalog filterable.

Field	Question it answers	Values per model
`type`	What is it?	exactly one
`tags`	What can it do?	many
`use_cases`	What would you use it for?	many

The distinction that matters: image is a type; generate-images is a use case. One describes the model, the other describes your job.

`type` — 9 values

language · image · video · embedding · reranking · transcription · audio-understanding · realtime · speech type is the product line you buy the model under — which endpoint serves it and which unit it bills in — not simply what it emits. That is why veo-3, which returns video and audio, is video, and why gemini-3-flash-audio, which returns text, is audio-understanding: you reach it at POST /v1/audio/understand and it bills per minute of audio, not per token. The audio types split by what you are asking for: transcription writes the words down, audio-understanding answers questions about the sound itself, speech generates audio, and realtime is the bidirectional socket.

`tags` — 12 values

tool-use · reasoning · vision · implicit-caching · explicit-caching · file-input · web-search · image-generation · video-generation · websocket-realtime · websocket-transcription · fast A tag is only set when it is objectively true of the model’s own spec. Three of them — fast, implicit-caching, explicit-caching — describe measured behaviour of a serving route rather than the model, so they are currently unset on every model rather than asserted without evidence.

`use_cases` — 14 values

write-code · build-agents · chat · write-content · translate · research-web · analyse-documents · solve-math · generate-images · edit-images · generate-video · transcribe-audio · generate-speech · search-documents

Filtering

All filters are query params. Comma-separated values combine as AND, except type — a model has exactly one type, so listing several means OR.

Param	Combines	Example
`type`	OR	`?type=image,video`
`creator`	OR	`?creator=anthropic,google`
`tags`	AND	`?tags=tool-use,vision`
`use_cases`	AND	`?use_cases=write-code`
`input_modalities`	AND	`?input_modalities=text,image`
`output_modalities`	AND	`?output_modalities=text`
`supported_parameters`	AND	`?supported_parameters=tools,structured_outputs`
`latency_tier`	—	`?latency_tier=fast`
`cost_tier`	—	`?cost_tier=cheap`
`quality_tier`	—	`?quality_tier=frontier-open`
`release_stage`	—	`?release_stage=stable`
`tools` `vision` `reasoning` `structured_outputs`	—	`?tools=true`
`min_context_window`	—	`?min_context_window=128000`
`max_input_price`	—	`?max_input_price=1.00`

creator is who made the model — the value each row carries as owned_by. ?owned_by= is accepted as the same filter, so you can filter by exactly what you just read in the response. Filters compose:

# Everything one lab makes
curl "https://kymaapi.com/v1/models?creator=anthropic"

# Text models that call tools and are good for agents
curl "https://kymaapi.com/v1/models?type=language&tags=tool-use&use_cases=build-agents"

# Anything that produces pixels or frames
curl "https://kymaapi.com/v1/models?type=image,video"

The filters block in the response echoes back exactly what was applied, so you can confirm a param was understood rather than ignored.

recommended_for is deprecated. It is now an alias of use_cases and still works, including the old vocabulary (coding, agent, general, image, …), which is translated to its use_cases equivalent. Prefer use_cases for new integrations. Nothing has been removed — recommended_for remains in every response.

Response

{
  "object": "list",
  "data": [
    {
      "id": "llama-3.3-70b",
      "name": "Llama 3.3 70B",
      "context_window": 128000,
      "max_output_tokens": 8192,
      "description": "Most popular open model. Great all-rounder.",
      "best_for": "General, code, reasoning",
      "speed": "fast",
      "recommended": true,
      "hot": true,
      "input_modalities": ["text"],
      "output_modalities": ["text"],
      "supported_parameters": ["temperature", "top_p", "max_tokens", "stream", "tools", "response_format", "structured_outputs", "prompt_caching", "reasoning"],
      "latency_tier": "medium",
      "cost_tier": "balanced",
      "quality_tier": "strong",
      "release_stage": "stable",
      "type": "language",
      "tags": ["tool-use"],
      "use_cases": ["chat", "write-code"],
      "recommended_for": ["chat", "write-code"]
    }
  ],
  "aliases": { "best": "qwen-3.6-plus" },
  "filters": {
    "type": [],
    "tags": [],
    "use_cases": [],
    "recommended_for": []
  }
}

A model can be served by more than one piece of infrastructure. context_window, max_output_tokens and the supports_* flags describe what is achievable for that model — the largest window reachable, and every capability at least one route can serve. Requests are matched to a route that can handle them, so a call that needs a capability never lands somewhere without it.

curl https://kymaapi.com/v1/models

curl "https://kymaapi.com/v1/models?type=language&tags=tool-use&use_cases=build-agents"

from openai import OpenAI
client = OpenAI(base_url="https://kymaapi.com/v1", api_key="ky-your-api-key")
models = client.models.list()
for m in models.data:
    print(m.id)

​The three axes

​type — 9 values

​tags — 12 values

​use_cases — 14 values

​Filtering

​Response

The three axes

`type` — 9 values

`tags` — 12 values

`use_cases` — 14 values

Filtering

Response