Embeddings

prom.codes uses a single, code-tuned embedding model per workspace, selected for retrieval quality on real code. The model is fixed for the life of a workspace so that every vector lives in the same space.

The managed embedding proxy

Embeddings run through api.prom.codes, authenticated with the PROMETHEUS_API_KEY you mint in the dashboard (/app/api-keys). That one key unlocks managed code embeddings — your raw code never leaves your machine, only the embedding text transits to the proxy, which routes it to the upstream model on your behalf. The upstream provider and model are abstracted: you talk to the proxy, not to any one vendor.

How the default is chosen

The default is whichever model gives the best retrieval quality per unit cost on our internal code benchmark. We measure whether the right code chunk lands inside the top candidates an agent ever sees — that is the number that drives answer quality downstream.

Specific model identifiers are deliberately not published: they shift as providers ship new versions and we re-run the benchmark. The default and any configured alternative are surfaced per tenant in the dashboard.

One model per workspace

Every workspace is pinned to one model. The indexer verifies that the configured model matches the workspace before it writes, so a misconfiguration cannot silently corrupt the index with vectors from the wrong model. Changing the model later is a managed re-embed, not an in-place edit.

Provider flexibility

The embedding layer is provider-agnostic. Behind the proxy, prom.codes can route to a managed provider or to an EU-hosted endpoint we operate ourselves, selected per workspace via Region mode. This stays an implementation detail — your config never changes, and your key keeps working when we swap models.

Region implications

In the default profile the embedding call is the single non-EU hop in an otherwise EU-resident pipeline. The Region mode doc covers how to keep that hop inside the EU.