janhq/jan · warning · Error

Catalog not supported for ${provider.provider}

Error message

Catalog not supported for ${provider.provider}

What it means

Thrown by fetchTopRemoteModels when resolveCatalogKind(provider) returns null/undefined, i.e. the provider does not map to a known catalog flavor (openai / gemini / anthropic). The function refuses to guess a catalog format and aborts before any network call (remoteModelCatalog.ts:202).

Source

Thrown at web-app/src/lib/remoteModelCatalog.ts:202

    body = await response.json()
  } catch {
    body = null
  }
  return {
    ok: response.ok,
    status: response.status,
    statusText: response.statusText,
    body,
  }
}

export async function fetchTopRemoteModels(
  provider: ProviderLike,
  fetchImpl: FetchImpl
): Promise<RemoteCatalogModel[]> {
  const kind = resolveCatalogKind(provider)
  if (!kind) {
    throw new Error(`Catalog not supported for ${provider.provider}`)
  }
  if (!provider.base_url) {
    throw new Error('Provider must have base_url configured')
  }

  const keyChain = providerRemoteApiKeyChain(provider)
  const attempts: (string | undefined)[] = keyChain.length > 0 ? keyChain : [undefined]

  let lastStatus = 0
  let lastStatusText = ''
  for (let i = 0; i < attempts.length; i++) {
    const result = await getJson(
      fetchImpl,
      `${provider.base_url}/models`,
      buildHeaders(provider, attempts[i])
    )
    lastStatus = result.status
    lastStatusText = result.statusText

View on GitHub (pinned to fad3f12a14)

Solutions

1. Only call fetchTopRemoteModels for providers resolveCatalogKind recognizes (openai/gemini/anthropic-compatible).
2. If the custom provider speaks the OpenAI /models schema, ensure its api_type or provider name resolves to 'openai' in resolveCatalogKind.
3. Skip the catalog refresh (hide the 'browse models' action) for unsupported providers rather than letting it throw.
4. Extend resolveCatalogKind's whitelist if the provider genuinely supports one of the catalog shapes.

Example fix

// before
const kind = resolveCatalogKind(provider)
if (!kind) throw new Error(`Catalog not supported for ${provider.provider}`)
// after: caller checks capability before calling
if (!supportsRemoteCatalog(provider)) {
  return []  // catalog UI hides itself for this provider
}
return await fetchTopRemoteModels(provider, fetchImpl)

function supportsRemoteCatalog(provider: ProviderLike): boolean {
  return resolveCatalogKind(provider) !== null
}
// before calling fetchTopRemoteModels:
if (!supportsRemoteCatalog(provider)) return []

function isCatalogKind(k: unknown): k is CatalogKind {
  return k === 'openai' || k === 'gemini' || k === 'anthropic'
}

try {
  return await fetchTopRemoteModels(provider, fetchImpl)
} catch (e) {
  if (e instanceof Error && e.message.startsWith('Catalog not supported')) return []
  throw e
}

When it happens

Trigger: Calling fetchTopRemoteModels with a provider whose provider/api_type does not resolve to one of the three supported catalog kinds — e.g. a generic 'openai-compatible' custom provider, a local llamacpp/mlx provider, or a mistral/xai/cohere provider that resolveCatalogKind does not whitelist.

Common situations: User added a custom OpenAI-compatible provider and the catalog refresh tried to list its models; the provider name was renamed/typoed so it no longer matches the whitelist; calling fetchTopRemoteModels on a local engine provider.

Related errors

• Provider must have base_url configured
• Failed to fetch models from ${provider.provider}: ${result.s
• Provider must have base_url configured
• Invalid backend string: ${targetBackendString} supplied to u
• Invalid backend string format: "${targetBackendString}". Exp

AI-assisted analysis of janhq/jan@fad3f12a14 (2026-08-12). Data as JSON: /api/errors/8c462bc14eafe14f. Report an issue: GitHub.