What causes "Image generation not supported by the model yet" in conductor-oss/conductor?

Switch the image-generation task's llmProvider to a provider that implements a real ImageModel: openai, gemini, azureopenai, bedrock, stabilityai, or cohere.

conductor-oss/conductor · error · UnsupportedOperationException

Image generation not supported by the model yet

Error message

Image generation not supported by the model yet

What it means

Grok.java throws UnsupportedOperationException from getImageModel() because the xAI Grok provider has no image-generation API endpoint. The AIModel interface declares getImageModel() as a non-default abstract method (line 141), so every provider must implement it — Grok fulfills the contract by throwing. LLMHelper.generateImage() calls llm.getImageModel() unconditionally at line 155, so routing an image task to grok crashes.

Source

Thrown at ai/src/main/java/org/conductoross/conductor/ai/providers/grok/Grok.java:93

                .topP(input.getTopP())
                .maxTokens(input.getMaxTokens())
                .stopSequences(input.getStopWords())
                .frequencyPenalty(input.getFrequencyPenalty())
                .presencePenalty(input.getPresencePenalty())
                .toolCallbacks(toolCallbacks)
                .toolNames(toolNames)
                .internalToolExecutionEnabled(false)
                .build();
    }

    @Override
    public ChatModel getChatModel() {
        return this.chatModel;
    }

    @Override
    public ImageModel getImageModel() {
        throw new UnsupportedOperationException("Image generation not supported by the model yet");
    }
}

View on GitHub (pinned to cf7c3e4a8a)

Solutions

Switch the image-generation task's llmProvider to a provider that implements a real ImageModel: openai, gemini, azureopenai, bedrock, stabilityai, or cohere.
Split the workflow into two tasks: use grok for chat/text and a different provider for image generation.
Contribute a GrokImageModel adapter once xAI ships a stable image-generation endpoint.

Example fix

// before (workflow task input)
{"llmProvider": "grok", "model": "grok-2-vision", "prompt": "a cat"}
// after
{"llmProvider": "openai", "model": "dall-e-3", "prompt": "a cat"}

Defensive patterns

Strategy: validation

Validate before calling

// Check provider name against known image-capable providers before calling getImageModel()
private static final Set<String> IMAGE_CAPABLE = Set.of(
    "openai", "gemini", "azureopenai", "bedrock", "stabilityai", "cohere");

String provider = request.getLlmProvider();
if (!IMAGE_CAPABLE.contains(provider)) {
    throw new IllegalArgumentException(
        "Provider '" + provider + "' does not support image generation. " +
        "Supported: " + IMAGE_CAPABLE);
}
ImageModel model = llm.getImageModel();

Type guard

null

Try / catch

try {
    ImageModel model = llm.getImageModel();
} catch (UnsupportedOperationException e) {
    throw new IllegalArgumentException(
        "Provider '" + providerName + "' does not support image generation: " + e.getMessage(), e);
}

Prevention

Maintain a capability matrix mapping provider names to supported features (chat, image, video, embeddings, speech).
Validate llmProvider against supported capabilities at task-definition time, not at runtime.
Document in workflow definitions which provider each task type requires.

When it happens

Trigger: A Conductor workflow task calls an LLM image-generation worker (e.g. LLMGenerateImage) with llmProvider set to "grok". LLMHelper.generateImage() invokes llm.getImageModel() and the Grok provider throws immediately — no network call is ever made.

Common situations: Pointing an image-generation task at a chat-only provider; confusing grok-2-vision (vision input) with image output; copying a chat-completion provider config and reusing it for an image task without checking capability support.

Related errors

AI-assisted analysis of conductor-oss/conductor@cf7c3e4a8a (2026-08-14). Data as JSON: /api/errors/2ecf0729414c8ba6. Report an issue: GitHub.