Skip to content

fix: provide auto fallback when Kiro catalog is missing - #3

Closed
Dipak-Chauhan wants to merge 1 commit into
NachoFLizaur:mainfrom
Dipak-Chauhan:fix/catalogless-model-discovery
Closed

fix: provide auto fallback when Kiro catalog is missing#3
Dipak-Chauhan wants to merge 1 commit into
NachoFLizaur:mainfrom
Dipak-Chauhan:fix/catalogless-model-discovery

Conversation

@Dipak-Chauhan

Copy link
Copy Markdown

Summary

  • replace the empty authenticated Kiro provider stub with a usable kiro/auto fallback
  • keep the fallback credential-gated and preserve explicit Kiro provider config
  • let OpenCode merge the fallback with the complete models.dev Kiro catalog when available
  • update package-contract expectations and documentation for the fallback path

Problem

The live models.dev catalog currently has no kiro entry. With a stored Kiro credential, the existing config hook inserts an empty provider only as a crash guard. OpenCode later removes that provider because it has no models, so opencode models kiro fails with Provider not found: kiro.

This also creates a dependency cycle with the pending models.dev restoration: anomalyco/models.dev#2559

Validation

  • npm run typecheck
  • npm run build
  • npm test -- --run (64 tests passed)
  • catalogless Windows smoke test with OPENCODE_MODELS_PATH unset and this checkout loaded by path:
    • opencode models kiro listed kiro/auto
    • opencode run -m kiro/auto completed through Kiro ACP

The fallback intentionally includes only auto; models.dev remains the source of truth for the complete and fast-changing Kiro model lineup.

@NachoFLizaur

Copy link
Copy Markdown
Owner

Hi @Dipak-Chauhan, thanks for this PR! While the problem you're addressing is real, it's temporary and after some thought I've decided not to add a plugin-side fallback.

The way I designed the model fetching deliberately keeps a single metadata authority: models.dev owns model registration and metadata, the SDK provides runtime availability and reasoning efforts, and the plugin only intersects the two.

Once the models.dev PR that adds the Kiro catalogue lands (which should be soon), this would become stale code that has to be kept in sync with models.dev in case the auto model changes. The way model loading works in opencode right now, config injected by the plugin shadows the matching catalog fields (the ??= guard only protects against user config, not the catalog), so any future change to auto's metadata on models.dev would be silently masked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants