Discussion: revisit dynamic model discovery (closed in #11) given Issue #15

[issmirnov]

This is a discussion issue — not a PR — to gauge appetite before writing code. PR #11 ("Replace hardcoded model list with dynamic config discovery") was closed with the rationale:

I'd rather keep this up-to-date than fetching the models each time from config.toml. This costs tokens & time.

Completely fair call at the time. I'd like to raise two things that have changed since, and propose a different framing that addresses the cost concern.

What's changed

1. Issue #15 documents that the manual update path is leaky. PRs #8 and #10 didn't bump the version, so installed users stayed on stale SKILL.md content even after the changes were merged. I just opened #20 (adding gpt-5.5 + gpt-5.4-mini) and had to bundle three separate version-field bumps to make sure the change actually reaches users — plugin.json, openpackage.yml, and .claude-plugin/marketplace.json were all out of sync. This delivery friction compounds every model release.

2. The Codex CLI now ships a runtime model registry. Since codex-cli ~0.12x, every install caches the canonical model list at ~/.codex/models_cache.json, refreshed from OpenAI's model directory. Each entry includes slug, display_name, visibility, and supported_reasoning_levels. The CLI itself uses this to populate its model picker — so it's already authoritative on every user's machine.

Reframed proposal — hybrid, not all-or-nothing

PR #11's design was "always discover at runtime," which is what triggered the cost objection. A hybrid design keeps the happy path free:

1. Keep the hardcoded list in SKILL.md as the default. No extra tokens or I/O for the common case.
2. Add a single optional discovery step: "If the user references a model not in the list above, or asks 'what models are available?', read ~/.codex/models_cache.json and offer the entries with visibility: 'list'."
3. Add a one-line note that the hardcoded list may lag the CLI, with a pointer to the cache file.

Cost analysis: the discovery step only fires when the hardcoded list is insufficient (rare). The cache file is small (~50KB JSON, ~6 entries). One bash call, parse, present — well under 500 tokens per occurrence. Compare to the lifecycle cost: every model release = one PR + one version-bump PR + waiting for claude plugins update to propagate. That's tens of maintainer minutes per release plus stale-version time for users.

Asking, not proposing code

Before I (or anyone) writes a PR for this, I'd value your read:

• Does this hybrid framing change the calculus, or is the hardcoded-only approach still the preferred design?
• If it could merge, would you want the cache-file path to be configurable, or hardcode ~/.codex/models_cache.json?
• Any other concerns I should design around (Windows path differences, missing-cache fallback, etc.)?

Happy to send a PR if you're open to it, or close this issue and stick with manual updates if you'd rather. Either way, thanks for maintaining the skill — it's genuinely useful.

— filed via Claude Code (Opus 4.7) by @issmirnov

[klaudworks]

@issmirnov what do you think about an automation that just updates the model list in this repo so we don't need to manually update it. No runtime cost for the user and up to date models. Shouldn't be too hard: Just find a source of all models and commit an update to the skill on change.

[issmirnov]

@klaudworks good idea. Had Claude take a stab at this on my fork

Docs: https://github.com/issmirnov/skill-codex/blob/main/docs/auto-update-workflow.md

Sample Update PR: issmirnov#6

If this approach works for you, I can squash this down and send a PR here too. As noted in the docs you'll need to enable Actions workflow access in this repo.

[klaudworks]

@issmirnov thank you!

I did not fully understand yet what stops us from including the spark models. Are these models only available after going through the oauth and not via api key?

if so I'd be fine with just accepting that and updating spark models by hand for now.

Alternative would be to just fetch this web page daily https://developers.openai.com/codex/models, extract the models via a simple llm call and use that.

what do you think?

[issmirnov]

Hi @klaudworks , yes, I believe the spark modesl require an API key, so the update by hand probably is a good move. If this looks good to you, I will open a PR from my fork. Let me know. Thanks!