Ollama provider: catalog fetch failure leaves models-store.json empty forever — /model lists no Ollama models and no error is surfaced

[grim-susemi]

Summary

For the built-in ollama provider (Ollama Cloud), the model catalog is discovered dynamically via fetchModels (GET https://ollama.com/api/tags + per-model /api/show) and persisted to ~/.omo/models-store.json (or the agent dir equivalent). If the first network refresh never completes successfully, the store stays {} permanently. From then on:

• /model shows no Ollama models at all (the provider's model list is empty).
• Model selectors like ollama/glm-5.2 fail validation (is not a valid or known model selector in fallback-chain validation) because the registry has zero models for the provider.
• No error or warning tells the user that the catalog fetch failed or never ran. The failure is silent and self-perpetuating: startup restores from the (empty) store and, depending on the network policy path, never retries a network refresh.

Environment

• senpi: @code-yeongyu/senpi@2026.8.11-4 (via omo-ai@5.0.0-0.beta.6, OMO native profile)
• pi-ai: @earendil-works/pi-ai@2026.8.11-4
• OS: Windows 11 (win32 x64)
• Auth: ollama API key present in auth.json, and OLLAMA_API_KEY set as a User environment variable
• Ollama Cloud API verified reachable with the same key: GET https://ollama.com/api/tags returns 18 models including glm-5.2

Steps to reproduce

1. Have a valid Ollama Cloud API key configured.
2. Ensure models-store.json is empty ({}) — e.g. after a first run where the catalog refresh was aborted or the network path was not taken.
3. Start a new session.
4. Open /model → no Ollama models listed.
5. Observe models-store.json is still {}; no warning is printed about the missing catalog.

Expected behavior

One of:

• Startup performs (or schedules) one network catalog refresh for configured providers whose store entry is missing/empty, or
• A failed/never-run catalog fetch surfaces a visible warning (e.g. "Ollama catalog unavailable: /model will not list Ollama models"), and/or
• A manual command (/models refresh or similar) re-fetches and persists the catalog.

Actual behavior

The empty store is treated as a valid cached catalog; the provider appears configured (auth OK) but exposes zero models; fallback-chain validation emits misleading "not a valid or known model selector" warnings for perfectly valid selectors like ollama/glm-5.2.

Evidence

Relevant code paths (as shipped in @code-yeongyu/senpi@2026.8.11-4):

• dist/core/model-runtime.js line ~78: modelNetworkEnabled = envValue("OFFLINE") === undefined && options.allowModelNetwork === true; line ~81: refreshFromNetwork = runtime.modelNetworkEnabled && options.allowModelNetwork === true — startup network refresh depends on both flags, and the failure/abort path records nothing user-visible.
• dist/core/models-store.js (FileModelsStore): plain JSON map { [providerId]: { models, checkedAt } } — stays {} if no successful refresh ever writes it.
• node_modules/@earendil-works/pi-ai/dist/providers/ollama.js: fetchOllamaModels requires per-model /api/show; abort/throw paths keep previous in-memory models but write nothing when refreshed.length === 0 or the signal is aborted.
• dist/core/retry-fallback/validate.js: validates selectors against registry.getAll(); with an empty Ollama catalog, ollama/glm-5.2 warns as "not a valid or known model selector".

Manual verification that the catalog itself is fine:

GET https://ollama.com/api/tags  (Bearer $OLLAMA_API_KEY)
→ 18 models: qwen3.5:397b, minimax-m3, deepseek-v4-pro, ..., glm-5.2, glm-5.1, ...

Workaround (user-side)

Populate models-store.json manually with the entry shape senpi writes ({ "ollama": { "models": [...], "checkedAt": <ms epoch> } }), using toOllamaModel's field layout (id, name, api: "openai-completions", provider: "ollama", baseUrl: "https://ollama.com/v1", reasoning, input, zeroed cost, contextWindow, maxTokens: 16384, compat). After this, /model lists Ollama models and ollama/glm-5.2 validates cleanly.

Suggested fix direction

• Treat a missing/empty store entry for a configured provider as "needs refresh" and attempt one network refresh at startup regardless of the cached path, and/or persist fetch errors so the TUI can warn once.
• Optionally include provider-level fetch diagnostics in the fallback-chain validation warning (e.g. "provider ollama has no models — catalog may not have been fetched").