What is GLM-4.7?
GLM-4.7 is an open-weight mixture-of-experts language model from Z.ai. Its primary role is to handle demanding software-engineering and reasoning workflows: repository-level coding, terminal-based agents, tool use, technical research, frontend generation, and extended multi-turn collaboration.
A mixture-of-experts model contains multiple specialist subnetworks, or “experts.” Although the full GLM-4.7 system is listed at approximately 355 billion total parameters, Z.ai’s open-source materials identify approximately 32 billion active parameters for a given inference step. This design helps explain both the model’s capability target and the substantial hardware requirements associated with running the full model locally.
The canonical API identifier is glm-4.7. Z.ai offers the model through a chat-completions interface, and the weights are also distributed for local or self-hosted use. The released weights are identified as MIT-licensed in the supplied model-card research.
Where GLM-4.7 fits in Z.ai’s lineup
GLM-4.7 is part of Z.ai’s GLM family and is positioned as a coding- and reasoning-focused model rather than a general media model. The supplied research identifies GLM-5 and later GLM-5.x models as newer successors, but GLM-4.7 remains a separately identifiable and accessible model with its own API identifier, pricing, and downloadable weights.
That positioning matters when selecting it. GLM-4.7 is aimed at tasks where the model must maintain a large amount of context, reason through several steps, or interact with tools. It is not presented as a native vision, speech, music, or video system. Applications that need those modalities should use a model designed for them instead of treating GLM-4.7 as a universal input and output model.
Context, output, and supported modalities
Z.ai documents a 200,000-token context window. The context window is the amount of text and conversation state that can be supplied to the model during a request, including relevant instructions, source files, tool results, and previous turns. This makes GLM-4.7 suitable for large repositories, long technical documents, and agent sessions that need to preserve substantial state.
The documented maximum output is 128,000 tokens. That limit is unusually useful for tasks such as generating large code changes, detailed technical plans, or extended tool-assisted responses, although applications should still request only the output length they need because longer generation can increase latency and cost.
| Specification | GLM-4.7 |
|---|---|
| Provider | Z.ai |
| API model ID | glm-4.7 |
| Input | Text |
| Output | Text |
| Context window | 200,000 tokens |
| Maximum output | 128,000 tokens |
| Tool and function calling | Supported |
| Streaming | Supported |
| Structured output | Supported |
| Weights | Available under the MIT License |
GLM-4.7 is text-only in both directions according to the supplied documentation. It does not natively accept images, audio, or video, and it does not directly produce images, speech, music, or video. Structured text formats such as JSON are supported, but the research does not verify a distinct provider feature called JSON mode; structured output should therefore not automatically be treated as a separate JSON-mode guarantee.
Reasoning, coding, and agent behavior
GLM-4.7 is designed for tasks in which the model needs to plan before producing an answer or calling a tool. Its interleaved reasoning approach is intended to support multi-step execution, while preserved reasoning blocks can retain relevant reasoning state across turns in coding-agent scenarios. Z.ai also documents controls for enabling or disabling thinking and for changing reasoning behavior at the turn level.
These controls create a practical quality-versus-latency trade-off. More extensive reasoning can be useful when the task involves debugging, planning a repository-wide change, interpreting tool results, or deciding between several implementation paths. A lighter or disabled thinking configuration may be preferable for straightforward transformations, short answers, and latency-sensitive interactions. The supplied research does not define a universal quality improvement for every prompt, so these modes should be evaluated against the application’s workload.
Z.ai reports improvements over GLM-4.6 on coding, terminal-agent, tool-use, and reasoning evaluations. Reported results include 73.8% on SWE-bench Verified, 66.7% on SWE-bench Multilingual, 41% on Terminal Bench 2.0, and 42.8% on Humanity’s Last Exam with tools. These are provider-reported benchmark results, not independent guarantees of performance on a particular codebase or production workflow.
In practical use, the model’s coding focus is most relevant when an application needs more than code completion. Examples include inspecting a repository, proposing a plan, editing several related files, running or interpreting terminal commands, responding to test failures, and continuing through multiple tool calls. Its long context can also help keep specifications, implementation details, and prior tool output available during an extended session.
Tools, streaming, and structured responses
GLM-4.7 supports function calling, which allows an application to describe external operations—such as searching a codebase, running a test, querying a database, or creating a ticket—and let the model request those operations in a structured way. The application remains responsible for executing the function, validating arguments, handling permissions, and deciding whether a requested action is safe.
Streaming is also supported. Rather than waiting for the entire response, a client can receive generated text progressively. Streaming is useful for interactive interfaces and long responses, but it does not remove the underlying generation cost or make an unusually complex task instantaneous.
The model supports structured output formats such as JSON. This is useful when the surrounding application needs predictable fields rather than free-form prose—for example, a code-review result containing a severity, file location, explanation, and suggested fix. Developers should still validate the returned structure and handle refusals, incomplete output, and values that do not satisfy application constraints.
GLM-4.7 API pricing
The supplied pricing research reports Z.ai API pricing of $0.60 per 1 million input tokens and $2.20 per 1 million output tokens. These are token-based prices rather than a fixed monthly subscription. Input tokens include the material sent to the model, while output tokens are generated by it; a long context and a lengthy response can therefore produce different costs even for similar requests.
The pricing figures come from a secondary pricing reference in the supplied research, while the official Z.ai documentation confirms the model and API details. Cache pricing may vary by access route, so teams should verify the current billing page before estimating production expenditure. Because output tokens cost more than input tokens in the reported pricing, applications can reduce spending by limiting unnecessary response length, avoiding repeated context where caching is available, and selecting a lower-cost model for simple tasks.
API access versus local deployment
The hosted API is the simpler way to use GLM-4.7 when the priority is access to the model without assembling the infrastructure required for a very large mixture-of-experts system. The API also avoids the operational work involved in downloading weights, configuring inference software, managing memory, and scaling requests.
Local deployment may be attractive when an organization needs control over its serving environment, wants to inspect or modify an open-weight model, or has suitable infrastructure. Z.ai’s open-source materials reference deployment paths involving Transformers, vLLM, SGLang, and ModelScope. However, the approximately 355-billion-parameter total model size means that full-precision self-hosting is substantially more demanding than serving a small model. Quantization and optimized inference may change the hardware calculation, but the supplied research does not establish a specific minimum hardware configuration.
When to choose GLM-4.7
Choose GLM-4.7 when the workload benefits from a large context, deliberate multi-step reasoning, and interaction with external tools. Strong use cases include:
- Repository-level software engineering and code review.
- Terminal or browser-style agents that must plan, call tools, inspect results, and continue.
- Complex debugging and implementation tasks involving several related files.
- Long technical documents, specifications, and research-oriented workflows.
- Frontend generation and iterative UI development.
- Applications that need function calling, streaming, or structured text responses.
Another option may be more appropriate when speed is the dominant requirement, when the task is simple enough for a smaller model, or when the application needs image, audio, video, or other non-text capabilities. A smaller or specialized model can also be easier and cheaper to self-host. Conversely, GLM-4.7 is a better candidate than a lightweight text model when the additional reasoning, context capacity, and agentic coding behavior justify its higher computational demands.
Important limitations
GLM-4.7’s modality limitation is straightforward: it is a text-in, text-out model. It should not be selected as a native image-understanding or media-generation system. Its large architecture is another important limitation for local deployment, particularly for individuals or teams without substantial inference hardware.
Reported benchmark scores should also be interpreted as directional evidence rather than a promise for every project. Coding performance depends on the repository, language, tests, tool definitions, prompt design, and the quality of the surrounding agent loop. Similarly, a 200K context window does not mean that every task improves when the entire window is filled; relevant context selection and clear tool outputs still matter.
Overall, GLM-4.7 is most compelling as a text-based engineering and reasoning model for users who value long context, configurable thinking, tool use, and open-weight availability. Its cost and deployment trade-offs are reasonable for those workloads, but a smaller, faster model or a modality-specific system may be the better choice for simpler or non-text applications.