Skip to content
Olivares AI docs

Module X — model & provider management

Module X governs the whole AI model and provider stack — Claude, OpenAI, Gemini and local inference, not just one vendor. It is a Core-layer module that sits on top of the model/provider connectors: it does not re-implement any provider integration nor the inference gateway. What it owns is the governance layer — a versioned catalog, a cross-vendor capability matrix, and named routing policy.

What it is

Section titled “What it is”

The module turns the bare Provider/Model entities that inventory (module I) discovers into a governed catalog. Two halves:

  • A declared reference catalog — a versioned-in-repo, operator-overridable table of model families with their declared API-feature capabilities and list-price defaults. Prices are stamped with the date they were declared (pricing_as_of), are explicitly defaults to verify against each provider’s pricing page, and are never fabricated telemetry. A family with no matching entry stays unpriced rather than getting an invented price.
  • Enrichment of the live estate — the module listens to the cost.sampled stream and enriches the discovered Model/Provider entities with family, context window, modality, per-token pricing and the capability set (the pricing fields inventory defers to it).

The capability vocabulary is one cross-vendor matrix — the full Claude stack (prompt caching, batch, Files, citations, extended thinking, computer use, the memory tool, context management, vision/PDF, structured outputs) plus the analogs each other vendor actually exposes — so the UI renders one matrix and a routing policy can require a capability across vendors. The Claude families are catalogued by family (claude-opus, claude-sonnet, claude-haiku, claude-fable, claude-mythos), with deprecated/legacy versions kept under longer prefixes so current ids resolve to the current price tier.

Its contract & entities

Section titled “Its contract & entities”

Routing is the actuation surface, and it is routing-only:

  • Routing policy is persisted on the core Policy entity (Kind="routing"): named selection / fallback / version-pinning policies (cheapest-first, lowest-latency, capability-ordered, or a pinned model). POST …/routing-policies/{id}/resolve resolves a policy against the governed estate and returns a primary + fallback chain with the reason for the choice. This is read-only: it computes a selection that the connector/gateway then executes — the module performs no inference.
  • API-key / workspace governance is minimal-data metadata only — which agent or team uses which credential, carried as a masked hint, never the secret value.
  • A read-only Anthropic rate-limit inventory (the ceilings a gateway or proxy must keep in sync) is served as a consultable inventory; it is never a control the module mutates, and it degrades to an honest unavailable-with-reason response when the read-only Admin connector is not provisioned.

Catalog and feature reads are not sensitive and are gated at the viewer tier; routing and key-governance mutations are an editor-tier, audited change; the governed-execution path is an admin-tier action distinct from the read-tier resolve. The routes are published in the separate beta module-route reference, not the stable core contract; their field-level shapes live in the product’s typed interfaces.

What it consumes & produces

Section titled “What it consumes & produces”

The module consumes cost.sampled from the event bus to enrich the catalog with real per-token pricing and usage; it does not introduce a new observation type. On the governed-execution path, a successful call would produce a redacted CostSample to FinOps — the model output goes to the caller, but is persisted nowhere here. Money never appears on this surface: no USD amount is returned, only token counts and the target that served.

Section titled “Related”