GLM 5.2 (served as glm-4-plus via Zhipu AI's API) is a 753B-parameter mixture-of-experts model with a 1-million-token context window. It handles code, vision, structured outputs, and streaming out of the box. But there is one thing no amount of pretraining can fully solve: events that happen after the training cutoff.
This tutorial shows you two ways to give GLM 5.2 live web access — Zhipu's native web_search tool (the quickest path) and a custom function-calling setup you can wire to any search API (SerpAPI, Brave, Tavily, or similar). Both approaches are compatible with the OpenAI SDK, so the setup is minimal if you have already integrated the model.
By the end you will have a working Python script that answers real-time questions — current stock prices, breaking news, the latest library changelog — without any browser automation or scraping.
Pain Point
Every large language model is frozen in time. GLM 5.2's training data has a cutoff, which means the model cannot answer questions about yesterday's earnings report, the newest framework release, or any event that happened after its snapshot of the internet was taken.
For many production use cases this is a showstopper. A customer-service bot that quotes an outdated return policy, a research assistant that cites superseded documentation, or a financial tool that uses stale price data — all erode user trust immediately. RAG pipelines over private documents help with internal knowledge, but they do not solve the "what happened today" problem.
The standard fix is to pair the model with a live web search at query time: the model decides it needs current information, calls a search tool, reads the results, and folds them into a grounded answer. GLM 5.2 supports this pattern natively.
How GLM 5.2 Web Search Works
GLM 5.2's API endpoint (https://open.bigmodel.cn/api/paas/v4/) is OpenAI-compatible. This means the standard tools / function-calling interface is available, and Zhipu has added a first-party web_search tool type that the hosted model already knows how to use.
The call flow is:
- You include the
web_searchtool in your request. - GLM 5.2 decides — based on the user's question — whether a live search is needed.
- If yes, the Zhipu backend fetches search results and injects them into the model's context.
- The model returns a final answer that cites or incorporates those results.
Steps 3 and 4 happen server-side with the native tool, which makes the integration a single-request operation. With the custom function-calling approach, your Python code handles steps 3 and 4 explicitly, giving you full control over which search provider and ranking logic you use.
Method 1: Native Zhipu web_search Tool
Zhipu's API exposes a web_search tool type that the model can invoke automatically. Enabling it requires one additional entry in the tools list. No separate search-API key is needed.
from openai import OpenAI
client = OpenAI(
api_key="YOUR_ZHIPU_API_KEY",
base_url="https://open.bigmodel.cn/api/paas/v4/",
)
response = client.chat.completions.create(
model="glm-4-plus",
messages=[
{
"role": "user",
"content": "What are the top AI news stories from the past 24 hours?"
}
],
tools=[
{
"type": "web_search",
"web_search": {
"enable": True
}
}
],
)
print(response.choices[0].message.content)That is the entire integration. The model decides whether the question requires a web lookup. If the user asks something the model can answer from training data, it answers directly. If the question requires current information — news, live pricing, a recent software release — the model triggers the search, reads the results, and returns a grounded response in one API round-trip.
You can also disable search for specific turns by setting "enable": False, which is useful when you want deterministic, purely parametric answers (for example, when generating structured outputs from retrieved data you have already loaded into the context).
Method 2: Custom Function Calling with a Search API
The native tool is the fastest path, but there are cases where you want more control: a specific search provider, custom ranking, filtering by date or domain, or the ability to inspect and log raw results before they reach the model. In those cases, implement the search as a standard OpenAI-compatible function call.
The five-step cycle is: define the function schema, pass it to GLM 5.2, receive the model's tool-call request, execute the actual search in your code, and send the results back so the model can write its final answer.
import json
import requests
from openai import OpenAI
client = OpenAI(
api_key="YOUR_ZHIPU_API_KEY",
base_url="https://open.bigmodel.cn/api/paas/v4/",
)
# --- Define the search tool schema ---
tools = [
{
"type": "function",
"function": {
"name": "web_search",
"description": (
"Search the web for current information. "
"Use this for recent events, live pricing, or the latest documentation."
),
"parameters": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "The search query to execute."
},
"num_results": {
"type": "integer",
"description": "Number of results to return (default 5).",
"default": 5
}
},
"required": ["query"]
}
}
}
]
def run_search(query: str, num_results: int = 5) -> list[dict]:
"""
Execute a real web search using your preferred provider.
Replace this stub with a call to SerpAPI, Brave Search, or Tavily.
"""
# Example stub — replace with your actual search provider:
# serpapi_key = "YOUR_SERPAPI_KEY"
# url = "https://serpapi.com/search"
# params = {"q": query, "num": num_results, "api_key": serpapi_key}
# data = requests.get(url, params=params).json()
# return [{"title": r["title"], "snippet": r["snippet"], "url": r["link"]}
# for r in data.get("organic_results", [])[:num_results]]
# Placeholder response for demonstration:
return [
{
"title": f"Search result for: {query}",
"snippet": "Live snippet from the web would appear here.",
"url": "https://example.com"
}
]
def chat_with_search(user_message: str) -> str:
messages = [{"role": "user", "content": user_message}]
# First turn: model may request a tool call
response = client.chat.completions.create(
model="glm-4-plus",
messages=messages,
tools=tools,
tool_choice="auto",
)
choice = response.choices[0]
# If the model wants to search, execute it and send results back
if choice.finish_reason == "tool_calls":
tool_call = choice.message.tool_calls[0]
args = json.loads(tool_call.function.arguments)
search_results = run_search(
query=args["query"],
num_results=args.get("num_results", 5)
)
# Append the assistant's tool-call message and our results
messages.append(choice.message)
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": json.dumps(search_results)
})
# Second turn: model writes final answer using search results
final_response = client.chat.completions.create(
model="glm-4-plus",
messages=messages,
)
return final_response.choices[0].message.content
# Model answered directly without searching
return choice.message.content
if __name__ == "__main__":
answer = chat_with_search(
"What is the current Python version and when was it released?"
)
print(answer)The key points in this implementation:
tool_choice="auto"lets the model decide when to search; set"required"if you always want it to search first.- After the tool call, you send the search results back as a message with
"role": "tool"— this is standard OpenAI function-calling protocol and works identically with GLM 5.2. - GLM 5.2's 1M-token context window means you can comfortably pass dozens of search results (full page text, not just snippets) without hitting limits.
Choosing Between Methods
Use the native web_search tool when you want the fastest integration and do not need to inspect or control the search results. Zhipu handles the search backend, so there are no additional API keys or result-parsing steps.
Use the custom function-calling approach when you need a specific search provider (for domain coverage, geographic filtering, or pricing reasons), want to log raw results for auditing, need to filter results by date range before the model sees them, or are building an agentic loop where the search is one tool among several.
Both methods work with streaming — you can add stream=True to the create() call and iterate over response.choices[0].delta.content for token-by-token output, even while tool calls are in flight.
Real-World Use Cases
Live news summarization. Pass a topic and ask GLM 5.2 to summarize the latest coverage. With the 1M context window, you can include full article text rather than truncated snippets, which dramatically improves summary quality.
Current pricing and availability. E-commerce or travel assistants can query live product or flight data and let the model format a clean comparison — without a dedicated scraping pipeline.
Up-to-date documentation lookup. Ask the model to check the latest API changelog for a library. The model fetches the release notes page, reads the content, and explains what changed since the version you are running.
Financial data queries. For applications that need current exchange rates, index values, or commodity prices, a search tool call at query time is more reliable than embedding stale data into a system prompt.
Competitive Differentiator
Several leading models support function calling and can therefore be paired with a web search tool. What makes GLM 5.2 worth considering for this specific use case is the combination of three factors.
First, the native web_search tool requires no extra API key, no search provider account, and no result-parsing code. The integration is a single JSON object in the tools list — that is a meaningful reduction in setup friction compared to models where you must build the entire search loop yourself.
Second, the 1M-token context window (the largest among production API models as of writing) means you are not forced to truncate search results. You can pass 20 full web pages into a single context and ask the model to synthesize them, something that is impractical at 128K or even 200K tokens.
Third, at $1.40 per million input tokens, web-search-augmented queries remain affordable even when you are injecting several thousand tokens of search results per turn. A comparable workflow on a more expensive model at $15 per million input tokens costs roughly ten times as much at scale.
For a deeper look at the API setup — authentication, streaming, JSON mode, and the full endpoint reference — see the GLM 5.2 API integration guide which covers the complete developer onboarding flow.
Getting Started
If you want to test GLM 5.2's web search before writing any code, glm5.app lets you run prompts against the model directly in the browser. It is a fast way to verify that a query actually triggers the search tool and see what the grounded response looks like before committing to a backend integration.
Once you are ready to build, follow the steps in this tutorial: enable the native web_search tool for the quickest setup, or wire in your preferred search provider via the custom function-calling pattern for full control over results. Either way, GLM 5.2 handles the reasoning and synthesis — you just supply the real-time data.
For teams evaluating GLM 5.2 for production use, glm5.app also provides a playground where you can test edge cases, compare outputs across different system prompts, and estimate token costs before committing API budget.
Sources
- Zhipu AI API documentation and web search tool reference: https://open.bigmodel.cn/dev/api/thirdparty-frame/openai-sdk
- Zhipu AI developer platform: https://open.bigmodel.cn/
- GLM-4 model weights on Hugging Face: https://huggingface.co/THUDM/GLM-4
- Artificial Analysis benchmark leaderboard (speed and quality index): https://artificialanalysis.ai/