Remove provider from chat_model_configs (CODAGT-599)

Direction (approval surface)

Outcome

The denormalized provider string is gone from Agents storage. Provider
identity for a model config has a single source of truth: the ai_providers
row reached through chat_model_configs.ai_provider_id. Every surface that
still needs a provider type derives it from ai_providers.type instead of
reading a stored copy.

Observable end state

• chat_model_configs has no provider column, and no idx_chat_model_configs_provider
  or idx_chat_model_configs_provider_model index.
• The experimental HTTP/SDK ChatModelConfig response has no provider field.
  Consumers resolve provider type from ai_provider_id plus
  GET /api/experimental/chats/providers (id -> provider type).
• The Agents web UI selects icons, groups, sorts, and resolves legacy model
  references using the provider type derived from ai_provider_id, not a stored
  provider string.
• Telemetry still emits provider for each model config, now computed from
  ai_providers.type at snapshot time. The BigQuery chat_model_configs.provider
  column and the Nexus dashboards that read it keep working unchanged.
• The startup backfill BackfillChatModelConfigProviderStrings and the unused
  DeleteChatModelConfigsByProvider query are deleted. BackfillBedrockProviderType
  remains.
• The API/SDK response makes ai_provider_id a required (non-omitempty) field
  for the configs it returns, which are always active, so consumers rely on it
  as the sole provider identity.
• The coder-org repositories that read provider have a notice comment
  describing the removal and the ai_provider_id replacement path.

Recommended direction

Remove the column and every dependence on the stored string in a single
release, treating the change as one coordinated unit across schema, backend,
SDK, and frontend. Keep provider alive only where a consumer has a verified
dependency and no ai_provider_id/type dimension to derive from. That
condition holds for exactly one surface: the telemetry analytics projection.

Reason

Provider type already lives authoritatively in ai_providers.type, reachable
on every active row through ai_provider_id, which the CHECK constraint
chat_model_configs_ai_provider_required_when_active makes mandatory for
non-deleted rows (coderd/database/dump.sql:1927). Routing already prefers
ai_providers.type and reads the stored string only in an
!AIProviderID.Valid branch that the constraint makes unreachable for active
rows (coderd/x/chatd/model_routing_direct.go:85-92, coderd/x/chatd/subagent.go:536-553).
The stored provider is therefore a duplicate the system maintains with a
startup backfill but no longer needs as a source of truth.

The telemetry projection is kept because it is the only provider-identity
dimension in the analytics pipeline: the BigQuery schema bqChatModelConfig
(coder/coder-telemetry-server, convert.go) carries provider but no
ai_provider_id or type, and Nexus queries read coder-telemetry.coder.chat_model_configs.provider
directly (coder/nexus, util/sql/coder_agents_provider_trends.sql and four
sibling queries). Deriving that field from ai_providers.type preserves the
analytics contract while removing the stored duplication, so the projection is
computed from the source of truth rather than a denormalized copy.

High-level shape

1. Backend stops reading the column: derive provider type from the loaded
   ai_providers row at each read site, retarget ORDER BY provider, and
   source the telemetry provider from a JOIN.
2. SDK drops the response field; regenerate codersdk and the TypeScript
   types.
3. Frontend moves icon, grouping, sort, and legacy-reference logic onto
   ai_provider_id, including fixtures and stories.
4. A numbered migration drops the column and its indexes.
5. Delete the obsolete backfill and the dead delete query, regenerate database
   code.
6. Post a notice comment on the coder-org repositories that read the field.

Ruled-out directions

• Two-step expand/contract (stop reads in release N, drop column in N+1).
  Ruled out by operator decision to ship in one release on the assumption of
  scale-to-zero cutovers. Recorded as a risk below, since production reads the
  column through SELECT * positional scans, so a running pre-drop binary
  fails those scans the instant the column disappears.
• Keep the column, only stop depending on it. Ruled out: it does not
  satisfy the issue goal and leaves a dead column plus an obsolete backfill in
  place.
• Keep a derived provider in the HTTP/SDK response. Ruled out by operator
  decision. coder-mobile-android is not an officially supported project, so
  its dependence does not justify retaining the API field; it gets a notice
  comment instead.
• Drop provider from telemetry too and migrate the analytics pipeline.
  Ruled out by operator decision (kept derived). It would require coordinated
  changes in coder-telemetry-server (BigQuery schema) and nexus (five SQL
  queries) plus a story for historical BigQuery rows that only have provider.

Decisions already made

• Single release, relying on scale-to-zero upgrade cutovers.
• No compatibility guarantees during the migration window. Operators must scale
  to zero before upgrading. This is the accepted upgrade contract for the
  change.
• ai_provider_id becomes a required (non-omitempty) field in the API/SDK and
  TypeScript response, since those endpoints return only active configs and
  active configs always have it.
• API/SDK provider field is removed end-to-end; consumers migrate to
  ai_provider_id + the providers endpoint.
• Frontend migrates onto ai_provider_id end-to-end.
• Telemetry keeps provider, sourced from ai_providers.type.
• External coder-org consumers get at most a notice comment, not code changes
  or a coordinated release.

Assumptions

• Every active (non-deleted) chat_model_configs row has a non-null
  ai_provider_id. Verified at the database level: the CHECK constraint
  chat_model_configs_ai_provider_required_when_active was added without
  NOT VALID (migration 000505), so Postgres validated existing rows on add
  and the migration could not have succeeded with a non-conforming active row.
  The single production insert path also requires it (coderd/exp_chats.go:6920-6923),
  the update path never nulls it (coderd/exp_chats.go:7140-7162), and the FK
  has no ON DELETE SET NULL while ai_providers soft-deletes
  (coderd/database/dump.sql:5004). Soft-deleted rows may have null
  ai_provider_id but are never returned by the model-config endpoints.
• No persisted model reference uses a provider:model string. Verified:
  chats.last_model_config_id is a uuid column (coderd/database/models.go:4786,
  @last_model_config_id::uuid; TS typesGenerated.ts:1563) resolved as a UUID
  (coderd/x/chatd/chatd.go:4425-4442), and ModelSelectorOption.id is always
  the config UUID. The frontend provider:model matching is dead and is removed
  in Part 4, not preserved.
• A consumer can recover provider type from ai_provider_id. Verified:
  GET /api/experimental/chats/providers returns ChatProviderConfig{ID, Provider}
  where Provider is the type (codersdk/chats.go:1167-1180).

Constraints

• The drop is plain DDL and belongs in a numbered migration. The
  startup-backfill approach used by PR fix: backfill legacy Bedrock AI provider rows and stale model config strings #26155 was specific to reading
  dbcrypt-encrypted settings and does not apply here.
• The experimental API carries no stability guarantee
  (coderd/coderd.go:1192), which is what makes the field removal acceptable.

Tradeoffs

• Telemetry and the stored column diverge in treatment: telemetry keeps a
  derived provider, the API does not. This is intentional. Telemetry has a
  downstream consumer with no alternative dimension and both ends are owned
  internally; the API has a documented alternative (ai_provider_id + providers
  endpoint).

Risks affecting the direction

• Rolling-upgrade skew (accepted). Production reads provider via
  SELECT *, so a pre-drop replica still serving during a rolling upgrade would
  fail config reads once the column is gone. Accepted: the change provides no
  compatibility guarantees during migration and requires operators to scale to
  zero before upgrading. Coder does not support rollbacks
  (docs/install/upgrade.md). This is a documented operating contract, not an
  open mitigation.
• Frontend rows without ai_provider_id. Today the TypeScript type marks it
  optional and fixtures omit it. Making the response field required removes the
  runtime case for active configs (backend invariants guarantee the FK), so the
  residual work is mechanical: update fixtures and stories that omit it and
  remove the now-dead optional-handling branches rather than leaving them to
  silently fall back to a removed field.

Deferred decisions

• Whether to tighten ai_provider_id to strictly NOT NULL (dropping the
  deleted = TRUE OR ... exemption). Out of scope here; soft-deleted rows
  legitimately hold null.
• Whether to later migrate the telemetry/Nexus pipeline off the provider
  string onto a provider-type dimension. Deferred; not required by this change.

Implementation detail (preserves the approved direction)

Line numbers are anchors as of the researched revision and will drift; the named
symbols (functions, queries, struct fields) are authoritative. Grep the symbol
if a line number no longer matches.

Part 1: backend stops reading the column

Replace each read of the stored Provider with the provider type from the
loaded ai_providers row.

• Routing fallbacks: coderd/x/chatd/model_routing_direct.go:84-92 and
  coderd/x/chatd/subagent.go:172-190,553. In the !AIProviderID.Valid branch,
  return sql.ErrNoRows (the signal these call sites already treat as "no
  usable model config") instead of reading the stored string. Active rows always
  have the FK, so the branch is unreachable for them.
• Prompt build: coderd/x/chatd/generation_preparer.go:263 (chatFileResolver)
  takes the resolved provider type from the route loaded for the call,
  string(route.Provider.Type).
• Logging and debug-run records in coderd/x/chatd/chatd.go, two treatments:
  • Persisted debug-run provenance writes to chat_debug_runs.provider, a
    separate column kept by this change. Set it from string(route.Provider.Type)
    at the WrapModel RecorderOptions.Provider site (:2622) and the
    CreateRun Provider site (:2653), where route is resolved in scope.
  • Pure log fields slog.F("provider", ...) (:2608,2615,2665,2791,2806) sit
    in failure branches where no route resolved: delete the field.
• Listing/availability: coderd/exp_chats.go:889-917 builds ConfiguredModel.Provider;
  source it from ai_providers.type. This requires GetEnabledChatModelConfigs
  to return ap.type (it already JOINs ai_providers,
  coderd/database/queries/chatmodelconfigs.sql:37-38).
• Cost breakdown: coderd/exp_chats.go:6533 from GetChatCostPerModel
  (coderd/database/queries/chats.sql). This query joins chat_model_configs
  without a deleted = FALSE filter, so it can reference soft-deleted configs
  that may carry a null ai_provider_id. Use LEFT JOIN ai_providers ap ON ap.id = cmc.ai_provider_id (no ap.deleted filter, so soft-deleted providers
  still resolve) and select COALESCE(ap.type::text, '') AS provider. Drop
  cmc.provider from the SELECT and the GROUP BY.
• Retarget the two ORDER BY provider clauses
  (coderd/database/queries/chatmodelconfigs.sql:27,45) to ap.type (and
  model).

Part 2: telemetry keeps provider, derived

• Change GetChatModelConfigsForTelemetry (coderd/database/queries/chats.sql,
  currently SELECT id, provider, model, ... WHERE deleted = false) to
  JOIN ai_providers ap ON ap.id = cmc.ai_provider_id and select
  ap.type AS provider. The query already filters deleted = false, so every
  row has a non-null ai_provider_id; a plain INNER JOIN is correct and no
  coalesce is needed.
• coderd/telemetry/telemetry.go:2304 and the struct field :2475 keep their
  shape. bqChatModelConfig and Nexus SQL need no change.

Part 3: SDK drops the field

• Remove the Provider field from codersdk.ChatModelConfig
  (codersdk/chats.go:1248-1262) and from convertChatModelConfig
  (coderd/exp_chats.go:7505).
• Remove the Provider field from CreateChatModelConfigRequest and
  UpdateChatModelConfigRequest (both define it, codersdk/chats.go) and the
  provider-string handling in the handlers: delete the legacy branch at
  coderd/exp_chats.go:7128-7137 (the "AI provider ID is required when updating
  provider" path) and the insert/update param wiring at
  coderd/exp_chats.go:6997,7220,7429. Leave the request AIProviderID fields
  as optional pointers: create validates presence at runtime
  (coderd/exp_chats.go:6920-6923), update omits it to keep the existing value.
  Only the response field changes shape.
• Make ai_provider_id required: change codersdk.ChatModelConfig.AIProviderID
  from *uuid.UUID with omitempty (codersdk/chats.go:1251) to a non-pointer
  uuid.UUID. The list and get endpoints return only deleted = FALSE configs,
  which always carry the FK, so the field is never absent in responses.
  convertChatModelConfig (coderd/exp_chats.go:7498) is the only construction
  site; it assigns config.AIProviderID.UUID directly and relies on the CHECK
  constraint, with no runtime null-handling. The invariant is covered by a test,
  not by a defensive branch.
• Run make gen to regenerate codersdk consumers and the TypeScript types:
  provider leaves ChatModelConfig,
  CreateChatModelConfigRequest, UpdateChatModelConfigRequest, and
  ai_provider_id becomes required (ai_provider_id: string)
  (site/src/api/typesGenerated.ts:2488,2489,3502,8890).

Part 4: frontend moves onto ai_provider_id

Introduce one provider-type lookup and use it everywhere a provider type is
needed; do not read config.provider anywhere. Build
providerTypeByID: ReadonlyMap<string, string> from chatProviderConfigs()
(site/src/api/queries/chats.ts:1847-1853), mapping ChatProviderConfig.id to
ChatProviderConfig.provider. Each site below resolves the provider type as
providerTypeByID.get(config.ai_provider_id) and receives the map as a prop or
argument from the page that already loads the providers query.

• Icon reads ModelRow.tsx:39 and UserCompactionThresholdSettings.tsx:285.
  UserCompactionThresholdSettings gains a providerTypeByID prop sourced by
  its parent page from chatProviderConfigs(). Replace
  provider={modelConfig.provider} with
  provider={providerTypeByID.get(modelConfig.ai_provider_id)}.
• Model selector options: add a providerTypeByID parameter to
  getModelOptionsFromConfigs (modelOptions.ts:73,185,197,205) and set
  ModelSelectorOption.provider from the map; callers pass the map. Update the
  grouping and labels in ModelSelector.tsx:83,88,127,129 and the option built
  in SubagentModelOverrideSettings.tsx:48 to use the same value.
• Sort key ModelsPage.tsx:24 sorts by the mapped provider type.
• Legacy reference shim: delete the dead provider:model matching in
  modelDisplayName.ts:29,42,48 and chatHelpers.ts:84,101, and the .provider
  reads that feed it. It cannot match real data: getModelOptionsFromConfigs
  always sets ModelSelectorOption.id to the config UUID, and
  Chat.last_model_config_id is a uuid string (typesGenerated.ts:1563).
• Delete the provider-string fallback branches in
  providerStates.ts:124-133,224-236 and AgentSettingsAPIKeysPageView.tsx:91-95;
  they are dead once ai_provider_id is required.
• Stop sending provider in ModelForm.tsx:155,184; send only ai_provider_id.
• Update every fixture and story that sets provider or omits ai_provider_id
  on a ChatModelConfig: testHelpers/chatModels.ts and
  ModelsPage/testFixtures.ts, plus the stories the TypeScript compiler flags
  once ai_provider_id is required (the required field turns every omission
  into a compile error, so the compiler enumerates them). For each, add
  ai_provider_id and remove provider.

Part 5: schema migration

• New numbered migration up: DROP INDEX idx_chat_model_configs_provider,
  idx_chat_model_configs_provider_model; then ALTER TABLE chat_model_configs DROP COLUMN provider.
• Paired .down.sql must restore the original schema exactly, since the
  migration test runs up then down: ADD COLUMN provider text; backfill
  UPDATE chat_model_configs cmc SET provider = ap.type FROM ai_providers ap WHERE ap.id = cmc.ai_provider_id; set provider = '' for any rows still null
  after the backfill (soft-deleted, unlinked); ALTER COLUMN provider SET NOT NULL; recreate both indexes.
• Update coderd/database/dump.sql and the migration test fixtures via
  make gen.

Part 6: remove obsolete code

• Delete BackfillChatModelConfigProviderStrings (coderd/ai_providers_backfill.go:74-95)
  and its startup call (cli/server.go:1119-1122). Keep BackfillBedrockProviderType.
• Delete the BackfillChatModelConfigProvider query
  (coderd/database/queries/chatmodelconfigs.sql:147-166) and the unused
  DeleteChatModelConfigsByProvider (:136-145); DeleteChatModelConfigsByAIProviderID
  (:168) covers provider-scoped deletion.
• Remove Provider from database.ChatModelConfig and regenerate
  queries.sql.go, querier.go, dbauthz, dbmetrics, dbmock. Remove the
  dead-query plumbing and its dbauthz_test.go case. No audit-table entry
  exists for chat_model_configs.

Part 7: external consumers (coder org)

• Post a notice comment on the coder-org repositories that read the field,
  describing the removal and the replacement path (ai_provider_id plus
  GET /api/experimental/chats/providers, mapping id -> provider type):
  coder/coder-mobile-android (ChatModelConfigDto.provider),
  coder/demo-aigov-rhaiis-rhsummit-2026, coder/usgov-coderdemo,
  coder/pixel-playground.
• No code changes or release coordination are owed to these repositories.

Ordering and dependencies

Parts 1, 2, and 3 must land before Part 5; the column cannot drop while code
still scans it. Part 4 depends on Part 3 (regenerated types). Part 6 deletes
code only after Part 1 removes the last reader. Part 7 is independent and can
proceed in parallel.

Verification

• Before writing the migration, grep coderd/database/dump.sql for any view or
  trigger referencing chat_model_configs.provider; precedent column drops had
  to rebuild dependent views. None is expected (the relevant SQL are queries,
  not views), but confirm.
• make gen, make lint, make test for backend and generated code.
• Frontend: Storybook stories for the model selector, model rows, and settings
  pages exercise icon, grouping, sort, and legacy-reference behavior without the
  provider field.
• Confirm the telemetry snapshot still produces a provider value after the
  JOIN change; the query returns only active rows. Confirm the cost breakdown
  still returns a row for messages whose model config was later soft-deleted.

Invariants

• Active chat_model_configs rows always have a resolvable ai_provider_id;
  provider type is read from ai_providers.type, never from a stored copy.
• The telemetry provider value equals the linked provider's type. The cost
  breakdown tolerates soft-deleted configs with a null ai_provider_id by
  emitting an empty provider rather than dropping the row.
• No code path scans a provider column from chat_model_configs after the
  migration.
• Every ChatModelConfig the API returns carries a non-null ai_provider_id,
  because those endpoints return only active configs. This holds only while no
  endpoint returns soft-deleted configs and the
  chat_model_configs_ai_provider_required_when_active CHECK stays in place;
  both are load-bearing for the required-field contract.

References

• Schema and constraint: coderd/database/dump.sql:1910-1930,4628,4630;
  migrations 000503-000505 (PRs feat: add AI provider schema expansion #25412, feat: remove legacy chat provider tables #25416).
• Backfills: coderd/ai_providers_backfill.go; cli/server.go:1119-1122
  (PR fix: backfill legacy Bedrock AI provider rows and stale model config strings #26155 added the startup backfills only).
• Telemetry pipeline: coderd/telemetry/telemetry.go:2304,2475;
  coder/coder-telemetry-server convert.go (bqChatModelConfig);
  coder/nexus util/sql/coder_agents_provider_trends.sql and siblings.
• External consumers: coder/coder-mobile-android AgentDtos.kt
  (ChatModelConfigDto); coder/demo-aigov-rhaiis-rhsummit-2026
services/bridge/internal/coder/coder.go.
• Originating discussion: PR fix: backfill legacy Bedrock AI provider rows and stale model config strings #26155 thread r3386858811.