Crate tt_routing 

Routing engine — match incoming requests against per-org rules to pick a target model (or pass through unchanged).

Mirrors the shape used by tt-plan-core’s replay-time matcher so a Plan projection and the live Gateway agree on which route would fire for a given request. Differences from plan-core:

• Input is the canonical ChatCompletionRequest + RequestContext (live runtime), not a historical RequestLog.
• Token-count conditions use input_tokens estimated from the request (caller supplies; the engine never tokenizes itself — that’s a hot-path responsibility owned by the caller’s tokenizer cache).

Rules are stored sorted descending by priority. First match wins.

Re-exports

pub use cache::CachingRoutingStore;

pub use store::InMemoryRoutingStore;

pub use store::NewRoute;

pub use store::RoutingStore;

pub use store::RoutingStoreError;

pub use validate::validate_capability;

pub use validate::ValidationError;

Modules

cache

Per-org TTL cache in front of a crate::store::RoutingStore.

store

Where routes come from at runtime.

validate

Typed route validation shared by the gateway routes API. The capability check mirrors the runtime guard (tt_shared::capability_check). Cross- provider rewrites are allowed (V3d-1) — see docs/superpowers/specs/2026-06-04-v3d-1-cross-provider-routing-design.md.

Structs

Route

A single routing rule. When Route::when matches the request, the caller rewrites request.model to [Route::then::target_model] (and may observe the Route::id for telemetry attribution).

RouteAction

What a matching Route does to the request before dispatch.

RouteConditions

Match conditions for a Route. v1 supports four predicates — extend alongside tt_plan_core::types::RouteConditions so Plan and Gateway stay in lockstep.

RoutingEngine

Rule engine. Hold routes sorted by descending priority; iterate to find the first match.