---
title: "Detail counterpart to `get_models`."
method: GET
path: "/v1/models/{model}"
tags: ["models"]
---

# Detail counterpart to `get_models`.

`GET /v1/models/{model}`

## Path parameters

- `model` string, required

## Response `200`

Model detail

- ModelInfoWire — Wire shape aligned with ``sie_server`` ``ModelInfo`` for ``GET /v1/models``.
  - `capabilities` ModelCapabilitiesWire — Capability summary surfaced on each entry of ``GET /v1/models``. Mirrors the JSON shape constructed in ``types/model.rs::to_model_info_value``. All fields are optional — their presence depends on what the model config declares. These flags indicate that a model *supports* a task — they are NOT a precision-independent quality SLA. A flag is true at the model level even when quality is profile/precision-dependent (e.g. ``sql`` quality regresses under FP8; route SQL-critical traffic to a BF16 bundle via the ``sql`` alias). Treat them as "can do this", not "guaranteed to score X".
    - `code` boolean, required — Whether the model is validated for code generation — backs the ``model="code"`` alias. Informational only; never request-gated.
    - `grammar` string[], nullable — Grammar kinds the model's active backend supports (``json_schema`` | ``regex`` | ``ebnf``). EBNF presence depends on the backend: SGLang's Outlines backend does not implement EBNF, so a profile with ``grammar_backend: outlines`` advertises only ``["json_schema", "regex"]``; xgrammar/llguidance profiles advertise all three.
    - `guard` boolean, required — Whether the model is a content-moderation / policy-check guard — backs the ``model="guard"`` alias. Informational only; never request-gated.
    - `lora_adapters` string[], nullable — Union of LoRA served-names across profiles. Back-compat summary for consumers that don't care about profile scope; validation MUST go through ``profile_lora_adapters``.
    - `profile_lora_adapters` object, nullable — Per-profile LoRA breakdown — keyed by profile name. Added by M10 so consumers needing precise routing scope don't have to reverse-engineer it from the union. The validation gate uses this map; ``lora_adapters`` is for display only.
    - `sql` boolean, required — Whether the model targets the SQL path — backs the ``model="sql"`` alias. Informational only; never request-gated. Precision-sensitive: SQL quality can regress sharply under FP8, so this model-level flag is a support signal, not a per-profile quality guarantee.
    - `tools` boolean, nullable — Whether the model supports tool / function calling.
  - `dims` object, required
  - `inputs` string[], required
  - `last_error` unknown
  - `loaded` boolean, required
  - `max_sequence_length` integer, nullable
  - `name` string, required
  - `outputs` string[], required
  - `pending_generation` PendingGenerationSnapshot
    - `groups` PendingGenerationGroup[], required
      - `active_streams` integer, required
      - `count` integer, required
      - `display_model` string, required
      - `model` string, required
      - `oldest_request_age_ms` integer, required
      - `pool` string, required
      - `republished` integer, required
      - `waiting_first_chunk` integer, required
    - `total` integer, required
  - `profiles` object, required
  - `revision` string, nullable — Immutable model weights revision, when the catalog pins one.
  - `state` string, required

## Other responses

- `401` — Missing or invalid bearer token (inference token)
- `404` — Model not found
- `500` — Gateway auth enabled but no tokens configured

---

[API](https://skmtc.net/superlinked/apis/sie-gateway.md) · [All operations](https://skmtc.net/superlinked/apis/sie-gateway/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/superlinked/sie-gateway/versions/516a1abd18c8/schema)