What causes "Not supported" in conductor-oss/conductor?

Use an embeddings-capable provider (e.g. OpenAI, Voyage, or another provider that implements generateEmbeddings) for embedding steps.

conductor-oss/conductor · error · UnsupportedOperationException

Not supported

Error message

Not supported

What it means

Thrown by Anthropic.generateEmbeddings unconditionally — the Anthropic provider does not implement embeddings (Anthropic offers no embeddings API as of this code), so the method is a hard UnsupportedOperationException stub required by the AI provider interface. It is a capability declaration, not a runtime/conditional failure: calling it always throws.

Source

Thrown at ai/src/main/java/org/conductoross/conductor/ai/providers/anthropic/Anthropic.java:79

    /**
     * Anthropic Claude Sonnet 4.6+ rejects requests whose final message has the {@code assistant}
     * role with {@code 400 "This model does not support assistant message prefill. The conversation
     * must end with a user message."} Earlier Claude models (Sonnet 4.5 and below) silently
     * accepted prefill, which is the only reason {@link
     * org.conductoross.conductor.ai.tasks.mapper.ChatCompleteTaskMapper}'s loop-history
     * auto-injection ever worked on Anthropic — the injected messages arrived as accidental
     * prefill. We declare {@code false} here so the mapper suppresses that injection across all
     * Anthropic models; workflows that need prior-iteration state on an Anthropic loop should
     * template it into the user message via {@code ${...output.result}}.
     */
    @Override
    public boolean supportsAssistantPrefill() {
        return false;
    }

    @Override
    public List<Float> generateEmbeddings(EmbeddingGenRequest embeddingGenRequest) {
        throw new UnsupportedOperationException("Not supported");
    }

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

    @Override
    public ChatOptions getChatOptions(ChatCompletion input) {
        List<Tool> tools = convertTools(input);
        Double temperature = input.getTemperature();
        Integer thinkingBudget = null;

        if (input.getThinkingTokenLimit() > 0) {
            thinkingBudget = input.getThinkingTokenLimit();
            temperature = 1.0; // Thinking mode requires temperature=1
        }

View on GitHub (pinned to cf7c3e4a8a)

Solutions

Use an embeddings-capable provider (e.g. OpenAI, Voyage, or another provider that implements generateEmbeddings) for embedding steps.
Check provider capability before calling — Anthropic explicitly does not support embeddings.
Fix the model/provider routing so embedding requests never reach the Anthropic provider.
If the workflow needs both chat and embeddings, configure separate providers per operation.

Example fix

// before
List<Float> vec = anthropicProvider.generateEmbeddings(req);
// after
if (provider instanceof Anthropic) {
    throw new IllegalStateException("Anthropic does not support embeddings; use an embeddings-capable provider");
}
List<Float> vec = provider.generateEmbeddings(req);

Defensive patterns

Strategy: type-guard

Validate before calling

// Route embedding requests away from Anthropic at config/dispatch time.
if (provider instanceof org.conductoross.conductor.ai.providers.anthropic.Anthropic) {
    throw new IllegalStateException(
        "Anthropic does not provide embeddings; select an embeddings-capable provider");
}
List<Float> vec = provider.generateEmbeddings(req);

Type guard

// Capability guard before calling generateEmbeddings.
boolean supportsEmbeddings(Object provider) {
    return !(provider instanceof org.conductoross.conductor.ai.providers.anthropic.Anthropic);
}

Try / catch

try {
    provider.generateEmbeddings(req);
} catch (UnsupportedOperationException e) {
    if ("Not supported".equals(e.getMessage())) {
        // provider lacks embeddings; reconfigure to an embeddings-capable provider
    }
    throw e;
}

Prevention

Never route embeddings operations to the Anthropic provider.
Check provider type/capability before dispatching embedding requests.
Use distinct providers for chat vs embeddings in mixed workflows.

When it happens

Trigger: Calling generateEmbeddings on an Anthropic-backed AIConfig/AIProvider (e.g. a workflow configured to use an Anthropic model for an embeddings step, or generic code that iterates providers and calls generateEmbeddings without checking capability).

Common situations: Workflow/task configured with an embeddings operation but the selected provider/model is Anthropic; code that assumes every provider supports embeddings; misconfiguration routing an embedding request to the Anthropic provider.

Related errors

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