Budibase/budibase · error · HTTPError

No available LLM configurations

Error message

No available LLM configurations

What it means

getDefaultLLMOrThrow resolves the workspace's default LLM configuration; if getDefaultLLM finds none (no LLM configs exist, none are enabled, or none match the requested options), it throws HTTPError 500 "No available LLM configurations". It is the guard used by chat, providerOptions and llm so callers fail fast when the workspace has no usable AI provider.

Source

Thrown at packages/server/src/sdk/workspace/ai/llm/utils.ts:117

  const llm = await createLLM(configToUse._id)

  if (
    !llm ||
    !options?.reasoningEffort ||
    !(await supportsReasoningEffort(configToUse))
  ) {
    return llm
  }
  return applyReasoningEffort(llm, options.reasoningEffort)
}

export async function getDefaultLLMOrThrow(
  options?: GetDefaultLLMOptions
): Promise<LLMResponse> {
  const llm = await getDefaultLLM(options)
  if (!llm) {
    throw new HTTPError("No available LLM configurations", 500)
  }
  return llm
}

View on GitHub (pinned to a81a902e9a)

Solutions

1. Create an LLM/AI configuration for the workspace in the Budibase admin/settings UI.
2. Verify the existing LLM configuration is enabled and points at a reachable provider with valid credentials.
3. Check self-hosted env vars for the AI proxy (Budibase AI) are set and the service is reachable.
4. If calling getDefaultLLMOrThrow directly, catch the HTTPError and fall back to an explicit LLM config.

Example fix

// before
const llm = await getDefaultLLMOrThrow()
// after
let llm
try {
  llm = await getDefaultLLMOrThrow()
} catch (e) {
  llm = await getLLM({ provider: "openai", credentials })
}

const configs = await getLLMConfigs(workspaceId) // or inspect admin state
if (!configs || configs.filter(c => c.enabled).length === 0) {
  throw new Error("Workspace has no enabled LLM configuration")
}

null

try {
  const llm = await getDefaultLLMOrThrow(options)
} catch (e) {
  if (e instanceof HTTPError && e.status === 500 && e.message === "No available LLM configurations") {
    // fall back to an explicitly configured provider or disable AI features
  }
  throw e
}

When it happens

Trigger: Calling chat/providerOptions/llm helpers (or getDefaultLLMOrThrow directly) in a workspace that has zero LLM configurations, all configurations disabled, or none matching the options filter (e.g. specific provider requested).

Common situations: Fresh/self-hosted Budibase install where no AI/LLM config was created; AI config deleted or disabled by an admin; self-hosted environment without Budibase AI proxy credentials; environment variable for the AI service missing.

Related errors

• LLM not available
• Failed to create operation file storage
• Workspace DB not found - self-host users using cloud don't h
• CouchDB username not set
• CouchDB password not set

AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29). Data as JSON: /api/errors/b16797d46875649e. Report an issue: GitHub.