How to use GLM-5.2 in Factory

GLM is a family of open-weight language models from Zhipu AI. Factory offers GLM natively, so you can run it inside a Droid without setting up your own inference endpoint or API key. If you have been searching for where to run GLM-5.2 for coding work, this is how it fits into Factory.

The short version: GLM-5.2 appears in Factory's model list alongside the Anthropic, OpenAI, Google, and xAI models, you select it the same way you select any other model, and Factory handles the inference and billing. The rest of this article covers the specifics.

What GLM is

GLM is an open-weight model series, which means the weights are published rather than served only through a single vendor's API. Factory groups GLM under its Droid Core open models, the set of open models it hosts and serves directly. Two versions are available today, GLM-5.2 and GLM-5.1, both listed on the Available Models page with their model IDs and settings.

Because Factory serves these models itself, GLM works across the surfaces where Droids run, not only in a local setup. You do not manage a GPU, a serving stack, or a provider key to use it.

Selecting GLM in a Droid

In an interactive session, run the /model command and pick GLM-5.2 from the list. You can also cycle through available models with Ctrl+N while the chat input is focused. The full set of interactive commands is in the Droid CLI reference.

For headless runs, pass the model ID directly with the -m flag:

droid exec -m glm-5.2 --auto medium "add validation to the signup form and run tests"

GLM-5.2 exposes reasoning levels of Off, High (the default), and Max; GLM-5.1 offers Off and High. Raise the reasoning effort for harder problems with Tab in interactive mode or the -r flag in droid exec. The exact levels per model are on the models page.

Cost and the credit multiplier

Factory bills model usage with a per-model credit multiplier, and GLM runs at one of the lower multipliers in the catalog. Both GLM-5.2 and GLM-5.1 are listed at 0.55x, which makes GLM a reasonable default for high-volume or exploratory work where you want to conserve credits. Check the current multiplier on the Available Models page before you standardize on it, since these values change.

The table below summarizes the GLM options as published.

When to reach for GLM

GLM is a good fit when you want an open model with a low credit multiplier for iteration, cleanup, or well-scoped changes, and you would rather not couple a workflow to a single closed provider. Keeping model choice open is the argument for a model-agnostic approach to agents, and Factory supports mixing models per task rather than locking to one.

For work where you want Factory to pick the model for each step automatically, Factory Router can route across the catalog instead of you setting a fixed model. When you do want deterministic control, setting -m glm-5.2 pins the run to GLM.

GLM in headless runs and Missions

The same model ID works everywhere the CLI runs, including CI. A GitHub Actions step can call droid exec -m glm-5.2 to keep automated tasks on a low-multiplier model. In Missions, where an orchestrator delegates to worker and validator agents, you can assign GLM to the worker role with --worker-model glm-5.2 while keeping a stronger model for validation. That lets you spend credits where reasoning matters most and economize on the rest.

If GLM is not the right model for a given task, switching is a one-line change, which is the point of keeping model selection open.

Further reading

• How to use Kimi K2 in Factory
• How to use MiniMax in Factory
• Why your AI agents should be model-agnostic
• Available Models