OpenAI (GPT)

TL;DR

ONGRID_OPENAI_API_KEY=sk-...
ONGRID_OPENAI_MODEL=gpt-5.4                 # default
ONGRID_OPENAI_BASE_URL=                     # optional; OpenAI-compatible relay

Provider id: openai. SDK adapter: OpenAI Chat Completions (eino-openai client).

OpenAI is the legacy default — older Ongrid deployments came with gpt-4o baked in as cfg.OpenAI.Model (a top-level struct field, not under cfg.LLM). The current code keeps the top-level field for backward compat:

// internal/pkg/config/config.go:36
type Config struct {
    OpenAI         OpenAIConfig
    LLM            LLMConfig
    // ...
}

A fresh install reads ONGRID_OPENAI_API_KEY from this legacy path; an operator edit in /settings/llm writes the new system_settings.llm.openai_* rows. The resolver checks both, with the per-provider rows winning.

Env vars

Var	Default	Notes
ONGRID_OPENAI_API_KEY	—	Empty = provider dropped from the catalog
ONGRID_OPENAI_MODEL	gpt-5.4	Legacy single-model knob; honoured as the default model when openai_default_model row is empty
ONGRID_OPENAI_BASE_URL	https://api.openai.com/v1	Override for Azure / OpenAI-compatible relays

The "default model" trip-wire

There are TWO model-related settings keys for OpenAI:

• openai_model — the legacy single-model row. Predates the per-provider expansion.
• openai_default_model — the new "default model in the catalog" row, matches what every other provider uses.

The resolver tries the new row first, then falls back to the legacy key, then to env:

// internal/manager/biz/setting/llm.go:181
defaultModel, _, _ := r.svc.Get(ctx, model.CategoryLLM, pk.defaultModel)
if defaultModel == "" && pk.legacyModelKey != "" {
    legacy, _, _ := r.svc.Get(ctx, model.CategoryLLM, pk.legacyModelKey)
    defaultModel = strings.TrimSpace(legacy)
}

This is why an admin who wrote to openai_model in 2025 doesn't lose their default after a 2026 upgrade — the read path still honours it.

Default catalog

The out-of-box model picker shows three GPT models — wired in cmd/ongrid/main.go:499:

Models: dedupeModels(firstNonEmpty(cfg.OpenAI.Model, "gpt-5.4"),
    "gpt-5.5", "gpt-5.4", "gpt-5.4-mini"),

dedupeModels heals deployments that ended up with the configured default duplicated in the list (the gpt-5.4 / gpt-5.4 bug that hit some 2026-05 installs).

BaseURL override

OpenAI-compatible relays (Azure OpenAI, OpenRouter, local llama.cpp's --api mode, vLLM) all work — set ONGRID_OPENAI_BASE_URL to the relay's /v1-rooted base.

# Azure OpenAI
ONGRID_OPENAI_BASE_URL=https://<resource>.openai.azure.com/openai/deployments/<deployment>

# OpenRouter
ONGRID_OPENAI_BASE_URL=https://openrouter.ai/api/v1

# Local vLLM
ONGRID_OPENAI_BASE_URL=http://localhost:8000/v1

Use Custom for non-Azure relays you also use

alongside real OpenAI The single ONGRID_OPENAI_BASE_URL knob means you can't run OpenAI AND an OpenAI-compatible relay simultaneously through the openai provider slot. Use Custom for the relay instead — it's a parallel slot specifically for this.

Making OpenAI the default

ONGRID_LLM_DEFAULT_PROVIDER=openai

Or /settings/llm → Default provider.

Quirks

• Function calling — flat tool_calls array on assistant messages. The Ongrid tool dispatcher expects this shape; adapters for other providers translate to it.
• Streaming — OpenAI's data: [DONE] sentinel is consumed by the eino adapter; you get a single *schema.Message from Generate or an eino StreamReader from Stream regardless of provider.

See also

• Custom (OpenAI-compatible) — the second OpenAI-style slot for relays / local servers.
• Models overview — provider catalog assembly.
• Routing — WithProvider("openai").