How to Run Kimi K3.1 Pro on Canopy Wave

This guide explains the model’s capabilities, walks through your first request, and covers the details that matter when you connect it to an application. You will need a Canopy Wave account, a Model API key, and either cURL or Python.

Kimi K3.1 Pro is an open-weight Mixture-of-Experts model from Moonshot AI. Its architecture contains 2.8 trillion total parameters, with 104 billion active parameters, and supports a context window of up to 1,048,576 tokens.

That context capacity makes it worth evaluating for work that spans many files or documents. Possible applications include investigating a repository, comparing technical specifications, and reviewing a collection of research materials.

The model accepts text and images and produces text. Moonshot describes improvements in coding, 3D creation, financial research, and agentic tasks. For a developer, those capabilities suggest several useful starting points:

A model response does not automatically execute code, open a browser, or operate CAD software. Your application must supply any execution environment and control what the model may do.

Moonshot's published evaluations include the following Kimi K3.1 Pro results:

These are Moonshot-reported results, not measurements of Canopy Wave’s hosted endpoint. The model card states that its evaluations use maximum reasoning effort, temperature 1.0, and top-p 0.95 unless otherwise specified.

The tools condition matters. A CAD benchmark run with external software measures a different workflow from a basic text request. The scores also use different tasks and evaluation methods, so you should not compare them as interchangeable percentages.

Use these results to decide what to test. For deployment decisions, run a small evaluation with your own prompts, expected answers, and acceptance criteria. Check correctness before optimizing request volume or response speed.

Canopy Wave provides an OpenAI-compatible API. For this tutorial, the relevant settings are:

Keep the full model ID, including the provider prefix and the period in k3.1. A model name copied from another provider’s documentation may not match the identifier used by Canopy Wave.

Canopy Wave calls these credentials Privacy Keys. The full key is shown only when you create or reset it. A masked value copied from the key list cannot authenticate an API request.

Store the key in your server environment rather than your source code. For the terminal examples below, set:

export CANOPYWAVE_API_KEY="YOUR_CANOPY_WAVE_API_KEY"

Replace the placeholder with your actual key. Do not publish that command with a real credential in a tutorial, screenshot, or repository.

You will also need cURL for the first example. For Python, use Python 3.10 or newer and install the OpenAI package:

python3 -m pip install --upgrade openai

Start with a short text prompt. This makes it easier to separate connection problems from the demands of a larger application.

curl -sS https://inference.canopywave.io/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $CANOPYWAVE_API_KEY" \
  -d '{
    "model": "moonshotai/kimi-k3.1-pro",
    "messages": [
      {
        "role": "user",
        "content": "Explain serverless inference in three short sentences."
      }
    ],
    "max_tokens": 4096
  }'

A successful call returns a JSON response. Look for the final answer in choices[0].message.content. If the API returns an error, inspect its message before changing the prompt or adding more parameters.

The example leaves sampling and reasoning controls unspecified. Start with the endpoint's defaults, then add optional settings only after checking their support for this model on Canopy Wave.

Save the following example as run_kimi.py. It uses the same endpoint, model ID, and prompt as the cURL request.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["CANOPYWAVE_API_KEY"],
    base_url="https://inference.canopywave.io/v1",
)

response = client.chat.completions.create(
    model="moonshotai/kimi-k3.1-pro",
    messages=[
        {
            "role": "user",
            "content": "Explain serverless inference in three short sentences.",
        }
    ],
    max_tokens=4096,
)

print(response.choices[0].message.content)

Run it from the terminal where you set the environment variable:

python3 run_kimi.py

If you already use an OpenAI client, update the API key, base URL, and model ID in your configuration. Keep your existing application behavior under test, especially if it depends on provider-specific parameters or response fields.

Self-hosting a model of this size involves more than downloading its weights. You must plan inference infrastructure, operate the serving software, and maintain it as your workload changes.

With the Shared Endpoint, your application sends requests to Canopy Wave’s hosted service. You can concentrate on prompt design, response handling, and product behavior instead of building the serving stack for an initial evaluation.

The OpenAI-compatible interface lets you use the Python client shown above. Keeping provider settings in one configuration layer also makes it easier to compare models without scattering endpoint details throughout your codebase.

Compatibility still needs application-level testing. A basic Chat Completions request is a useful first check, but it does not establish support for every optional feature offered by another provider.

Measure your traffic pattern first. Bring your expected concurrency, prompt sizes, output lengths, and service targets to the capacity discussion rather than assuming a shared and dedicated deployment have identical limits.

Ask for a deliverable and define how you will judge it. A coding prompt can specify the affected files, permitted changes, and required tests. A document task can request supporting passages and a separate list of unresolved questions.

For example: "Review these two API specifications. List breaking changes, cite the relevant sections, and propose migration tests. Do not infer missing requirements."

That instruction gives the model a more useful target than a broad request to analyze everything. Keep human review in the workflow for decisions that carry operational or financial consequences.

A large context window gives you room for substantial source material. It does not mean every request should include your entire repository or document archive.

Start with the materials the task actually needs. Label files and sections clearly, remove duplicate content, and reserve room for the response. Compare a focused prompt with a larger one before making full-context requests your default.

For research tasks, ask the model to distinguish source-backed statements from its own deductions. Verify quoted figures against the original documents, especially when several files use different units or reporting periods.

Kimi’s native API has its own reasoning controls, multimodal input rules, and tool workflows. Those instructions do not automatically describe the Canopy Wave endpoint.

Keep the first integration limited to the text request shown here. Before adding image input, reasoning settings, structured output, or tools, confirm the supported request format for this model with Canopy Wave’s current documentation or support team.

An agent also needs application-side safeguards. Limit tool permissions, validate arguments, and review actions that modify external systems. A model's ability to propose an action is separate from your application's permission to execute it.

Build a small test set from the work you expect the application to perform. Include difficult cases, incomplete inputs, and requests where the correct response is to ask for clarification.

Record answer quality, latency, and token usage together. A shorter response is not automatically better, and a benchmark score cannot tell you whether an answer meets your team's acceptance criteria.

If authentication fails, confirm that the environment variable contains the full key rather than its masked display value. Check that the key remains active and that you are using a Model API credential, not a separate Cloud management credential.

If the model cannot be found, compare the request with the exact identifier: moonshotai/kimi-k3.1-pro. Check the base URL as well; the Python client expects the /v1 base, while cURL uses the complete /chat/completions path.

For HTTP 429 responses, review your account's rate limits and reduce request frequency. Canopy Wave recommends exponential backoff instead of repeated immediate retries. Confirm your plan's limits before running concurrent tests.

If a response is incomplete or lacks final text, inspect the returned fields and output limit. Reduce the task to a short prompt before investigating a more complex workflow. Avoid logging API keys or sensitive prompt content while debugging.

To run Kimi K3.1 Pro on Canopy Wave, create a Model API key, configure the OpenAI-compatible endpoint, and use moonshotai/kimi-k3.1-pro as your model ID.

Once the basic request works, test it against your application’s actual tasks. Add context and optional features gradually, measure the results, and discuss dedicated capacity when your workload requires it.