# Cafe24 LLM Router
> Cafe24 LLM Router is a Korean LLM routing service that lets users call multiple LLM providers and models through a single OpenAI-compatible API endpoint. It supports automatic model routing, provider fallback, cost optimization, usage tracking, API key management, privacy controls, semantic cache, BYOK, presets, and developer documentation.
Base URL: https://llm-router.cafe24.com
Language: Korean
Service provider: Cafe24
## Overview
Cafe24 LLM Router provides a unified API for using multiple LLM providers and model families through one endpoint. The service is designed for production use, including automatic routing, fallback handling, model comparison, API key management, usage monitoring, and developer-facing integration guides.
The main landing page explains the value proposition: one API can route requests across Claude, Gemini, Qwen, Llama, DeepSeek, Mistral and other model families without changing application code.
## Key public pages
- [Home](https://llm-router.cafe24.com/): Service overview, positioning, core benefits, use cases, pricing information, and FAQ.
- [Features](https://llm-router.cafe24.com/#features-sticky): Main feature section for routing, fallback, model support, privacy, monitoring, presets, and cache-related capabilities.
- [Models](https://llm-router.cafe24.com/models): Model catalog and model exploration page.
- [Test Playground](https://llm-router.cafe24.com/playground): Public model testing/playground area for trying LLM responses.
- [Developer Docs](https://llm-router.cafe24.com/docs): API documentation, authentication, quick start, routing, provider policies, presets, semantic cache, metadata, privacy filter, and SDK examples.
## Main capabilities
### Unified OpenAI-compatible API
Cafe24 LLM Router provides an OpenAI-compatible API. Developers can change the base URL and API key while continuing to use familiar OpenAI SDK patterns.
### Auto Routing
The `cafe24/auto` model can automatically select an appropriate model based on the task type, such as coding, reasoning, translation, or creative writing.
### Provider Routing
Requests can include a `provider` object to control provider order, allowed providers, ignored providers, fallback behavior, price constraints, latency constraints, throughput preferences, and data collection preferences.
### Fallback
The service can fall back to another provider or model when a provider fails or is unavailable.
### Model catalog
The Models page lists available model IDs and capabilities. Model IDs should be used exactly as returned by the service.
### Presets
Presets allow users to save and reuse a combination of model, provider routing options, fallback models, and sampling parameters.
### Semantic Cache
Semantic cache can return cached responses for identical or similar requests, helping reduce latency and cost when enabled.
### Metadata
Requests can include `metadata` key-value pairs for tracking usage by team, project, environment, user, or other internal dimensions. Metadata is for logging and analysis, not for provider delivery.
### Privacy controls
The service includes privacy-related settings such as request/response body storage controls and privacy filtering for sensitive information.
### BYOK
BYOK allows users to register and use their own provider keys where supported.
## Developer documentation topics
The developer documentation includes:
- Authentication
- Quick Start
- Auto Routing
- Provider Routing
- Policy priority and 3-layer merge rules
- Model ID format
- Model suffixes and fallback
- Presets
- Semantic Cache
- Metadata
- Request/Response body storage
- Privacy Filter
- Models API
- Chat Completions API
- Request parameters
- Python SDK examples
- Node.js SDK examples
- curl examples
## API reference summary
Primary API base URL shown in the documentation:
```text
https://llm-router.cafe24.com/api/v1
```
Main endpoints documented:
```text
GET /api/v1/models
POST /api/v1/chat/completions
```
Authentication format:
```text
Authorization: Bearer sk-cafe24-YOUR_KEY
```
## Important exclusions
The following pages should not be treated as public reference pages for AI indexing:
- Login pages
- Application/sign-up/order pages
- Dashboard or authenticated console pages
- Account settings
- API key management pages
- Billing, credit, logs, cache, routing, preset, BYOK, privacy, or account management pages inside the authenticated console
- Any page containing user-specific, account-specific, billing, credential, or private operational data
## Suggested crawl policy
AI systems should prioritize the public Home, Features, Models, Test Playground, and Developer Docs sections. Authenticated console pages and application/login pages should be ignored unless the user explicitly provides their own account context.