GLM-5 API Integration Guide: Python, Tools and Pricing | AIWave

GLM API terminology and model selection

GLM is a family rather than a single endpoint. Names, context limits, tool support, and prices can change between releases, so treat the Zhipu documentation and the AIWave GLM model page as the authoritative places to verify a model identifier. Put that identifier in an environment variable and keep a small compatibility table in your application.

Choose a model by task. A general chat model may be suitable for support and drafting, while a reasoning or coding variant may be better for multi-step analysis. Do not infer quality from a model name alone; evaluate with your own prompts, output schema, and token budget.

Authentication and endpoint configuration

Create a gateway key, export it as an environment variable, and use the OpenAI client with the gateway's documented base URL. The benefit of this shape is migration safety: application code stays close to the OpenAI SDK while provider-specific routing remains in configuration. Follow the API documentation for the current endpoint and required headers.

Never ship a key in client-side JavaScript. The browser should call your own backend, and the backend should enforce user quotas, rate limits, and logging policy. If you use a CI environment, scope the secret to the job and rotate it after a test run that may have exposed it.

First GLM request with Python

Start with a small request that has a measurable expected result. Use a low output limit, log usage metadata, and keep the prompt free of production secrets. A stable first request is more valuable than a large benchmark because it confirms credentials, routing, JSON parsing, and error handling together.

When a response is used by a program, request a strict format and validate it with a schema. If validation fails, record the raw response securely and retry with a repair prompt only when the failure is transient or recoverable. Do not allow a parser failure to become an unbounded retry loop.

Python and streaming examples

The snippets below use the same OpenAI-compatible client shape as other AIWave models. The model identifier is intentionally configurable; check the live model page rather than copying an identifier from an old article. Streaming requires UI code that can handle partial output and a final event that may be absent when a connection fails.

For batch jobs, non-streaming calls are often simpler to retry and audit. For interactive chat, streaming improves perceived responsiveness but needs first-byte and total-duration timeouts. Measure both paths with the same prompt set before choosing one for a product surface.

Tool use and structured output

Tool calling should be treated as a contract between the model and your application. Define a narrow JSON schema, validate arguments before execution, and return a compact tool result. Never let a model choose an arbitrary URL, SQL statement, or shell command without an allow-list and authorization check.

Structured output is easiest to operate when you log schema version, validation result, and the model identifier. If the model cannot satisfy a schema, fall back to a safe text response or a human review queue. The function-calling guide provides a wider pattern you can adapt.

Pricing and evaluation discipline

GLM prices and free-tier policies are provider-specific and may change. Use the live AIWave pricing page and the official Zhipu documentation on the day you make a budget. Keep input, output, cache, and retry tokens separate in your spreadsheet; an apparently cheap request can become expensive if a fallback repeats a long prompt.

Build an evaluation set that covers your real traffic: Chinese and English prompts, code, extraction, long context, and safety boundaries. Score correctness, format compliance, latency, and cost per successful task. Store the date and exact model identifier beside every result so a future model update remains comparable.

Production reliability

Use bounded exponential backoff for timeouts and transient 5xx responses. Treat authentication, malformed requests, and unknown model errors as non-retryable. Add a circuit breaker when an upstream failure rate crosses a threshold, and keep a fallback model ready for the workflows where a delayed answer is worse than a lower-cost answer.

Expose operational metrics without exposing prompts: request totals, tokens, status classes, time to first token, total duration, and fallback rate. Alert on changes in error rate or token spend rather than on a single failed call. This makes a GLM integration diagnosable during a provider or application incident.

Migration checklist

Before switching traffic, run a shadow comparison with identical prompts, remove assumptions about OpenAI-specific model names, and validate all JSON parsing paths. Confirm that your content filters, timeout settings, and usage accounting work with the new response metadata.

Deploy gradually, starting with an internal or low-risk route. Keep the previous model available for rollback, publish the selected model and pricing date in your runbook, and review the model comparison guide when your workload changes. A controlled migration is safer than changing every call at once.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["AIWAVE_API_KEY"],
    base_url=os.environ.get("AIWAVE_BASE_URL", "https://aiwave.live/v1"),
)
result = client.chat.completions.create(
    model=os.environ.get("AIWAVE_MODEL", "glm-5"),
    messages=[{"role": "user", "content": "Give two migration checks as a numbered list."}],
    temperature=0.2,
    max_tokens=220,
)
print(result.choices[0].message.content)

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["AIWAVE_API_KEY"], base_url="https://aiwave.live/v1")
for event in client.chat.completions.create(
    model=os.environ.get("AIWAVE_MODEL", "glm-5"),
    messages=[{"role": "user", "content": "Stream a short release checklist."}],
    stream=True,
):
    print(event.choices[0].delta.content or "", end="", flush=True)

GLM model page · Live pricing · API docs · Function calling guide · Model comparison

GLM-5 integration boundaries

GLM-5 is one member of a changing model family. Verify the currently exposed identifier, context, tool behavior, and price in the official documentation and the AIWave GLM model page. Keep a logical model name in application code so a provider alias change remains reversible.

Compatibility means tested roles, streaming events, usage fields, errors, and tool arguments. Put provider differences in a small adapter and connect the integration to the chat-completions documentation.

Prompt and token budgeting

Token cost starts with the prompt that the application sends, not with the model name alone. Put stable instructions in a reusable system message, remove duplicated context, and retrieve only the passages required for the current task. Measure input tokens for English, Chinese, and code separately because character counts are not a reliable cost estimate.

Output limits are equally important. Ask for the smallest useful answer, validate structured output, and set a maximum completion budget. A response that explains every intermediate decision may cost more than a response that returns the required fields. Compare quality after applying the same budget instead of comparing unbounded answers.

Evaluation fixtures that resemble production

Create a versioned fixture set from real task categories: chat, extraction, code, long documents, multilingual prompts, tool arguments, and refusal boundaries. Score correctness, schema validity, and useful completion separately. A high average can hide a failure in a critical workflow, so publish a per-category threshold.

Run the fixtures against the current route and a fallback with the same prompt version. Record model, date, input tokens, output tokens, latency, parse failures, and cost. Keep the raw measurements so a later provider change can be separated from a prompt change. The model comparison explains why a single benchmark number is not enough.

Streaming and partial responses

Streaming improves perceived responsiveness, but a first token does not mean the answer completed. Track time to first token, total duration, bytes delivered, and whether a finish event was observed. The client should display an incomplete state and allow a bounded retry when a connection closes early.

For background work, non-streaming requests can be simpler to retry and audit. Choose the path per product surface and measure both with the same fixtures. Store the model identifier and gateway request ID so a provider delay can be separated from a slow renderer.

Retries, fallbacks, and idempotency

Retry only transient timeouts, connection resets, and selected 5xx responses. Use exponential backoff with jitter and a small attempt budget. Treat authentication, malformed JSON, unknown model, and quota errors as configuration or policy failures. A circuit breaker prevents an incident from multiplying traffic.

Choose a fallback by the task's minimum quality and context requirement. Record the original error, fallback model, and final status. For tool calls and other side effects, store an idempotency key before execution so a replayed response cannot create a duplicate charge or record. See the fallback patterns guide.

Cache, batching, and queue controls

Cache discounts depend on a repeated prefix that the provider recognizes. Keep stable instructions at the beginning, put request-specific material later, and record usage fields instead of assuming a cache hit. Run cold and warm evaluations separately and budget from the observed mix.

Move summaries, classification, and enrichment into a queue with a deadline, retry limit, and dead-letter record. Apply a semaphore per route and tenant, expose queue age, and pause low-priority work when a provider is degraded. Batching changes the user experience and must be measured with the same chat-completions contract.

Security and data handling

Keep keys in a secret manager, separate environment credentials, and rotate them on a schedule. Put authorization, tenant quotas, model allow-lists, and maximum token budgets before the model call. Never put a server key in browser JavaScript or a public repository.

Prompts, documents, and tool results may be sensitive. Redact by default, encrypt retained traces, expire them on a defined schedule, and expose an opaque request ID for support. Log route, model, status, tokens, and latency without making raw content visible to every operator.

Pricing verification and cost per task

Use the live pricing page and the official provider documentation on the deployment date. Keep input, output, cached input, retries, and fallbacks as separate fields. Divide spend by successful task rather than request count; a low request price is not useful if parsing failures cause repeated calls.

Publish the pricing date and model identifiers in the runbook. Re-check them before a launch and alert when token spend grows faster than request volume. The cost comparison gives the accounting vocabulary, while your own token logs are the source for product decisions.

Canary, rollback, and monthly review

Use contract tests first, then shadow traffic, then a canary for a low-risk route. Monitor status classes, schema failures, first-token latency, total duration, tokens, cost, and fallback rate. Keep the last known-good model map and base URL so rollback is a configuration change.

Once a month, review provider status, model identifiers, limits, safety behavior, prices, and documentation links. Retire routes that no longer meet the minimum threshold. A dated checklist and a small regression suite make model changes manageable instead of surprising.