From account review to production, in five minutes

Introduction

Kite Layer is a managed AI API gateway for enterprise teams. With one API key and one standardized API endpoint, teams can manage multiple model providers, routing, access control, usage analytics, and billing operations.

What it solves

• Reduce the operational overhead of scattered provider accounts, keys, SDKs, and invoices.
• Use routing, fallback channels, and policy configuration to reduce the impact of a single upstream issue.
• Separate API keys, quotas, rate limits, and access policies by team, project, and environment.
• Use usage analytics and cost visibility to support internal allocation, customer reconciliation, and model-spend optimization.
• Access different model capabilities through a standardized interface and reduce application-side migration work.

Who it is for

• Software teams adding AI capabilities to their own products.
• Platform teams running RAG, agents, batch jobs, and internal automation.
• Enterprise service teams that need unified customer usage, quotas, and billing.
• Technical teams that need to balance cost, performance, and reliability through model routing.

Quickstart

Get through the full request path in three steps. It should take about five minutes.

1. 1

   Complete business account review

   Contact [email protected] to confirm your business use case, service scope, and test environment. After approval, sign in to the console with your business account.

2. 2

   Create a test API key

   After account approval, go to Console -> API Keys, create a test key, then copy the sk- key into your local environment:

   CopyCopied

   export KITELAYER_API_KEY="sk-..."

   The key is shown only once. If you lose it, generate a new key in the console and disable the old one.
3. 3

   Make your first call

   Use curl to verify the key and the base request path:

   CopyCopied

   curl https://api.kitelayer.com/v1/chat/completions \
     -H "Authorization: Bearer $KITELAYER_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{
       "model": "claude-haiku-4-5",
       "messages": [{ "role": "user", "content": "Hello" }]
     }'

   If the response body includes choices[0].message.content, the request path is working.

   The request path is live. Next, connect your SDK, switch models, or enable streaming as needed.

CLI quickstart

Kite Layer works with common AI coding command-line tools such as Claude Code, Codex, and Gemini CLI. Copy the setup commands below to verify connectivity.

3.1 Claude Code

Anthropic’s AI coding CLI. Point ANTHROPIC_BASE_URL to the gateway and use the same sk- key for authentication.

# 1) Install
npm install -g @anthropic-ai/claude-code

# 2) Configure environment variables in ~/.zshrc or ~/.bashrc
export ANTHROPIC_BASE_URL="https://api.kitelayer.com/v1"
export ANTHROPIC_AUTH_TOKEN="$KITELAYER_API_KEY"

# 3) Start
cd your-project && claude

3.2 Codex (OpenAI)

OpenAI’s AI coding CLI. Add two configuration files, then start the CLI.

# 1) Install
npm install -g @openai/codex

# 2) Write the two config files below, then start
codex

model = "gpt-5.4"
model_provider = "kitelayer"

[model_providers.kitelayer]
name = "Kite Layer"
base_url = "https://api.kitelayer.com/v1"
wire_api = "responses"

{ "OPENAI_API_KEY": "$KITELAYER_API_KEY" }

3.3 Gemini CLI

Google’s command-line assistant. Kite Layer also provides a Gemini-native endpoint ( https://api.kitelayer.com/v1beta) compatible with the Google AI Studio request format.

# 1) Install
npm install -g @google/gemini-cli

# 2) Configure environment variables (Kite Layer provides a Gemini-native endpoint)
export GEMINI_API_KEY="$KITELAYER_API_KEY"
export GEMINI_API_BASE_URL="https://api.kitelayer.com/v1beta"

# 3) Start
cd your-project && gemini

Authentication

Send your API key in the HTTP Authorization header:

Authorization: Bearer $KITELAYER_API_KEY

Managing multiple keys

• Create separate keys for each project and environment, such as development, staging, and production.
• Let team members use their own keys instead of sharing one key, so access can be audited and revoked cleanly.
• Each key can be disabled, revoked, or given its own quota limit from the console.

What to do after a key leak

1. Disable or delete the key in the console immediately.
2. Review recent usage to check for unexpected calls.
3. Create a new key and update your production environment variables.
4. Find the source of the leak and avoid committing keys to Git or logs again.

API examples

5.1 Basic chat

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["KITELAYER_API_KEY"], base_url="https://api.kitelayer.com/v1")

resp = client.chat.completions.create(
    model="claude-opus-4-6",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Explain RAG in one sentence."},
    ],
)
print(resp.choices[0].message.content)

5.2 Streaming

For long-form output, streaming improves the perceived response time.

stream = client.chat.completions.create(
    model="gpt-5.4",
    messages=[{"role": "user", "content": "Write a haiku"}],
    stream=True,
)
for chunk in stream:
    print(chunk.choices[0].delta.content or "", end="")

5.3 Multimodal image input

Vision-capable models can receive image_url or base64 input.

resp = client.chat.completions.create(
    model="gemini-3.1-pro-preview",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "What's in this image?"},
            {"type": "image_url", "image_url": {"url": "https://..."}},
        ],
    }],
)

5.4 Function calling

Tool-capable models can use the same request structure. Exact fields depend on the selected model and current console capability.

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Get current weather in a city",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    },
}]

resp = client.chat.completions.create(
    model="claude-opus-4-6",
    messages=[{"role": "user", "content": "Weather in Beijing?"}],
    tools=tools,
)

Choosing a model

You can pass a concrete model ID in the model field, or manage model selection through aliases and routing policies in the console. In production, start by grouping workloads by capability, then configure defaults, fallbacks, and quotas for each group.

Choose by capability

• General chat and generation: customer support, knowledge Q&A, writing, and in-app conversations.
• Reasoning and code: complex analysis, code generation, agent workflows, and high-value requests.
• Multimodal understanding: image, document, audio, and video input.
• Retrieval and reranking: RAG, semantic search, and knowledge-base recall.
• Regional or private routes: customer-specific provider, data-boundary, or dedicated-channel requirements.

Routing strategy

• Use different keys and quotas for production, staging, and test environments.
• Configure a high-capability primary model and a cost-efficient fallback for critical paths.
• Separate routing for batch, summarization, classification, and other lower-risk workloads so costs can be tracked independently.
• Review usage analytics regularly and tune routing by hit rate, failure rate, latency, and cost.

See the homepage capability matrix for typical categories. Live model availability, quotas, and prices are controlled in the console.

Advanced tips

7.1 Fallback

For critical paths, configure a Fallback Chain on the key so a single model or upstream issue does not stop the request path:

# Console -> API Keys -> select a key -> Fallback
primary:   claude-opus-4-6
fallback:
  - gpt-5.4
  - claude-sonnet-4-6

When the primary model times out, is rate-limited, or returns an error, the gateway can fall back to the next model in order. The resp.model field indicates the model that actually served the request.

7.2 Prompt Caching

For fixed system prompts or long document context, caching can reduce repeated input cost and improve response performance:

messages=[
    {
        "role": "system",
        "content": long_system_prompt,
        "cache_control": {"type": "ephemeral"},
    },
    ...,
]

Cache billing rules vary by model and upstream provider. Use the console model configuration and billing details as the source of truth.

7.3 Timeouts and retries

Recommended SDK-side defaults:

• Non-streaming: start with a 120-second client timeout; reasoning models may need longer.
• Streaming: avoid short client-side timeouts and rely on gateway heartbeats.
• Retries: retry only 5xx and 429 responses, with exponential backoff for idempotent workloads.
• Do not retry most 4xx responses, except 429. They usually indicate a request error.

Billing and usage

8.1 Billing model

Fees are typically settled through business accounts, contracts, invoices, and actual service usage. Input tokens, output tokens, cache hits, routing policies, and customer agreements can affect the final invoice.

8.2 Viewing usage

Console -> Usage provides:

• Usage curves by model, key, and day.
• Per-request token details, including input, output, and cache hits.
• CSV exports for internal finance workflows.

8.3 Contracts, invoices, and service allowance

Business customers may pay through subscriptions, monthly invoices, advance service payments, or written service agreements. Service allowance, billing cycles, and refund handling are governed by the Billing page, console records, or written agreements.

FAQ