GLM-4.5 Air Guide: 12B Active, MIT Weights, One-Node Serving

GLM-4.5 Air is easy to overlook. It shipped in July 2025 as the smaller half of the GLM-4.5 launch, the headlines went to the 355B flagship, and Z.ai has released several generations since. But Air has a property the flagship GLM line has since left behind: it is small enough that one well-specified server can run it, and its weights are MIT-licensed.

That makes it less a frontier model and more a piece of infrastructure. This guide covers what it is, what it needs, and the specific situations where it is still the sensible choice in late 2026.

What Air actually is

Z.ai's model card describes GLM-4.5 Air as a mixture-of-experts model with 106B total parameters and 12B active per token. The full GLM-4.5 is 355B total with 32B active. Both share the same design goals: agent work, tool calling, and a hybrid reasoning setup where a thinking mode handles complex problems and a non-thinking mode answers quickly.

Z.ai's documentation lists a 128K context window and a 96K maximum output for the GLM-4.5 series, text in and text out. OpenRouter's catalogue matches that, listing a 131,072-token context and reasoning and tool calling as supported features.

On Z.ai's own aggregate of 12 benchmarks, the vendor reports 59.8 for Air against 63.2 for the full model. That is a vendor-chosen suite, so treat the gap as directional rather than precise, but it is a useful sanity check: Air gives up a few points, not half the capability.

Air also matters as a foundation. GLM-4.5V, Z.ai's vision-language model from August 2025, is built on Air. If you have used that model, you have used Air underneath. See the GLM-4.5V guide for that side of the family.

What 12B active buys you

Total parameters decide how much memory you need. Active parameters decide how much compute each token costs. Air's 12B active is roughly three-eighths of the full model's 32B, which shows up directly in tokens per second and in how many concurrent requests a node can serve. Active vs total parameters goes into why that ratio matters more than the headline size.

The price reflects it. Z.ai's pricing page lists GLM-4.5 Air at $0.20 per million input tokens and $1.10 per million output, against $0.60 and $2.20 for GLM-4.5. OpenRouter listed Air at about $0.13 input and $0.85 output per million tokens at the time of writing, with third-party hosts competing on the rate. Prices move; check before you budget.

Running it yourself: the hardware maths

This is where Air separates from almost everything else in the GLM line. Z.ai's GitHub README for the GLM-4.5 series gave these inference requirements at launch:

• BF16 weights: four H100s or two H200s.
• FP8 weights: two H100s or a single H200.
• LoRA fine-tuning: four H100s.

For comparison, the full GLM-4.5 needs sixteen H100s or eight H200s in BF16, and eight H100s in FP8. The README also notes that serving the full 128K context needs twice as many GPUs than these minimums, so plan for your actual prompt lengths, not the advertised maximum.

A single-H200 FP8 deployment is the kind of thing a small team can actually rent, run, and reason about. That is the real case for Air: an open model with tool calling and a reasoning mode, sized so that self-hosting is a configuration problem rather than a cluster project. Whether that is cheaper than an API depends on your utilisation; the self-hosting break-even point walks through the inputs honestly.

Air or the full GLM-4.5

The two models were released together and are meant to be chosen between. A short rule:

• Pick Air for high-volume, bounded work: classification, extraction, short tool-calling loops, summarisation, and anything you want to self-host on one node. Lower latency and a lower rate compound over volume.
• Pick GLM-4.5 when tasks are long and unattended, when a failed run is expensive, or when you have measured a quality gap on your own tasks that the price difference does not cover. The GLM-4.5 guide covers that model in detail.

The common pattern is to use both: Air first, escalate to the larger model on failure or low confidence. Because they share a prompt format and a reasoning toggle, routing between them is unusually painless.

Where it sits in late 2026

Be honest about the date. Air is more than a year old, and Z.ai has shipped GLM-4.6, GLM-4.7, the GLM-5 line and small models like GLM-4.7 Flash since. Its 128K context is now modest, and its knowledge cutoff is listed as the end of 2024.

For new hosted workloads where you never touch the weights, a newer small model is usually the better starting point. GLM-4.7 Flash in particular is a 30B-class model with a 200K context that Z.ai serves for free on its own API. Air keeps its place where you already run it, where you have fine-tuned it, or where its size and licence fit a deployment you control.

On the variants: Z.ai publishes Air as BF16 and FP8 weights plus a base model for fine-tuning, and its API also lists a faster, pricier AirX tier. On OpenRouter it appears as a single z-ai/glm-4.5-air endpoint.

A sensible test plan

1. Take twenty tasks from your real workload, weighted towards the bounded jobs Air is meant for.
2. Run each with thinking enabled and disabled. For many extraction and routing jobs, non-thinking mode is faster and just as accurate.
3. Run the same set on the full GLM-4.5 and record cost per completed task, not cost per token.
4. If you plan to self-host, test the FP8 weights specifically; quantised and full-precision outputs are close but not identical.

If Air completes most of the set and the failures are recognisable, a cheap-first routing setup will probably serve you better than either model alone.