Mintplex-Labs/anything-llm · critical · Error

Unsupported provider ${JSON.stringify(provider)} for this ta

Error message

Unsupported provider ${JSON.stringify(provider)} for this task.

What it means

Thrown by the LangChain `ChatOpenAI` factory switch in ai-provider.js when the `provider` argument matches no case (openai, azure, anthropic, localai, litellm, foundry, docker-model-runner, lemonade, omlx, etc.). It is a hard `default:` throw with no fallback, so a typo or a slug valid elsewhere in the app but unregistered in this switch lands here. The message echoes `JSON.stringify(provider)` so whitespace and case are visible in the diagnostic.

Source

Thrown at server/utils/agents/aibitat/providers/ai-provider.js:499

        });
      case "lemonade":
        return new ChatOpenAI({
          configuration: {
            baseURL: process.env.LEMONADE_LLM_BASE_PATH,
          },
          apiKey: process.env.LEMONADE_LLM_API_KEY || null,
          ...config,
        });
      case "omlx":
        return new ChatOpenAI({
          configuration: {
            baseURL: parseOMLXBasePath(process.env.OMLX_LLM_BASE_PATH),
          },
          apiKey: process.env.OMLX_LLM_API_KEY || null,
          ...config,
        });
      default:
        throw new Error(
          `Unsupported provider ${JSON.stringify(provider)} for this task.`
        );
    }
  }

  /**
   * Get the context limit for a provider/model combination using static method in AIProvider class.
   * @param {string} provider
   * @param {string} modelName
   * @returns {number}
   */
  static contextLimit(provider = "openai", modelName) {
    if (typeof provider !== "string") {
      console.log(
        `\x1b[43m\x1b[30m[.contextLimit warning] A non-string provider for .contextLimit was given — Returning fallback context limit of 8000.\x1b[0m\n\x1b[43m\x1b[30mThis is a bug and should be reported so that context windows are properly managed by AnythingLLM.\x1b[0m`
      );
      console.trace();
      return 8_000;

View on GitHub (pinned to 526360e320)

Solutions

1. Compare the exact string in the error (it is JSON-stringified, so quotes/case are visible) against the case labels near ai-provider.js:499.
2. Add the missing `case` to the switch if this provider is intended to be supported by this factory.
3. Fix the upstream caller — it may be passing the display name instead of the canonical slug.
4. If the value came from a stored workspace setting, migrate or reset the setting to a known slug.
5. Validate the provider against an allow-list before invoking this factory.

Example fix

// before
async function buildChat(provider, config) {
  switch (provider) {
    // ... existing cases ...
    default:
      throw new Error(`Unsupported provider ${JSON.stringify(provider)} for this task.`);
  }
}

// after — validate at the trust boundary, not inside the factory
const KNOWN = new Set(["openai","azure","anthropic","localai","litellm","foundry","docker-model-runner","lemonade","omlx"]);
function assertKnownProvider(provider) {
  if (!KNOWN.has(provider))
    throw new Error(`Unsupported provider ${JSON.stringify(provider)} for this task.`);
}
// call assertKnownProvider(provider) before buildChat

// Allow-list the provider at the trust boundary, not inside the factory.
const SUPPORTED_PROVIDERS = new Set([
  'openai','azure','anthropic','localai','litellm','foundry',
  'docker-model-runner','lemonade','omlx' /* keep in sync with the switch */
]);
function assertSupportedProvider(provider) {
  if (!SUPPORTED_PROVIDERS.has(provider))
    throw new Error(`Unsupported provider ${JSON.stringify(provider)} for this task.`);
}

function isSupportedProvider(provider) {
  return typeof provider === 'string' && SUPPORTED_PROVIDERS.has(provider);
}

// Validate before constructing; let the error bubble as a 400 to the caller.
assertSupportedProvider(provider);
return buildChat(provider, config);

When it happens

Trigger: Caller passes a provider slug valid for the main provider registry but not wired into this LangChain factory; typo in config/env (e.g. "docke-model-runner"); a custom provider was added to the UI picker but the case here was forgotten; null/undefined provider passed through from an unvalidated API field.

Common situations: New provider added to the picker without a matching case in this factory; a stored workspace setting references a provider the current build does not know (e.g. after a downgrade); provider string sourced from a request body or DB row that was never allow-listed.

Related errors

• No base URL was set.
• Invalid runtime setting: ${key}
• Unknown flow type: ${step.type}
• Unknown provider: ${config.provider}. Please use a valid pro
• ENV: No valid LLM_PROVIDER value found in environment! Using

AI-assisted analysis of Mintplex-Labs/anything-llm@526360e320 (2026-08-13). Data as JSON: /api/errors/1e9cfa288f45b065. Report an issue: GitHub.