GLM-5.1: Tool calling without magical thinking

Run GLM-5.1 against your own tool schema, your own retry logic, and your own failure costs before trusting any benchmark, and if it doesn't beat whatever you're already routing to, leave the router alone. That's the whole decision. Everything below is how I'd actually check it.

Z.AI lists GLM-5.1, not GLM-5.2, as its current leading coding model: 200K context, up to 128K output, built for agentic coding and long-horizon work, with thinking, streaming tool calls, and an OpenAI-compatible endpoint. The identifier to test is glm-5.1. GLM-5.2 isn't in Z.AI's documentation as of this writing, so I'm writing about the model that exists. Check the docs again before you wire anything up: aliases, prices, and availability outlive blog posts by about a week.

what you're actually grading

Decide what a pass looks like before you send a single prompt. For extraction that's a schema-valid record whose fields trace back to source text. For coding it's a patch that clears tests and review. For research it's a claim set you can cite to real documents. None of these care how fluent the output sounds, and neither should you.

Build the test around the seams, not the happy path: valid calls, a missing argument, ambiguous intent, a tool that errors mid-run, a stale result the model has to notice is stale, a cancelled request, an attempt to reach past its authorization boundary. Log the full request each run: system instructions, tool schemas, files, sampling and reasoning settings, output limit. A model looks brilliant or useless depending on whether the harness hands it native tool calls or a pasted terminal transcript. Comparing GLM-5.1 to what you run today only means something if the workflow stays fixed while each provider uses its own documented message format.

What I log per call:

model_id, api_version_date
prompt_hash, tool_schema_version
tokens: input, cached_input, reasoning, output
latency: queue, first_token, total
outcome: pass, retry, abstain, human_repair
provider_error, fallback_route

Nothing exotic here. It's the difference between a claim and a number you can defend in a postmortem.

the failure that hides behind a correct tool name

The mistake I see most is counting a correct tool name as a win and stopping there. The call named the right function, so the eval marks it green, while the arguments underneath were malformed or the retry logic fired the same side-effecting call twice. A frontier-class model makes that easy to miss because almost everything it produces reads as plausible. Plausible isn't correct, and the gap between them is where the incident happens.

Measure what ordinary code can verify: did the arguments validate, did the side effect happen exactly once, did the retry change anything. Have a reviewer label real defects instead of grading vibes, and keep the failing runs. A folder of clean transcripts proves the model can do the job on a good day; the failures tell you where to put the guardrail and when to route around it.

context is not custody

200K tokens of context doesn't buy 200K tokens of trust. It doesn't remove prefill time or retrieval noise, and it doesn't separate instructions you trust from documents you don't. If the API caches prompts, put stable system content first, keep volatile metadata away from the cache boundary, and send a structured checkpoint instead of full history when you can. Ask for restraint on output too: a decision plus its evidence is cheaper to generate and easier to review than an essay nobody asked for.

Tool calling changes the risk model in a way that's easy to gloss over. Z.AI may have sharpened function selection here, and I'd believe it. That doesn't move the job of validating arguments, authorizing the caller, capping side effects, deduplicating requests, or logging what happened, because that was never the model's job. Web pages, files, emails, and prior tool results are data the model reads, not instructions it obeys. A sharper model isn't a substitute for a narrower interface; give it fewer dangerous tools instead of trusting it to use them carefully.

the router should not care what's fashionable

Expose the smallest tool set that gets the job done and keep authorization outside the model, in configuration rather than in whatever a team remembers about which model is good this month. Log model identity, phase timings, token categories, tool outcomes, and eval results by default, and skip retaining sensitive prompt content unless you've decided you need it.

Keep a cheap, fast lane for routine work and a real escalation condition for the rest. The strongest model should only see requests that benefit from its extra capability, and a cheap tier stops being cheap once its retries and review overhead eat the savings it was meant to deliver. codex-model-dial covers the general shape of that dial; GLM-5.1 doesn't change the shape, only where the threshold sits.

Treat the upgrade as routine operations, not an event. Pin dated versions where stability matters, watch deprecation notices, canary a new alias before it touches all traffic, and keep a known-good fallback wired in. model-migration-reality walks through what usually goes wrong when a team skips one of those steps. Re-run your local eval set the moment the model, prompt, tool contract, or reasoning default changes.

What I'd check next, concretely: pull the tool-schema revision running in production today, point GLM-5.1 at it unchanged, and run it through the boundary cases above before touching a single prompt. If it doesn't clear your current pass rate on that exact test, it doesn't get a slot in the router yet.