GLM-4.6 API guide: tool calling, RAG, and bilingual agents

Quick answer: GLM-4.6, GLM-5, and what to route this workload through

Developers searching for a GLM-4.6 API guide are usually building one of three things: an agent that calls tools, a retrieval-augmented generation pipeline over their own documents, or a support bot that has to move naturally between Chinese and English. GLM-4.6 handled all three reasonably well, which is why it built a following among teams shipping bilingual products. Zhipu's own API still serves it directly if you have an existing integration. For new integrations, the current generation is GLM-5, with GLM-5.1 and GLM-5.2 as higher-instruction-following tiers above it. All three keep the same tools array, tool_choice, and tool_calls contract that GLM-4.6 used, and all three were trained on the same bilingual corpus lineage, so the skills that made GLM-4.6 useful for this workload carry forward. Nothing about tool calling, retrieval-augmented generation, or bilingual replies is GLM-specific mechanically; every OpenAI-compatible chat completions API works the same way underneath, which is exactly why the cost math below applies regardless of which GLM tier, or which competing model, ends up in your config file.

How tool calling, RAG, and bilingual replies actually work

Put the three together and a single user turn in a bilingual RAG support agent looks like this: retrieve the relevant chunks, assemble the prompt from system instructions, tool definitions, retrieved chunks, and conversation history, call the model, execute whatever tool it asked for, call the model again with the tool's result, then return the final answer to the user. Every one of those calls resends everything that came before it in that turn, because chat completions APIs are stateless between calls. That single fact, not anything specific to GLM, is the entire mechanism behind the cost surprises covered below.

• Tool calling: the model never executes code. It returns a tool_calls object naming a function and its arguments, your application runs that function, and the result is appended as a new message before the model is called again. One user question can trigger two, three, or more of these round trips before a final answer comes back.
• Retrieval-augmented generation: the model never searches your documents. A vector or keyword search runs in your application first, and the matching chunks get pasted into the prompt as plain text before the completion call, exactly as if you had typed them in yourself.
• Bilingual replies: GLM-family models will usually answer in whichever language the user wrote in, but "usually" is not a policy your support queue can rely on. Production bilingual agents pin the reply language explicitly in the system prompt instead of trusting language detection to guess correctly every time.

Worked example: what a bilingual RAG support agent costs per day

Model a realistic case instead of guessing. Assume a support agent handling 1,000 queries a day, each carrying a 600-token system prompt, a 900-token tool schema for two or three functions, 2,500 tokens of retrieved context from a vector search, and 500 tokens of recent conversation history, for roughly 4,500 input tokens on the first call. Roughly one in three queries needs a second tool round trip to fetch an order status or run a lookup. Because chat completions APIs are stateless, that second call resends the entire 4,500-token first-call context plus the tool call and its result, roughly 1,200 tokens of new content, for about 5,700 input tokens on that call alone, and a 150-token final answer on top of the 350-token answer a single-call query gets. Averaged across all 1,000 queries, that lands at about 6.4 million input tokens and 400,000 output tokens a day. The table below prices that exact workload across the GLM-5 family and the nearest bilingual-capable alternatives in this catalog, so the tier choice is a straight price-for-capability read rather than a guess.

Why tool-calling and RAG costs surprise people

None of this is a defect in any particular model. It is what happens when an agentic loop, a retrieval step, and a language-detection habit all compound inside the same conversation without anyone tracking the token math turn by turn.

• Tool-call loops multiply the call count, not just the token count. A question that needed one call at a small chat app now needs two or three inside an agent framework, and every one of those calls carries the full tool schema and system prompt again.
• RAG retrieval size creeps up quietly. "Top 5 chunks" sounds modest until each chunk runs 500 to 800 tokens, and a chatty retriever can push 3,000-plus tokens into the prompt before the model even reaches the actual question.
• Bilingual token counts are not symmetric. Chinese text does not compress into tokens the way English does, so the same conversation can tokenize noticeably differently depending on which language the user is writing in, which makes flat per-message cost estimates unreliable for mixed-language traffic.
• Tool schema bloat rides on every call, not just the first one. A growing internal library of functions means every definition, name, description, and JSON parameter schema gets resent on every turn of every conversation that has tools enabled at all.
• The GLM-5 family tops out at a 200K token context window, generous but not unlimited. A RAG pipeline that keeps appending retrieved chunks and history without pruning will eventually hit that ceiling or start silently dropping older context.
• Malformed tool-call arguments trigger expensive retries. When a model emits invalid JSON in a tool call, naive retry logic resends the entire accumulated context to ask again, rather than just re-prompting for corrected arguments, which doubles the cost of that one turn.

GLM-5 family vs the nearest bilingual alternatives

The GLM-5 tiers are not interchangeable, and neither are the other Chinese-origin models commonly considered alongside them for bilingual, tool-heavy, or RAG-style workloads. Context window matters as much as price once conversation history and retrieved chunks start accumulating in the same window.

Practical fixes: control cost without hurting quality

The tool and retrieval fixes usually save more than switching model tiers does, because they cut the input volume that every call in the loop resends. Model routing is the last lever, applied once the loop itself is not wasting tokens on schemas and context the current turn does not need.

• Filter the tools array per request. If your app supports twenty functions overall, send the three to five relevant to the current task, not the full toolbox on every call.
• Trim retrieved chunks before they hit the prompt. Rerank and keep the top three, not the top ten, and strip headers and boilerplate out of each chunk before it is pasted in.
• Pin the reply language explicitly in the system prompt rather than relying on autodetection. A wrong-language reply usually costs a retry, which doubles that turn's bill.
• Cache the retrieval step, not just the completion. If ten users ask near-identical questions, re-running the vector search each time wastes latency even when the final answer would otherwise be cacheable.
• Validate tool-call JSON before executing the function, and on a parse failure, re-prompt for corrected arguments alone instead of resending the entire accumulated context.
• Route the routine slice of the workload, high-volume queries with small retrieved context and no tool calls, through a lower-cost OpenAI-compatible endpoint such as APIsRouter, and reserve the pricier GLM tier for the fraction of queries that need multi-step tool reasoning or fail structured extraction on the first pass.

Config example: tool calling through an OpenAI-compatible endpoint

GLM-5 tool calling runs on the same request shape as any OpenAI-compatible chat completions call: a tools array describing your functions, tool_choice to control whether calling one is required, and a tool_calls field in the response when the model wants to invoke one. Point the client's base_url at the endpoint below and the model ID at whichever GLM-5 tier fits the task, and the rest of an existing agent framework needs no changes. Verify the endpoint and key with a plain curl request before wiring up the full tool-calling loop:

from openai import OpenAI

client = OpenAI(
    api_key="sk-APIsRouter-...",
    base_url="https://api.apisrouter.com/v1",
)

tools = [{
    "type": "function",
    "function": {
        "name": "lookup_order_status",
        "description": "Look up the shipping status of a customer order",
        "parameters": {
            "type": "object",
            "properties": {"order_id": {"type": "string"}},
            "required": ["order_id"],
        },
    },
}]

response = client.chat.completions.create(
    model="glm-5.1",
    messages=[
        {"role": "system", "content": "Reply in the same language the user writes in."},
        {"role": "user", "content": "\u8ba2\u5355 8842 \u53d1\u8d27\u4e86\u5417\uff1f"},
    ],
    tools=tools,
    tool_choice="auto",
)
print(response.choices[0].message.tool_calls)

FAQ