A common entry point for model calls.
We are exploring a model gateway for provider configuration, routing, caching, and usage controls. The goal is to make model access easier to manage while keeping provider behavior and costs visible.
Scope is subject to change. No public release or API is announced.
Model access with policies you can inspect.
The concept puts routing and usage policy in one place. Teams could choose provider credentials, permitted models, and how to handle failures. Provider coverage, cache behavior, and budget enforcement are still being designed.
1. Choose the providers and models a workload may use. 2. Define routing, caching, and usage policies. 3. Review model usage and request outcomes.
Route. Observe. Control.
We are exploring a shared interface with explicit policies for model access.
Choose among providers
Explore model routing through a common interface. Supported providers and compatibility with their individual APIs remain to be defined.
Usage policies and caching
Explore request caching and budget controls with visible usage. Accounting rules, in-flight requests, and enforcement limits need explicit semantics.
Explicit provider selection
Explore configurable alternate-provider policies for errors or rate limits. Model differences and retry behavior would remain visible to the caller.
Other parts of an agent workflow.
Explore compute, session records, memory, and storage separately. A gate9 integration is not available today.
Sandboxes
Create Boxes, execute commands, and fork filesystem snapshots with run9.
run9 → owl9Session records
Capture and review native transcripts from supported agent runtimes with collection enabled.
owl9 → mem9Agent memory
Store and retrieve context for agent workflows through mem9’s memory interfaces.
mem9 → drive9Shared filesystem
Store and share files using drive9’s filesystem interfaces and access controls.
drive9 →What should a model gateway control?
Tell us which providers, routing rules, and usage controls your team needs.