Decide how the USAi catalog represents embedding models (and drop the one that cannot be prompted) #461

Question

The USAi gateway serves both chat models and embedding models from one /v1/models list. The catalog and the per-harness emitters currently treat that list as if every entry were promptable. One entry is not, and it ships today.

Measured facts

Probed against the live gateway (chat endpoint vs embeddings endpoint):

So these are not broken models. They are embedding models, working correctly on the endpoint they belong to, and failing on the one a coding harness calls.

Two consequences:

1. cohere_english_v3 is in the shipped catalog and both shipped opencode.jsonc kits, listed with a limit/cost block as though selectable. Anyone who picks it gets an opaque 403. The earlier read that this was a USAi IAM gap was wrong — the 403 is Bedrock refusing a chat call to an embedding model.
2. text-embedding-005 is absent from the catalog. That absence is currently correct for a chat block, but it is accidental rather than decided: nothing in the pipeline distinguishes model kinds, so the next regeneration could pull it in.

Can a coding harness use an embedding model at all?

For OpenCode, no — not through provider.*.models. Checked the published schema at https://opencode.ai/config.json: the model object accepts cost, limit, modalities, tool_call, reasoning and similar. modalities enumerates text|audio|image|video|pdf — there is no embedding modality, and the string embed does not appear anywhere in the schema. Every model in that block is assumed promptable.

Embeddings are useful to agentic tooling in general — semantic code search, RAG over docs, dedupe — but that is consumed by a separate component calling /v1/embeddings directly, not by the harness's model picker.

Proposal

Near-term, uncontroversial: drop cohere_english_v3 from the catalog's chat models and regenerate both shipped kit configs. It cannot be prompted; listing it only offers a selection that fails. (Already removed from the local workstation config, verified: all 20 remaining models return 200.)

The actual decision — three options:

1. Chat-only catalog. Add an explicit exclusion list or a kind discriminator, and have build-catalog.mjs drop non-chat models with a logged reason. Simplest, and makes the current accidental behaviour intentional. Cost: anyone wanting embeddings gets nothing from this pipeline.
2. Catalog both kinds, emit selectively. Add kind: chat | embedding to the schema; the OpenCode emitter filters to chat; the catalog stays a faithful record of what the gateway serves. Costs a schema version bump and a round-trip test update. Lets a future embeddings consumer read the catalog instead of re-querying.
3. Leave it. Rejected for cohere_english_v3 regardless — shipping an unusable selection is a defect either way.

Worth noting USAi's /v1/models response carries no kind, type, or capability field — only id, created, object: "model", owned_by. So any discriminator is ours to infer (by id pattern or a maintained list), which is exactly the kind of fuzzy mapping the USAi enhancement request already asks them to make unnecessary. That argues for option 1 until the gateway exposes capability metadata.

My lean: option 1 now, with the exclusion recorded as data rather than code, and revisit option 2 when something actually needs embeddings. YAGNI applies — but the cohere_english_v3 removal does not wait on the decision.

Acceptance criteria

• cohere_english_v3 no longer appears as a selectable model in the catalog or either shipped opencode.jsonc
• A decision is recorded (ADR or issue resolution) on whether the catalog represents embedding models
• build-catalog.mjs cannot silently admit a non-chat model into a chat block on the next regeneration
• If any model is excluded, the exclusion names the reason, so it is not mistaken for an oversight and re-added

Observed while fixing the catalog drift check (GSA-TTS/agentic-coding-patterns#459).