/api/show returns stubs — populate model_info context_length + details so Ollama-compatible clients can auto-configure

[LarsArtmann]

Problem

flm serve exposes Ollama-compatible endpoints, but /api/show returns a hardcoded stub that ignores the requested model (verified on v1.0.1, same for every tag — loaded or not):

{"details": {"family": "", "parameter_size": "", "quantization_level": ""},
 "model_info": {"general.architecture": "flm"},
 "capabilities": ["chat", "vision", "completion"]}

Context length is exposed nowhere in the HTTP API — /v1/models returns only id/owned_by (no meta.n_ctx like llama-server). So Ollama-API clients cannot auto-configure: they get context_window=0 for every model and need hardcoded per-model tables.

Goal

As an Ollama-API client, I query /api/show and get correct context length, parameter size, and quantization per model — no hardcoded tables. E.g. provider add flm --type ollama --base-url http://localhost:52625 in agent CLIs like Crush (reads any *.context_length key from model_info) then works with zero extra config, discovery included.

Evidence (it's wiring, not missing data)

1. handle_show (src/server/rest_handler.cpp:599-623) returns a hardcoded literal JSON — it reads request["model"] and then ignores it. No lookup is performed.
2. The registry (model_list.json) already carries everything per model, e.g. qwen3.6-moe:35b-a3b:

   {"default_context_length": 32768, "max_prefill_len": 4096, "vlm": true,
    "details": {"format": "NPU2", "family": "qwen3.6-moe", "parameter_size": "35B",
                "quantization_level": "Q4_K_S", "think": true}}

3. /api/ps already serializes this same data (model_info["details"], rest_handler.cpp:1008-1015) — and returns real values for the running model, while /api/show returns empty strings for that same model. Only context length is missing from both.

Suggested fix

In handle_show: call supported_models.get_model_info(model), serialize details, and emit flm.context_length (= default_context_length) in model_info. Optionally mirror context in /v1/models.

Open design choice: report default_context_length (what the server actually runs, matches Ollama's n_ctx semantics) vs. the model family max (256k here).

Research was done by GLM-5.3 via Crush

[LarsArtmann]

Additional data point: /api/ps (loaded models) already returns real details — {"family":"qwen3.6-moe","format":"NPU2","parameter_size":"35B","quantization_level":"Q4_K_S","think":true} — so the metadata exists server-side, it is just not populated in /api/show (which returns empty strings for the same model, loaded and running). Only context length is missing from both.

[LarsArtmann]

Source-level confirmation that this is pure wiring, not missing data:

1. handle_show (src/server/rest_handler.cpp:599-623) returns a hardcoded literal JSON — it reads request["model"] and then ignores it completely. No lookup is performed.
2. The registry already carries everything needed per model, e.g. from model_list.json for qwen3.6-moe:35b-a3b:

{"default_context_length": 32768, "max_prefill_len": 4096, "vlm": true,
 "details": {"format": "NPU2", "family": "qwen3.6-moe", "parameter_size": "35B",
             "quantization_level": "Q4_K_S", "think": true},
 "label": ["vision", "reasoning", "tool-calling"]}

3. /api/ps already serializes model_info["size"] and model_info["details"] (rest_handler.cpp:1008-1015) — same accessor handle_show could use.

So the fix is: call supported_models.get_model_info(model) in handle_show, serialize details, and emit flm.context_length (= default_context_length) in model_info. The only design choice is which number to report — default_context_length (what the server actually runs, matches Ollama semantics) vs. the model family max (256k for this one).