IDE Surfaces
An IDE Surface aggregates other surfaces (LLM Surfaces and their variant aliases) into a single, governed, per-caller-filtered model menu for IDE AI clients. It is a dispatching front door, not just a list: GET {route}/v1/models returns the caller’s filtered model list, and POST {route}/v1/chat/completions (and other suffixes) dispatches by the request’s model field to the chosen member surface, re-running that member’s full governance under the same caller identity. See IDE Surface → for the conceptual model.
Catalogue configuration
The stored configuration for an IDE Surface.
| Field | What it does |
|---|---|
| LLM Surfaces | The surfaces exposed by this catalogue. Add as many as you need. Order here is a fallback; each member’s explicit order takes precedence when the list is rendered. Labeled LLM Surfaces on the Catalogue panel roster in the dashboard. |
| Client Auth | Optional central client sign-in bootstrap (below). In the dashboard this is edited on the Access Point panel under Publish OAuth Metadata to Caller. Currently exposed only as a reference to an OAuth Identifier profile (see OAuth Identifier ID below); the inline provider/tenant/client/scopes fields have no direct dashboard inputs. |
Catalogue members
Each entry references an LLM Surface, optionally pinned to a variant, plus presentation and per-member gating, turning that surface (or one of its variants) into a single selectable entry in the IDE’s model picker. The mnemonic, display name, and gating here are what a developer actually sees and can be restricted to, independent of how the surface is configured elsewhere.
- Pin a Target Variant when you want the catalogue to expose a specific named variant (say, a canary or a
$high-effort configuration) rather than the surface’s base configuration. - A Mnemonic is worth setting when the derived
{pipe_id}[$alias]model id isn’t the name you want developers to see or type: a short, memorable id instead of an internal surface id, for example. - OAuth Identifier (upstream sign-in) gives this member its own token, distinct from the front-door caller token, for cases where the provider needs one. Microsoft 365 Copilot is the clear example, since it needs a Graph-audience token. Leave it unset to forward the caller’s own front-door token instead.
- A Policy Definition (Model Policy) restricts one specific model in the catalogue to a subset of callers, for example gated to one Entra group, without touching the underlying LLM Surface’s own policy.
Switching either toggle on adds its own chip node to the canvas rather than expanding inline; each chip carries its own field, opened by selecting the chip itself: the Upstream Sign-in chip’s panel holds an OAuth Identifier profile, and the Model Policy chip’s panel holds a Policy Definition.
| Field | What it does |
|---|---|
| LLM Surface | The referenced LLM Surface (pipe) id. Required, non-blank. Labeled LLM Surface in the dashboard’s member panel. |
| Target Variant | Variant alias to expose ({pipe_id}${alias}). Absent exposes the base surface. Labeled Target Variant in the dashboard’s member panel. |
| Mnemonic (model id) | Operator-chosen mnemonic that becomes this entry’s client-facing model id, overriding the derived {pipe_id}[$alias] when set and non-blank. Must be unique across every member. Labeled Mnemonic (model id) in the dashboard’s member panel. |
| Display name in client IDE | Display name shown in the client model picker. Defaults to the mnemonic, then the surface/model name, when omitted. Labeled Display name in client IDE in the dashboard’s member panel. |
| Enabled (published to the IDE model list) | On by default, as a toggle. When off, the entry is withheld from the published list without deleting it from the catalogue. Labeled Enabled (published to the IDE model list) in the dashboard’s member panel. |
| OAuth Identifier | Reference to an OAuth Identifier profile (Credentials store) giving this member its own upstream sign-in token (e.g. a Graph-audience token for Microsoft 365 Copilot), distinct from the front-door token. Absent means the caller’s front-door token is forwarded. Edited behind the member panel’s Upstream sign-in toggle, which opens a chip panel labeled OAuth Identifier. |
| Policy Definition | Id of an IDE-type policy definition evaluated on this specific model, after the front-door gates pass and the member is resolved, under the caller’s front-door identity: a Model Policy. A denial blocks the dispatch with 403; a set-but-uncompiled policy fails closed. Edited behind the member panel’s Enforce an OPA Policy for this LLM surface model route toggle, which opens a chip panel labeled Policy Definition. |
The unique, client-facing model id for a member prefers a trimmed, non-blank Mnemonic; otherwise it is the canonical surface id, or surface id plus variant alias. Reorder members in the client model picker with the ↑/↓ “Move up”/“Move down” buttons on the Catalogue panel’s member roster.
Metadata fields, both editable in the member panel’s Context window (advertised to the IDE) section:
| Field | What it does |
|---|---|
| Max input tokens | Advertised maximum input token count for this member’s model. |
| Max output tokens | Advertised maximum output token count for this member’s model. |
Central client sign-in
This block publishes public (never secret) sign-in identifiers at the surface’s unauthenticated bootstrap endpoint, so an IDE client can acquire a token and discover models from nothing but the Access Point URL, with no prior configuration.
Manage tenant, client, and scopes once in the Credentials store as an OAuth Identifier profile, then reference it here via Publish OAuth Metadata to Caller. This is the only field with a direct dashboard control; the inline Tenant ID/Client ID/Scopes fields exist mainly as a fallback path via the Config tab’s raw JSON.
| Field | What it does | Default |
|---|---|---|
| Provider | Identity provider the client signs in with. Currently only Microsoft Entra ID. No input control in the dashboard; fixed and not directly editable. | Microsoft Entra ID |
| Tenant ID | Directory (tenant) the client targets. No direct input in the dashboard’s Access Point panel. Populated only via the referenced OAuth Identifier profile (see OAuth Identifier ID below) or the Config tab’s raw JSON. | Not set |
| Client ID | Public client app registration the editor uses to request the token. No direct input in the dashboard’s Access Point panel. Populated only via the referenced OAuth Identifier profile or the Config tab’s raw JSON. | Not set |
| Scopes | API scopes the client requests. No direct input in the dashboard’s Access Point panel. Populated only via the referenced OAuth Identifier profile or the Config tab’s raw JSON. | None added |
| Publish OAuth Metadata to Caller | Reference to an OAuth Identifier profile. When set, the profile’s public identifiers are resolved and overlaid onto this block at publish time, so the identifiers are managed once in the Credentials store; the inline fields above act as a fallback. This is the only client sign-in field with a direct dashboard control: a dropdown labeled Publish OAuth Metadata to Caller on the Access Point panel. | Not set |
Validation: the provider must be non-blank; when a profile reference is set, the profile is expected to supply tenant/client/scopes so the inline fields may be blank; otherwise, for the Entra provider, a non-blank tenant ID, client ID, and at least one non-blank scope are all required.
A per-member upstream sign-in slot, synthesized (never authored directly) from a member’s OAuth Identifier reference:
| Field | What it does |
|---|---|
| ID | The deterministic slot id a published model entry references, and the client keys its per-upstream token cache on. |
| Provider | Same meaning as Central client sign-in above, resolved for this member’s own OAuth Identifier profile. |
| Tenant ID | Same meaning as above. |
| Client ID | Same meaning as above. |
| Scopes | Same meaning as above. |
| OAuth Identifier ID | The profile this slot was resolved from. |
Members that share a profile id yield a single deduplicated slot.
Related
- IDE Surface concept: Why an IDE Surface is a dispatching front door rather than a static list.
- Core configuration: The IDE Surface type.
- OPA policies: The IDE front-door policy layer and the per-member Model Policy.
- Providers and Models: Microsoft 365 Copilot provider configuration.
Glad to hear it! Please tell us how we can improve more.
Sorry to hear that. Please tell us how we can improve.
Thank you for sharing your feedback so we can improve your experience.