Current customer API
The published model settings contract documents three current operations:get-model-settings, update-model-settings, and
list-tied-hosted-models. They share the account-scoped
/api/v1/accounts/{account_id}/model_settings resource. The authenticated URL
account member must have the model_settings feature enabled and be an
administrator. The account is resolved from the authenticated membership, and
reads and writes are scoped to that account.
The settings read returns the effective routing profile, plan tier, lock version,
profile catalogue, and Tied-managed override role names. The hosted catalogue is
filtered by the account’s server-derived plan tier. The profile update accepts
only top-level profile and lock_version, persists the profile and audit event
atomically, and refuses stale versions, invalid or unavailable profiles, and
customer changes to a staff-pinned profile. It does not accept provider keys or
per-job model selections. The existing contract and its tests establish these
behaviors; they do not establish any key-management or per-job customer endpoint.
Staff roster pins and internal provider-key storage are separate implementation
surfaces. Their existence does not provide customer Studio routes or authorize
customer API exposure. Current model settings responses include no provider
credential, key reference, model override selection, key prefix, or digest.
Requested actions with no current customer operation
Every row below was checked against the routes and OpenAPI at source revision637fcc97d3e471e82b0b630161fd75b680c4ed22 on 2026-10-22. ENG-5876 owns the
missing runtime behavior and I-30 reconciliation. These entries are proposals,
not an operational register or harness debt. No path, operation ID, scope, or
runtime behavior is approved by this inventory.
The profile and job-model floor decision for future behavior is: Tied-paid jobs
are locked; customer-paid jobs may raise the model; nobody may lower a floor.
A future implementation must enforce this with server-side plan-tier checks.
This is a decided future rule, not evidence of current per-job enforcement;
ENG-4912 owns floor enforcement; ENG-5891 owns agent model-override behavior.
Exposure and event decisions remain open
For every missing action,callable_route and operation_id are null,
approved is false, and scopes and events remain pending review. SDK exposure is
excluded. MCP stays hidden for all key actions. Per-job reads are visibility
candidates only and need explicit approval under P4 scope review and P9
external-provider data-flow review. A provider-choice change needs its external
data-flow notice before external clients are allowed.
model_settings.updated and model_key.added, model_key.updated,
model_key.rotated, and model_key.removed are proposed event names only. They
make no delivery, ordering, or payload promise. Any approved design must also
respect I-30 / ENG-5876 reconciliation, ENG-4915 and ENG-4912 model-routing
constraints, I-34 key storage, direct adapter ownership in ENG-5840, and P4/P9
review. The inactive inventory is recorded in
docs/platform-api/proposals/ENG-5860.json; it is not imported into an
operational baseline.