Repository navigation
feat: plugin-registered image models for native image_generate (async providers) #60144
Description
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Native image_generate (2.2.x, experimental.image_generate) only works with type: "image" models from the provider catalog. Providers with a different image API cannot be used: ModelScope, for example, uses an async submit → poll → result flow and cannot be expressed as a catalog image model.
Today the only option is a custom tool plugin. We maintain one, but it has to reimplement progress, polling, notifications, output files and display; the native image tool, job lifecycle and completion notifications cannot be reused.
Proposal: let plugins register an image model/provider for the native tool — model metadata (providerID/modelID, capabilities, variants) plus a generate handler that may return an async job or stream. image_generate keeps owning its schema, permissions, job lifecycle, completion notification, output path and image rendering.
This is an extension point, not a request for the core team to maintain more image providers.
Related: #37713 (image generation domain; the design notes that async job protocols differ across providers), #51802 (plugin provider registration currently does not execute).
Benefit: users can connect free or self-hosted image APIs (ModelScope, ComfyUI, etc.) and still get native progress, notifications and preview.
Activity
opencodejr commentedon Oct 29, 2026
Thanks for the detailed proposal, @MercuryOoO! To restate it: you'd like plugins to be able to register an image model with their own generate handler, which may be an async job or a stream. The native
image_generatetool would then handle the schema, permissions, job lifecycle, completion notice, output path and preview for providers like ModelScope or ComfyUI.Today
image_generateonly takes image models from the provider catalog, which it loads through the model's package, and the plugin API has no hook for supplying a generate handler. So this would need a new plugin API extension point; a standalone plugin can't do it. Maintainers will consider it.Related:
ctx.provider.transformcurrently doesn't runproviders.*are not visible to plugins duringsetup, so one-shotopencode runresolves the model before plugin-registered models exist #57421: plugin-registered models aren't visible early enough for one-shotopencode run