Provider-registry migration skips builtin:zai-coding-plan — session resumes fail with "Model creation failed" ("Select a model before continuing")

[Ni7e]

Summary

The provider-registry migration that ships with the CLI records the old provider id builtin:zai-coding-plan as "skipped" instead of remapping it to the new zai provider. Every session whose runtime/model_selection pin still references the skipped id fails on resume with a generic Model creation failed error. On my machine that is 61 sessions, all created before today's update.

Environment

• zcode-app-cli 3.12.3-26, zcode-runtime 0.16.5 (npm package, macOS darwin-arm64)
• Sessions created under the previous CLI (3.11.2-25 runtime) with a pinned model

Reproduction

zcode --mode yolo --resume sess_<id> --prompt "ping"
# ZCode Built-in skipped (not-due)
# Error: Model creation failed (traceId: 5ddbb3d6-4965-4b77-8c79-414c1a5e0691)

The TUI shows the same failure on the first turn of any resumed session (✗ Turn failed · Ctrl+O to expand → Model creation failed).

The CLI log (~/.zcode/cli/log/zcode-*.jsonl) shows the wrapped cause:

{
  "event": "turn.failed",
  "context": { "turnPhase": "model_creation" },
  "error": {
    "message": "Model creation failed",
    "cause": {
      "message": "Select a model before continuing",
      "code": "CONFIGURATION_ERROR"
    }
  }
}

Root cause

~/.zcode/cli/migrations/provider-registry-ce5aea1ef735029c.json:

{
  "schemaVersion": 1,
  "imported": ["bigmodel", "zai"],
  "skipped": ["builtin:zai-coding-plan"],
  "completedAt": "2026-09-18T12:08:39.962Z"
}

The migration imported the new providers but skipped the old builtin:zai-coding-plan id instead of remapping it. Sessions that pinned it are left dangling: at model-creation time the runtime cannot resolve the provider and the turn fails with Select a model before continuing, wrapped in the misleading Model creation failed.

Affected rows: ~/.zcode/cli/db/db.sqlite, table session_entry, type = 'runtime/model_selection' — 61 rows shaped like:

{
  "modelId": "GLM-5.3",
  "providerId": "builtin:zai-coding-plan",
  "thoughtLevel": "high",
  "modelSelection": { "providerId": "account:zai-individual-coding-plan", "modelId": "GLM-5.3" }
}

A session created after the update pins the new shape and works:

{ "modelSelection": { "providerId": "zai", "modelId": "GLM-5.3-Flash", "options": { "reasoningLevel": "max" } } }

Verified fix

Rewriting a stranded row into the new shape immediately unblocks that session — resume completes normally afterwards (tested on a 440k-token session that had failed repeatedly):

{ "modelSelection": { "providerId": "zai", "modelId": "GLM-5.3", "options": { "reasoningLevel": "high" } } }

Suggested fix

1. In the provider-registry migration, remap known-equivalent ids (builtin:zai-coding-plan → zai) instead of skipping them.
2. Ship a follow-up migration that repairs stores which already recorded the skip — i.e. rewrite stale runtime/model_selection entries to the new shape.
3. Defensive layer: when a session's pinned provider id cannot be resolved at model-creation time, fail with a message naming the stale id (and how to re-select) instead of the generic Select a model before continuing wrapper — this class of failure is otherwise undiagnosable from the TUI.

Workaround for affected users

Back up ~/.zcode/cli/db/db.sqlite first, close running sessions, then for each runtime/model_selection row containing builtin:zai-coding-plan, rewrite data to:

{"modelSelection":{"providerId":"zai","modelId":"GLM-5.3","options":{"reasoningLevel":"high"}}}

(keep the row's original modelId and map thoughtLevel → options.reasoningLevel). Alternatively /model + re-pick inside each affected session.

Happy to test a fix build — the failing dataset is still on this machine.

[Ni7e]

Addendum — repairing this locally surfaced a second layer of the same failure, with the identical symptom (Select a model before continuing wrapped in Model creation failed):

2. Model-id casing and retired ids. After the migration, the imported zai provider registers lowercase model slugs (glm-5.3, glm-5.2, …), but pre-update sessions pin canonical-case ids (GLM-5.3). Resolution is case-sensitive, so zai/GLM-5.3 fails while zai/glm-5.3 works — verified by rewriting a row and resuming headless (first attempt errors, lowercase attempt answers normally). Pins to glm-5.1 fail even lowercase: the model is listed in the local provider config but is no longer served by the current plan (it is absent from model-catalog-managed.json's zai/* set).

Local repair numbers from one machine (341 session pins total):

• 61 rows pinned the skipped builtin:zai-coding-plan provider
• 17 rows pinned zai/GLM-5.3 (case mismatch)
• 6 rows pinned zai/glm-5.1 (retired id)

So the suggested follow-up migration should: remap skipped provider ids, normalize modelId casing against each provider's registered model list, and rewrite pins whose model is no longer served to the account default. All three produce the identical generic error today, which makes them indistinguishable from the TUI.

[kingsword09]

The recovery fix is implemented in #161. The behavior is now:

• Interactive resume: An invalid saved selection immediately opens a model picker showing the affected
  model and the reason. Selecting a replacement saves it for that session. Cancelling preserves the
  saved selection and prevents prompts from being submitted with an invalid model.

• Headless resume: An invalid selection exits with code 1, identifies the problem, and provides
  recovery instructions. It does not open a picker, send a model request, or silently switch models.
  After selecting a replacement once interactively, subsequent headless resumes use that saved
  selection.

• Persistence: No manual SQLite editing is required. The replacement is saved through the runtime’s
  normal session-store API, without changing the shared default or conversation history.

This fix does not introduce a bulk rewrite of existing sessions. A blanket builtin/account → zai
mapping or lowercase conversion is not valid for every configuration, and replacing an unavailable
model requires a user choice. Existing upstream migrations remain in place; the new recovery path
handles selections that are still invalid afterward.

All CI checks pass, and the commit preview is published:

  npx --yes https://pkg.pr.new/zcode-app-cli@9951c7e --resume SESSION_ID

Please test an affected session that has not already been manually repaired. Confirm that the picker
appears immediately, the selected model can continue the conversation, and the selection survives
another restart. Then verify headless resume:

  npx --yes https://pkg.pr.new/zcode-app-cli@9951c7e --resume SESSION_ID --prompt "ping"

The implementation is complete; the remaining verification is against your original affected sessions.