Learn 9router - History, Background & Why Choose 9router

#Introduction

In episode 0 you prepared your environment: foundational skills, the local emulator, and LLM provider credentials. Now it's time to understand why this tool exists. 9router didn't emerge from a vacuum — it's the result of a long evolution of gateway technology, from the simplest to the most intelligent.

This episode's roadmap: we'll trace the evolution of gateways from classic load balancers, compare three generations of technology (traditional API gateway, service mesh, and AI routing gateway), then explore the real-world use cases that make 9router relevant. By the end of this episode you'll know when and why a team needs an AI routing gateway — and how 9router answers that need.

#Gateway Evolution: from Load Balancer to AI Routing Gateway

The term gateway existed long before AI was born. Let's trace through its generations:

Load balancers were born to solve a simple problem: several servers serve the same application, so traffic must be divided so no server gets overwhelmed. The decision is static and load-based — round-robin, least connections, or based on health checks. It doesn't care what's inside the request, only how much there is.

Over time, the need to route based on content emerged: /api to service A, /web to service B. Reverse proxies and API gateways handle this with path- and host-based rules. All of these generations decide based on structure, not meaning.

This is where the big leap happened: when applications started calling LLMs, the routing question changed from "which server?" to "which model, from which provider, and under which policy?". A request contains a prompt — natural language text with an intent. Determining the right model for that intent can no longer be done by comparing path strings. This is what the AI routing gateway tries to solve.

#Traditional API Gateway vs Service Mesh vs AI Routing Gateway

These three technologies are often lumped together even though they solve different problems. Here's the comparison:

A traditional API gateway works at the transport and structure layer: if the path contains /v1/orders and the API key is valid, forward to a certain backend. This decision is deterministic and fast, but blind to payload content.

A service mesh operates one layer below: it injects a proxy (sidecar) into every service and handles inter-service communication — mTLS encryption, automatic retries, and traffic shifting. It guards the fabric, not the front door.

An AI routing gateway makes decisions at the semantic layer. It reads the content of the request — including the prompt — then decides which model fits best, which policies apply, and which provider should be called. This is a different category: previous gateways directed calls, while the AI routing gateway directs thinking.

#Use Case: Prompt Routing

Prompt routing is the practice of directing an incoming prompt to the most appropriate model. Imagine a customer assistant that receives three kinds of questions: light questions like "what time does the store open", technical questions that need reasoning, and language questions that need a model with strong multilingual support.

Without prompt routing, all questions go to one large model — expensive and slow for light questions. With prompt routing, light questions go to a small, cheap, fast model, technical questions to a powerful large model, and multilingual questions to a specialist model. The result: cost drops, latency improves, and quality stays intact.

#Use Case: Multi-Model Orchestration

Modern AI applications rarely use a single model. A product might combine a model for conversation (LLM), an embedding model for semantic search, a code model for code analysis, and a vision model for understanding images. Each category has a different provider and cost profile.

Multi-model orchestration is the art of managing all of it through one entry point. Applications don't need to know which provider handles which type of request — they just send the request to 9router with metadata like task type, and the gateway decides:

routes:
  - name: chat
    match:
      taskType: conversation
    target: anthropic
  - name: embed
    match:
      taskType: embedding
    target: openai-embedding
  - name: code
    match:
      taskType: code
    target: openai-code

The example above shows how 9router separates models by task category. The application just sends a task type field, and the gateway forwards it to the right stack.

#Use Case: Policy-Based Model Selection

Model selection is rarely purely technical — there's always a policy dimension. Some requests must use providers that comply with data residency rules (data must not leave a certain region). Some users subscribe to a premium tier and are entitled to top-tier models, while free users are restricted to standard models.

Policy-based model selection combines these criteria into the routing decision: who the user is, where the request comes from, and which business rules apply. If these rules are written as declarative configuration, they can be reviewed, tested, and rolled back like ordinary code — far safer than logic buried inside application code.

curl -X POST http://localhost:8080/v1/chat \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{"prompt":"Ringkas dokumen ini","user":{"tier":"premium","region":"ap-southeast-1"}}'

Based on the payload above, 9router can decide that a premium user is entitled to a large model, while the region determines which providers may be used. All these decisions happen at the gateway, not in the application. To make this pattern easy to test, get into the habit of validating policy configuration with 9router validate every time it changes.

#Why Choose 9router

From all the discussion above, we can summarize the main reasons to choose 9router:

• Single point of control: all routing, model selection, and safety policies live in one place, not scattered across application code.
• Declarative configuration: routes and policies are written as code, so they can be version-controlled, reviewed, and tested.
• Provider-agnostic: applications aren't tied to a single LLM provider; swapping providers is just a configuration change.
• Cost and latency optimization: prompt routing directs requests to the cheapest and fastest model for that need.
• Safety and policy: compliance, privacy, and access policies are applied consistently in a single layer.

It's important to remember that 9router is not a replacement for an API gateway or service mesh — it complements both. In a modern architecture, the API gateway still guards the application's front door, the service mesh guards internal communication, and 9router stands specifically to manage traffic toward LLMs and tools.

#Conclusion

In episode 1 you've understood why the AI routing gateway was born: the evolution from load balancers that decide based on load, toward gateways that decide based on request meaning. You've also compared three categories of gateway technology and learned three main use cases — prompt routing, multi-model orchestration, and policy-based model selection — plus the reasons for choosing 9router as the solution.

Key takeaways:

• Gateway evolution moves from structure-based decisions toward intent-based decisions.
• API gateways handle structure, service mesh handles the network, AI routing gateways handle meaning.
• Prompt routing saves cost and lowers latency by choosing the most appropriate model.
• Multi-model orchestration demands a single entry point for conversation, embedding, code, and vision.
• Policy-based model selection folds business rules, region, and user tier into the routing decision.

In the next episode, episode 2, we'll dismantle 9router's core concepts and main architecture — the route engine, model selector, policy engine, observability layer, the flow from intent extraction to tool invocation, and 9router's position between clients, LLM providers, and downstream tools. Prepare your mental configuration, because the next episode will be very technical!