Optimizer loop

Preview Observe → Experiment → Evaluate → Promote or roll back among reviewed choices. Results depend on the evidence available for your workload.

What we optimize (signals)

Signals include cost, reliability, latency/TTFT, tool validity, and application outcomes where you report them via POST /v1/optimizer/outcomes. Placement (region, hardware_class) may appear in Evaluate measurement — that is not hardware-aware scheduling (OPT-6).

Tenant APIs

GET /v1/optimizer/decisions/{decision_id} — explain a decision
GET /v1/optimizer/aggregates — evidence window rollups
GET /v1/optimizer/efficiency-advisor — advisory recommendations; apply only via explicit opt-in
GET /v1/optimizer/workloads/…/proof — evidence-backed proof objects when present; HTTP 200 ≠ quality

Evaluate savings against your own workload, provider mix, quality requirements, and usage data.

Portal

Optimization panel: load efficiency advisor, review recommendation table, optional classify/compress benches that call real tenant endpoints. Routing panel owns decision lookup + exports. Promotion/rollback history stays on control-plane APIs — the UI never invents quality scores from HTTP 200.

OpenAPI operations

Contract: /v1/openapi.json (also GET /v1/openapi.json). Tenant optimizer surfaces documented today:

GET /v1/optimizer/decisions/{decision_id} — explain a decision
GET /v1/optimizer/decisions/{decision_id}/outcomes — list stored outcomes
POST /v1/optimizer/outcomes — report application outcomes (idempotent)
GET /v1/optimizer/aggregates — evidence-window rollups

Efficiency-advisor / workload-proof portal panels may call additional routes; cite OpenAPI for the stable contract. No cookbook farm — use these operations + common OpenAI clients.