[Skill issue] `local-ai-app-integration`: two recommended model IDs in Step 2 do not exist in the Lemonade catalog

[Edocksil]

Summary

Two of the eight model IDs in local-ai-app-integration's Step 2 — Pick a model + backend profile table do not exist in the Lemonade model catalog. An agent that follows the table for either row picks a model that cannot be pulled.

This lands in the exact failure mode the skill itself warns about at length. Step 6 says:

Silent-empty is almost always an unpulled model. If inference returns an empty string / blank output with no HTTP error, the model was not downloaded. Check your pull step before debugging anything else — this is the failure mode that wastes the most time.

Because the recommended ID isn't in the catalog at all, POST /api/v1/pull cannot succeed, and the developer lands in that debugging loop by following the skill correctly.

The two rows

Row in Step 2	Skill recommends	Status
Coding assistant	Qwen2.5-Coder-7B-Instruct-GGUF (recipe llamacpp)	not in catalog
Speech-to-text (Linux NPU)	whisper-v3-turbo-FLM (recipe flm)	not in catalog

1. Qwen2.5-Coder-7B-Instruct-GGUF

Not present. The catalog has these Coder models — note that no 7B GGUF variant exists:

Qwen2.5-Coder-0.5B-Instruct-Hybrid
Qwen2.5-Coder-1.5B-Instruct-Hybrid
Qwen2.5-Coder-1.5B-Instruct-NPU
Qwen2.5-Coder-32B-Instruct-GGUF
Qwen2.5-Coder-7B-Instruct-Hybrid
Qwen2.5-Coder-7B-Instruct-NPU
Qwen3-Coder-30B-A3B-Instruct-GGUF
Qwen3-Coder-Next-GGUF

The 7B Coder variants that do exist are -Hybrid and -NPU, which are not llamacpp recipes — so the row's recipe column is wrong for them too. The nearest valid llamacpp options are Qwen2.5-Coder-32B-Instruct-GGUF (much larger than the row's "runs on iGPU" framing) or Qwen3-Coder-30B-A3B-Instruct-GGUF (MoE, plausible on an iGPU).

2. whisper-v3-turbo-FLM

Not present, and zero of the 211 catalog entries use the flm recipe.

Compounding this: the flm recipe's own declared modality is Text generation, not speech-to-text. From GET /api/v1/system-info:

"flm": {
  "display_name": "FastFlowLM NPU",
  "modality": "Text generation",
  "backends": { "npu": { "state": "installable", ... } }
}

So the "Speech-to-text (Linux NPU)" row names a nonexistent model on a recipe whose modality is text generation.

Caveat: my catalog snapshot is from a Windows host, and this row is labelled Linux-specific — a Linux-only flm STT model could plausibly be absent here. The recipe/modality mismatch is independent of OS. The Qwen2.5-Coder-7B-Instruct-GGUF miss is OS-independent (GGUF/llamacpp).

Reproduction

# Lemonade 11.5.1, Windows 11, Ryzen AI 9 HX 370
# authoritative catalog: 211 entries
python -c "
import json
c = json.load(open(r'%LOCALAPPDATA%\lemonade_server\bin\resources\server_models.json'))
for m in ['Qwen2.5-Coder-7B-Instruct-GGUF', 'whisper-v3-turbo-FLM']:
    print(m, '->', 'FOUND' if m in c else 'NOT IN CATALOG')
print('models with recipe flm:', [k for k,v in c.items() if v.get('recipe') == 'flm'])
"

Qwen2.5-Coder-7B-Instruct-GGUF -> NOT IN CATALOG
whisper-v3-turbo-FLM -> NOT IN CATALOG
models with recipe flm: []

The other six IDs in the table all check out: Qwen3-4B-GGUF, Gemma-4-E2B-it-GGUF, Llama-3.2-3B-Instruct-Hybrid, Whisper-Large-v3-Turbo, kokoro-v1, SDXL-Turbo — all present.

Suggested fix

• Coding row: use Qwen2.5-Coder-7B-Instruct-Hybrid with recipe ryzenai-llm, or Qwen3-Coder-30B-A3B-Instruct-GGUF with llamacpp if a GGUF/llamacpp default is wanted.
• STT Linux NPU row: drop it, or correct the model ID and reconcile it with flm's Text generation modality.
• Consider a CI check that asserts every model ID named in a SKILL.md exists in server_models.json for the pinned Lemonade version. That would catch this class of drift automatically — it's the same check the skill tells the agent to perform at runtime.

Environment

• Lemonade Server 11.5.1, Windows 11 Pro 26100, AMD Ryzen AI 9 HX 370 / Radeon 890M (gfx1150) / XDNA2 NPU
• Plugin amd-skills @ 8d5332c8f940, upstream sha 11c8edb

---

Found while systematically testing the amd-skills plugin. Also noting two smaller things in passing, happy to split into separate issues if useful:

• The reference Python launcher in local-ai-app-integration/reference.md hardcodes _wait_for_health(..., timeout_s=30), while Step 7's recovery table says to "Extend timeout to 90s on first launch, 30s after" — the code the skill says to copy verbatim ships the value the table calls wrong for first run. The same launcher uses stdout=subprocess.PIPE with no reader on a long-lived process, which can deadlock once lemond fills the pipe buffer.
• GET /api/v1/models is described as "the only authoritative model list", but on a running server it returns only the installed/suggested subset (13 entries here) versus 211 in server_models.json. Using it to validate a user-supplied model ID, as Step 6 suggests, yields false negatives for any not-yet-pulled model.

[danielholanda]

@iswaryaalex Can you please take a look?