What GLM-4.7-REAP-268B-A32B is
GLM-4.7-REAP-268B-A32B is a sparse mixture-of-experts, or MoE, causal language model published by Cerebras. It is derived from Z.ai's GLM-4.7 and is distributed as an open-weight checkpoint under the MIT license. The checkpoint is intended for users who want to run, evaluate, or adapt a large language model under their own infrastructure rather than use a hosted endpoint with a published per-token price.
The model's defining feature is REAP, short for Router-weighted Expert Activation Pruning. In an MoE model, many specialist subnetworks called experts are available, but only a subset is activated for each token. REAP removes lower-impact experts instead of merging all their weights together. The remaining experts stay independently addressable by the router, which Cerebras describes as a way to reduce the model's memory footprint while preserving the architecture's routing behavior.
After pruning, the model contains approximately 268 billion total parameters and activates about 32 billion parameters per token. This makes it smaller than the approximately 355-billion-parameter original GLM-4.7, but it is still a very large model. The compression should therefore be understood as a reduction in deployment requirements, not as a transformation into a lightweight local model.
Architecture, context, and deployment implications
The model card reports 120 remaining experts, with eight experts activated for each token. It has 92 layers and uses grouped-query attention with 96 query heads and eight key-value heads. These are verified specifications reported for this checkpoint, rather than independent benchmark results.
Its stated context length is 202,752 tokens. In practical terms, that provides room for large code repositories, long technical documents, extended conversations, and multi-step agent traces. The advertised context length does not guarantee that every deployment can use the full window efficiently. Usable capacity depends on available accelerator memory, quantization, runtime configuration, sequence limits, and the number of simultaneous requests.
No maximum output-token limit is specified in the supplied model-card research. A deployment may impose its own generation limit, but that should not be confused with a verified model-wide maximum. Similarly, no official hosted input or output price is specified for this exact checkpoint.
The checkpoint is available through Cerebras on Hugging Face and can be loaded with Transformers. The model card reports compatibility with recent vLLM releases and gives deployment guidance involving tensor parallelism, expert parallelism, automatic tool choice, and the GLM tool-call parser. Because the model has approximately 268 billion total parameters, practical inference generally requires substantial accelerator capacity. Quantization and conservative choices for context length or concurrency may be necessary.
Capabilities and supported modalities
GLM-4.7-REAP-268B-A32B accepts text and produces text. It does not natively generate images, audio, video, speech, or embeddings according to the supplied model data. It should therefore be evaluated as a text-only language model, even though its text capabilities can be used in applications that interact with other tools or media systems.
Its intended workload includes software development, repository-scale code understanding, multi-turn reasoning, agentic workflows, and function calling. Function calling allows an application to describe external operations, such as searching a database or running a build command, and have the model produce a structured tool request for the application to execute. The model card's vLLM instructions specifically address tool-call parsing and automatic tool selection.
These features do not mean that the model independently performs external actions. The surrounding application remains responsible for defining tools, validating arguments, executing requests, handling failures, and enforcing permissions. The model supplies text or tool-call output; the host system supplies the actual capabilities.
Main strengths and trade-offs
- Lower requirements than the source model: REAP removes 25% of the original experts, producing a checkpoint with approximately 268B total parameters rather than the roughly 355B reported for the original GLM-4.7.
- Long-context support: The reported 202,752-token context window is useful for large repositories, long documents, and extended agent sessions when the deployment can support it.
- Strong fit for code and tool use: The model is designed for coding, reasoning, function calling, and agentic workflows rather than image or audio tasks.
- Open-weight deployment: The MIT license and Hugging Face checkpoint support self-managed evaluation and inference, subject to the hardware and software requirements of the deployment.
- Still expensive to operate: Although compressed, a 268B-parameter MoE checkpoint remains far larger than conventional local models. Memory, parallelism, quantization, and operational complexity are important considerations.
- No simple hosted price comparison: The supplied research does not identify an official per-token price for this exact artifact, so its financial advantage cannot be established against hosted alternatives from pricing data alone.
The practical trade-off is therefore capability and capacity versus speed, simplicity, and cost. A large self-hosted MoE can be attractive for organizations that need control, long context, or experimentation with the GLM-4.7 architecture. A smaller model or a managed service may be more appropriate when fast setup, low hardware requirements, predictable billing, or high request throughput matters more.
Reasoning, coding, and tool use
The supplied evaluation fields rate the model's reasoning at 8 out of 10 and coding at 9 out of 10. These are editorial or database evaluations, not provider-published benchmark scores, so they should be treated as comparative guidance rather than measured facts. The official positioning supports using the model for reasoning-heavy coding tasks, repository analysis, and multi-step agent workflows, but the supplied research does not provide benchmark numbers for the BF16 checkpoint.
The model card refers to evaluation results for an FP8 variant, while BF16 results were listed as pending at the time of verification. Results from the FP8 variant should not automatically be presented as results for this exact BF16 checkpoint. Users comparing deployments should also account for quantization, runtime, prompt format, tool definitions, and concurrency because these factors can affect observed performance.
For coding, suitable tasks include examining a large codebase, proposing changes across several files, explaining unfamiliar implementation details, generating code, and participating in tool-assisted development workflows. For agentic use, its long context can help retain plans, tool results, and repository information across a longer interaction. However, long context increases memory and latency demands, and a model-generated tool call still requires application-side validation.
Pricing and availability
There is no verified provider-published input or output price for GLM-4.7-REAP-268B-A32B in the supplied research. The model is presented as a Hugging Face checkpoint for self-hosted or research deployment, not as an item with a stated Cerebras per-token API tariff. Accordingly, pricing depends on the user's infrastructure, accelerator rental or ownership costs, quantization strategy, power consumption, and operational setup.
The model is distributed under the MIT license. That permissive license can simplify many forms of use, but users should still review the checkpoint's documentation and their own obligations before deploying it commercially or incorporating it into a larger product.
When to choose this model
Choose GLM-4.7-REAP-268B-A32B when you need an open-weight GLM-4.7-derived model for self-managed inference and your infrastructure can accommodate a very large MoE checkpoint. It is particularly relevant for:
- coding assistants that need repository-scale context;
- research into expert pruning, sparse models, or long-context inference;
- agentic applications that use function calling and several sequential tools;
- organizations that prefer an MIT-licensed checkpoint over a closed hosted model; and
- experiments where reducing the original GLM-4.7's expert count is useful.
Another option may be more appropriate if the target device has limited memory, if low latency is the overriding requirement, or if the application needs native image, audio, video, speech, or embedding output. A hosted model may also be preferable when the team wants usage-based billing and managed scaling instead of provisioning the hardware and runtime stack itself. Conversely, users who require the uncompressed GLM-4.7 checkpoint should not treat this REAP version as an identical replacement: it is a pruned derivative with a different parameter count and deployment profile.
Limitations to check before deployment
The most important limitation is scale. Approximately 268B total parameters remains a substantial operational burden, even though only about 32B parameters are active per token. Sparse activation can reduce computation relative to a dense model of the same total size, but it does not eliminate the need to store and distribute the model's experts.
There is also incomplete published information for some production decisions. The supplied research does not verify a maximum output length, hosted API pricing, a knowledge-cutoff date, fine-tuning support, caching, batch API availability, or a distinct JSON-mode guarantee for this checkpoint. Those features should not be assumed from the presence of tool-calling guidance. Deployment teams should validate them in the exact runtime and checkpoint format they plan to use.
Overall, GLM-4.7-REAP-268B-A32B is best understood as a large, open-weight, text-only MoE checkpoint that trades some model size for a more manageable deployment profile. Its strongest case is self-hosted coding, reasoning, long-context research, and tool use where the operator can support the hardware and engineering complexity.