Gateway Docs
Understand how Ethen routes model work.
Gateway Docs explain model lanes, routing policies, request visibility, usage awareness, and fallback behavior where configured. Use them to understand how routing decisions fit apps and workflows before you move into exact API behavior.
Start with the routing model.
Gateway gives model work a shared routing path. The useful questions are which lane fits the workload, what policy shapes the route, what stays visible after the request, and how fallback behaves where configured.
- Use flagship, open, and local lanes as routing concepts for different kinds of work.
- Apply routing policies by task, context, review need, or privacy posture.
- Keep request history, route decisions, and usage signals visible where available.
- Plan fallback behavior where configured without treating it as an uptime guarantee.
- Connect Gateway routing to API, Status, Evidence, and workflow surfaces.
Core Gateway concepts
These concepts provide the working model for designing and reviewing routes.
Model lanes
Choose flagship, open, or local lanes based on the task and supported configuration.
Routing policies
Use task type, context, review needs, or privacy posture to shape a route where configured.
Request and usage visibility
Request history, status, route decisions, and usage signals can help teams inspect behavior and adjust policy where data is available. Usage signals are operational context for routing, not pricing or billing commitments.
Fallback and workflows
Configured fallback can change a request path when suitability, availability, or policy requires it. Workflows can use Gateway routing step by step instead of hardcoding one model path.
How a route comes together
- 01
Define the workload
Identify the task, context sensitivity, workflow step, and expected output.
- 02
Choose the lane
Match the work to a flagship, open, or local lane based on need and supported configuration.
- 03
Apply the route
Use the shared Gateway path and the routing policy configured for the workload.
- 04
Keep the decision visible
Route, status, usage signals, and fallback notes can become part of request history where available.
- 05
Review and adjust
Use status, route history, evidence, and workflow outcomes to refine routing policies over time.
Scope
Gateway Docs explain routing concepts. Exact API behavior and current provider availability belong in the API reference and current product documentation.
FAQ
- What do Gateway docs explain?
- They explain model lanes, routing concepts, request visibility, usage awareness, and fallback behavior where configured. They are the docs for understanding how Gateway thinks about lanes, policies, visibility, and configured fallback.
- Does Gateway support every model provider?
- Gateway docs describe the routing model. Exact provider and model availability should come from current technical documentation. Because routing is more useful as a product concept than as a bare provider list.
- What is a model lane?
- A model lane is a route category such as flagship, open, or local, chosen based on task needs and supported configuration. Route policy, model lanes, request visibility, usage awareness, and evidence connections.
- Does fallback always happen?
- Fallback behavior depends on route configuration and available lanes. The docs explain how to think about it and how to keep it visible. Only as configured behavior where the surrounding product surface supports it.
- How does Gateway connect to workflows?
- Workflows can route individual steps through Gateway so each step can use the lane that fits the task.
- Where do I find API details?
- Use API Docs and Platform API for request and response direction. Exact implementation details should be confirmed in final technical docs. It helps teams reason about model routing before they depend on final implementation detail.
Learn the routing model before you wire it in.
Use Gateway Docs to understand lanes, routing policies, request visibility, usage awareness, and fallback behavior where configured.