[KongchangAI]
· 2 min read· 1,357 words

Kimi K3 in Vercel AI SDK: One npm Package, Two Lines of Code

Kimi K3 in Vercel AI SDK: One npm Package, Two Lines of Code

wallaby-ai-provider lets Kimi K3 plug into Vercel AI SDK in two lines of code, with streaming and Next.js support, though it's a single-source commercial integration.

This article explains how to integrate Kimi K3, with its 1 million token context window, into the Vercel AI SDK using the third-party npm package wallaby-ai-provider. It provides complete examples from installation and environment variable setup to generateText and streamText calls, and shows the actual token usage and per-million-token costs from real runs. It then covers integration in a Next.js Route Handler and the differences in key management, analyzes the causes of two common errors (401 and model not found), and compares Wallaby vs. official list prices (about a 10% discount). Finally, it outlines the solution's advantages and boundaries: convenient calls and transparent billing, but access goes through Wallaby Token's relay endpoint, making it a single-source commercial integration.

Kimi K3 is Moonshot's open-weight model with a 1 million token context window, but it isn't in the Vercel AI SDK's official model catalog. A third-party package called wallaby-ai-provider fills that gap—install it, and you can call Kimi K3 anywhere the AI SDK runs.

Kimi K3 in Vercel AI SDK tutorial

Why This Provider Is Needed

The Vercel AI SDK is currently the easiest path to shipping AI features in TypeScript, and Kimi K3's 1M-token context is quite appealing for scenarios like coding agents. What's missing between them is a working provider—that's where wallaby-ai-provider comes in. In the author's words, it "puts Kimi K3 anywhere the AI SDK can run."

It should be noted that this package is developed by Wallaby Token, and the author explicitly discloses in the original article: Wallaby Token sells API access to Kimi K3, and the endpoint the package points to is their own service. This is not a neutral community open-source project, but an integration solution with a commercial purpose.

Vercel AI SDK is an open-source TypeScript toolkit from Vercel. Its core value is abstracting away the differences between different model providers' APIs with a unified interface, so functions like generateText and streamText can be reused across models. It communicates with models through a "provider" abstraction layer: officially maintained providers include OpenAI, Anthropic, Google, and so on, while an open interface allows third parties to implement their own providers. The wallaby('kimi-k3') in this article is the model handle returned by a third-party provider, semantically equivalent to openai('gpt-4o').

Open-weight models refer to models whose parameters can be publicly downloaded, which is not entirely equivalent to "open source"—training data, training code, and license terms may not be open. Kimi K3 uses this release format, meaning anyone can deploy the weights themselves, but the officially hosted API service and third-party resale channels are two different things.

Installation and Minimal Working Example

The prerequisites are simple: a Wallaby Token account and API Key, Node.js 18 or higher, and two npm packages. New accounts get $0.50 in trial credit, which according to the author is enough to run about 20 verification calls.

Installation takes just one command:

npm install wallaby-ai-provider ai

After setting environment variables, two lines of code can make a request:

import { generateText } from 'ai';
import { wallaby } from 'wallaby-ai-provider';

const { text } = await generateText({ model: wallaby('kimi-k3'), prompt: 'Hello, world' });

The original article emphasizes that this call was actually executed: 92 input tokens, 117 output tokens, one round trip. Each call returns a usage object, making it easy to meter in your own code.

token is the smallest unit of measurement for text processed by a model, and is not equivalent to a character or a word. In English, one token roughly corresponds to 4 characters, while in Chinese one character typically takes 1.5 to 2 tokens. So a "1 million token context window" doesn't mean you can fit 1 million Chinese characters—actual capacity varies by language and content type.

The usage object typically contains three types of fields: promptTokens (input), completionTokens (output), and totalTokens. Input and output are often priced differently—in this article's example, output is about 5 times the price of input, so output tokens are the main source of cost. In streamText scenarios, usage is a Promise and needs to be awaited to get the final statistics.

Streaming Output and Real Bills

After switching to streamText, the original article does a more concrete demo—asking "what does a 1M-token context window buy a coding agent?" and printing the cost at list price on the last line.

import { streamText } from 'ai';
import { wallaby } from 'wallaby-ai-provider';

const result = streamText({
  model: wallaby('kimi-k3'),
  prompt: 'In three sentences: what does a 1M-token context window buy a coding agent?',
});

for await (const delta of result.textStream) process.stdout.write(delta);

const usage = await result.usage;

This run consumed 103 input tokens, 1859 output tokens, at a cost of $0.0254. The original article gives the formula: (103 × $2.70 + 1859 × $13.50) ÷ 1,000,000. Unlike a vague "starting at" price, this is a bill number specific to a single call.

streamText returns an async iterator textStream, which can output as it generates, significantly reducing time to first token (TTFT), which is especially important for chat interfaces. Unlike generateText, which returns the complete text at once, streaming calls need to wait for all generation to finish before accurate usage data is available.

Cached input is a discount tier suppliers offer for repeated prefixes. When multiple rounds of conversation share the same system prompt or long document, that portion gets cached, and from the second time onward it's billed at a price far below standard input. In this article's table, the cached input price is about one tenth of the standard input price, which can significantly reduce costs for coding agent scenarios that repeatedly call long contexts.

Integrating in Next.js

The same provider can also be used on the server side. Put this snippet into app/api/chat/route.ts:

export async function POST(req: Request) {
  const { messages } = await req.json();
  const result = streamText({ model: wallaby('kimi-k3'), messages });
  return result.toUIMessageStreamResponse();
}

One difference from terminal scripts is key management: store it in .env.local as WALLABY_API_KEY=sk-..., rather than exporting it in the shell. Next.js loads it into process.env on the server side, and the key only exists in this route handler—it isn't sent to the browser.

Route Handler is the way to define server-side endpoints in the Next.js App Router. The POST function exported from app/api/chat/route.ts corresponds to POST /api/chat. Such files by default only execute on the server, so process.env.WALLABY_API_KEY won't be bundled into the client bundle.

toUIMessageStreamResponse is a helper method provided by the AI SDK. It converts model output into a streaming response format that the frontend useChat hook can consume directly, saving you the trouble of manually assembling SSE. .env.local is a local environment variable file by Next.js convention, excluded by .gitignore by default and not committed to the repository; only variables starting with NEXT_PUBLIC_ are exposed to the browser, while the rest are readable only on the server.

Troubleshooting Two Common Errors

A 401 on the very first call: this means the process can't read WALLABY_API_KEY. In terminal scripts, it usually means the export command wasn't run, or was run in another window. In Next.js, it could be that the key wasn't written into .env.local, or that the dev server had already been started before the key was added—after modifying the environment variable file, you need to restart next dev.

"model not found": the model ID must be strictly kimi-k3. Not moonshotai/kimi-k3, not kimi-k3-turbo, and not the display name. The provider passes the string through to the endpoint as-is, and the endpoint only accepts this canonical ID.

Pricing Comparison

The per-million-token prices given in the original article are as follows (as of the time point stated in the original):

WallabyOfficial list price
Input$2.70$3.00
Cached input$0.27$0.30
Output$13.50$15.00

All three Wallaby price tiers are about 10% below the official list price. At this rate, the $0.50 trial credit can indeed cover roughly 20 verification calls from the entire guide.

Boundaries Where This Solution Fits

Using Kimi K3 as a first-class provider in the AI SDK has clear benefits: one npm package, two lines of code, streaming support, and a bill itemized per token. It's suitable for development teams already using TypeScript and the AI SDK who want to try Kimi K3's long context.

The trade-offs are equally clear. This is a single-source commercial integration: model access goes through Wallaby Token's relay endpoint, rather than Moonshot's official channel. Pricing, availability, and model versions are subject to that service, and official updates won't sync automatically. If your project is sensitive to supply chain provenance, or you already have official Moonshot API access, then building a lightweight provider yourself is also a viable path—after all, the essence of this package is just a thin wrapper.

#Kimi K3#Vercel AI SDK#wallaby-ai-provider#AI SDK provider#Next.js AI integration
Share:

Related articles