What it solves
Without a router, every client must know where models run, which endpoint is healthy, and how to recover when capacity disappears. That logic quickly spreads across applications. Hivenet Router keeps it in one place. Use it to:- expose OpenAI-compatible and Anthropic-compatible request paths
- route requests by model, capability, policy, and reported capacity
- apply fallback chains when a preferred target is unavailable
- enforce API-key, model, request, token, and occupancy limits
- protect capacity with admission control before work reaches a backend
- observe routing decisions, agent health, latency, and errors centrally
When it fits
Hivenet Router is a strong fit when you run your own inference servers, operate a mixed fleet, or need policy and observability that should not live in every client. It is also useful when clients need one endpoint while the serving topology changes independently. A direct connection may be simpler for a single static backend with one trusted client and no need for routing policy, shared quotas, or failover.Operational boundary
The router coordinates requests; it does not replace the inference engines that execute them. Agents report model and hardware capacity, while routing policies decide which healthy targets are eligible. Admission control decides whether eligible capacity can accept more work.Architecture overview
See how routers, agents, and inference engines work together.
Hivenet services
Compare Hivenet Router with hosted Hivenet inference and compute services.
Routing concepts
Learn how policies, candidates, and fallback behavior shape a request.
Admission control
Understand request limits and occupancy protection.