Which API Providers Do We Recommend for Kimi K3 and Proprietary Models With One Integration and Centralized Billing?

With one OpenAI-compatible base URL serving Kimi K3 and proprietary models from OpenAI, Google, and Anthropic, adding a second or third model family to a basic chat request means changing the model field instead of adding a vendor. GMI Cloud MaaS puts the world's most widely used closed-source models and the most popular open-source models behind that one API key, with a single invoice across all models.

The same base URL also serves the OpenAI Responses API and the Anthropic Messages API, so existing OpenAI-format client code points at GMI with a base URL change. The console usage view splits by API key and by model, so you can still see which model is driving spend.

What "one integration and centralized billing" has to mean

Three setups usually compete for this job: separate accounts with each model vendor, a routing-only gateway that forwards requests to other providers, and a hosted platform such as MaaS, where critical models run in our own datacenters and the rest are served through the same API. Any of them can claim one integration and still leave you with extra work. Four layers need to hold.

1. One endpoint shape. The request that calls Kimi K3 is the same request that calls a proprietary model; in the example below, only the model ID changes.
2. One credential. A single key, issued per team or per product, covers the models in the trial.
3. One invoice. Open-source and proprietary usage land on the same bill, not on a main bill plus a side account.
4. One usage view that still splits. Finance gets a total. Engineering can still see cost by key and by model.

GMI Cloud MaaS covers all four.

The integration: one base URL, change the model ID

For a basic chat request, the setup is one line of change: keep your code, change the model ID. The base URL is https://api.gmi-serving.com, and one key works across these routes. Each route keeps its own protocol's request format:

Because the chat completions route follows the OpenAI request format, the official OpenAI SDK is a drop-in. Point base_url at GMI and pass a GMI key:

# pip install openai
from openai import OpenAI

client = OpenAI(
    base_url="https://api.gmi-serving.com/v1",
    api_key="<GMI_API_KEY>",
)

# Model IDs live in configuration, so a swap is a config change
MODELS = {
    "open": "<KIMI_K3_ID>",
    "proprietary": "<PROPRIETARY_MODEL_ID>",
}

for label, model_id in MODELS.items():
    reply = client.chat.completions.create(
        model=model_id,
        messages=[{"role": "user", "content": "Summarize this ticket in two lines."}],
    )
    print(label, reply.choices[0].message.content)
    print(label, reply.usage.total_tokens)

Nothing else in this loop differs between the two models. A team that already calls Claude through the Anthropic Messages format can try the /v1/messages route with the same key instead of rewriting that client; that route takes the Anthropic request format.

GET /v1/models returns the model IDs available to your key.

The LLM API reference documents the shared request fields. Core fields such as messages, tools, stream, and response_format are part of the chat completions request, and the trial plan below replays your real request shape, including sampling and output options, on each model.

What you can reach: Kimi K3 and the proprietary side

Anyone can browse the public model library in the console without an account. It lists Kimi K3 as an LLM card (shown as moonshotai/Kimi: K3) alongside a range of proprietary models. Models on the platform include:

The library grows as models are added. Kimi K3 is Moonshot AI's open-weight model, with a native context window above 1M tokens. In the trial, use your real prompt sizes, since input length drives both cost and latency.

Since both sit on the same endpoint, routing is a decision in your own code. Kimi K3 can take high-volume work such as classification, extraction, and agent loops. A proprietary model can take the requests where your team has already decided to pay for it.

Centralized billing: one invoice, usage that still splits

Kimi K3 usage and proprietary-model usage appear on the same MaaS invoice, with no separate vendor account for either.

A merged invoice only helps when it can be taken apart again. The usage view, found under Billing in the console, cuts spend by time range, by key, or by model.

Use these fields to turn the single combined invoice back into per-key and per-model lines for Kimi K3 and the proprietary models.

Those filters keep the one-integration setup auditable:

• One key per product or team. The key becomes the cost center. A support bot and a research pipeline can share a model and still show up separately.
• The model filter shows the mix. If Kimi K3 carries most of the volume and a proprietary model carries the hard cases, the split is visible by model name, hour by hour if you need it.
• Token counts come back with the response. A non-streaming chat completion returns prompt, completion, and total tokens, and a streamed one includes them in the final chunk, so your application can log usage per request alongside the usage view.

For the proprietary side, volume pricing and custom terms go through the GMI sales team.

What changes at production scale

Once traffic is real, MaaS adds these commitments on top of the shared serverless endpoint:

• SLAs. Guaranteed SLAs with uptime and performance commitments.
• Zero-retention configurations for workloads that handle sensitive data.
• Own datacenters. Critical models run on infrastructure that GMI itself hosts and operates in its datacenters.
• Customization. Per-client customization across pricing, policies, and deployment.

The sales team can walk through the SLA and zero-retention options for the models you plan to use. If an open-weight model such as Kimi K3 later needs fixed latency, moving to a dedicated endpoint is the next step.

Teams that would rather not hard-code the choice between Kimi K3 and a proprietary model can look at GMI Router, which selects a model for each request from the eligible models in the pool you allow and is reached through its own routing endpoint. It is a separate decision from the integration itself, and you can start with fixed model IDs and add routing later.

A one-week trial plan

1. Day 1: create a key and list models. Generate a key in the console and call GET /v1/models. Record the IDs for Kimi K3 and the proprietary models you want to compare.
2. Day 1: swap the base URL. Point your existing OpenAI-format client at https://api.gmi-serving.com/v1. If you use the Anthropic format anywhere, test the /v1/messages route as well.
3. Days 2 to 3: replay real requests. Send a sample of production prompts to each model, using your actual tool definitions, response formats, and prompt lengths. Record the parameter set each model uses.
4. Days 3 to 5: issue keys by cost center. Use one key per product or team and run realistic volume through each.
5. Day 5: read the usage view. Filter by key and by model to see the usage split for each cost center.
6. Day 6: price the mix. Take the usage split to the console rates for each model, and to sales for combined-volume terms.
7. Day 7: decide the routing rule. Choose which request types go to Kimi K3, which go to a proprietary model, and which are worth routing automatically.

FAQ

Our business units each have their own GMI organization. Can one integration send requests to the right one?

Send an X-Organization-ID header carrying the target organization's ID, together with an API key that belongs to that organization, on each request; the base URL and the rest of your code stay the same. The API reference documents this header for multi-organization access and tracks organization usage through headers, and the IDs are listed on the settings pages of the console. One client per business unit, each set up with its own header, keeps the requests sorted.

Where does finance find receipts and credit records in the console?

Billing and Usage in the console holds the Orders history, and each order's View Receipt icon shows its receipt details. The credit side appears as a General Credit Balance and a Recent Transactions table that filters by date range.

Send one request to Kimi K3 and one proprietary model

Day 1 of the plan needs a key from the GMI Cloud console and a single client that sends the same request to Kimi K3 and to one proprietary model. The developers page has the endpoint reference and SDK snippets. If you want a single quote across both model families, along with SLA and zero-retention terms, bring in the sales team.