GLM-5.3

Overview

GLM-5.3 is the latest release in the GLM family of language models from Z.ai. It is published as an open-weight model, which means the trained weights can be downloaded and run on your own infrastructure, subject to the license. It is known for strong coding ability and reliable tool use, which makes it a natural fit for open-weight coding assistants and agent workloads where a team wants control over cost, data and deployment.

This article explains what GLM-5.3 is for, how models in this family are built and used, and how to run, adapt and evaluate it. Exact figures such as parameter counts, context length and benchmark scores change between releases, so always confirm them on the official model card. Here the focus is on durable concepts. The last sections explain how an open-weight coding and agent model supports workflows around tabular data and tabular foundation models, such as TabPFN, TabICL and TabSTAR.

What it is

GLM-5.3 is a large language model, a neural network based on the transformer architecture that reads text and writes text. It is designed as a general model with particular strength in two areas.

• Coding. Writing, explaining, reviewing and fixing code, and working across files in a repository.
• Tool use and agents. Deciding when to call a tool, producing valid arguments, reading the result, and continuing a multi-step task, see function calling and ReAct loop.

"Open-weight" is a precise term. It means the weights are available. It does not always mean that the training data, the training code or every right to reuse is open. Read the license to learn what you may do with the model, for example commercial use, redistribution and fine-tuning.

An analogy: a closed model served by an API is like a restaurant. You order, you get a dish, and you never see the kitchen. An open-weight model is like receiving the recipe and the ingredients to cook in your own kitchen. You gain control, privacy and the ability to adjust the dish, and you take on the work of running the kitchen.

The kinds of work it suits

Model family context

The GLM name began with a research line on general language model pre-training with autoregressive blank infilling, published around 2021. Later releases moved to large decoder-style chat and agent models, often with long context and, in recent generations, mixture-of-experts designs in which only part of the network is active for each token. The numbering, such as 5.3, marks a release within a generation. Treat the family history as a guide and check the release notes for what changed in this version.

Where it came from

GLM comes from the research community around Tsinghua University and the company now known as Z.ai, which was earlier called Zhipu AI. The first GLM work proposed a pre-training objective that blanks out spans of text and asks the model to regenerate them in order, combining ideas from bidirectional encoders and left-to-right decoders. This produced a model good at both understanding and generation.

Over successive generations, the family grew in size and capability and released open weights at several points. The ChatGLM line brought the models to chat use and to the open-source community, including smaller versions that ran on a single consumer graphics card. Later GLM generations added longer context, better reasoning and coding, and stronger agent behavior. Recent generations have been described as using mixture-of-experts layers, a design discussed in mixture of experts, and as targeting coding and tool-use benchmarks. The fifth generation continues this direction, and GLM-5.3 is a release in it.

Alongside the model, the surrounding ecosystem matured: runtimes such as vLLM, SGLang and llama.cpp, formats such as GGUF, and tuning libraries such as PEFT, TRL and Axolotl. Open-weight models from several groups compete in this space, for example Qwen, DeepSeek, Kimi and Gemma, and the competition pushes quality up and cost down.

How it works

This section describes how a model of this kind works in general. Details for GLM-5.3, such as layer counts and expert counts, are on its model card.

Step 1: Text becomes tokens

The input is split into tokens by a tokenizer, see BPE and SentencePiece. Code is tokenized too, and a tokenizer that handles code well uses fewer tokens per line, which saves cost and context.

Step 2: Tokens become vectors

Each token is mapped to a vector called an embedding. Position information is added so the model knows the order, commonly with rotary position methods.

Step 3: Layers of attention and feed-forward blocks

The vectors pass through many transformer layers. In each layer, attention lets every token look at earlier tokens and gather relevant context, like a reader glancing back at earlier paragraphs. A feed-forward block then transforms each token's representation. Efficient kernels such as FlashAttention make this fast.

Step 4: Mixture of experts

In a mixture-of-experts model, the feed-forward block is split into many experts, and a small router picks a few experts for each token. Think of a hospital with many specialists. A triage nurse sends each patient to the two or three doctors who fit, so the hospital can employ a huge number of specialists while each patient sees only a few. This is how a model can have a very large total parameter count while using only a share of it per token. The trade-off is that all experts must still be stored in memory, even if only some are active.

Step 5: Predict the next token

The final vector is converted into probabilities for the next token. The system picks one, appends it, and repeats. Settings such as temperature control how random the choice is.

Step 6: Training stages

A model of this type is built in stages.

Coding and agent ability often benefits from reinforcement learning with checkable rewards. For code, a unit test either passes or fails, which gives a clean signal. For agents, the reward can be whether a task in a sandbox ended in the right state, see sandboxing.

Step 7: Tool use at inference

When used as an agent, the model receives a list of tool descriptions. It outputs a structured call, your code runs the tool, and the result goes back into the context. The loop continues until the model gives a final answer. See structured outputs, MCP and agent memory.

Step 8: Serving

For production, the weights are loaded into a serving engine that batches requests, manages the key-value cache and streams tokens. Quantization shrinks the model to fit smaller hardware, see AWQ, GPTQ, bitsandbytes and ExLlamaV2.

Key concepts and terms

A worked example

This example shows a tool-calling loop against a self-hosted GLM-5.3 endpoint that speaks an OpenAI-compatible API, as many serving engines do. The host and model name are placeholders. Check the model card for the exact served name and recommended sampling settings.

import json
from openai import OpenAI

client = OpenAI(base_url="http://llm.example.internal:8000/v1", api_key="placeholder")

tools = [{
    "type": "function",
    "function": {
        "name": "run_sql",
        "description": "Run a read-only SQL query on the analytics database",
        "parameters": {
            "type": "object",
            "properties": {"query": {"type": "string"}},
            "required": ["query"],
        },
    },
}]

def run_sql(query: str) -> str:
    # In real code, execute against a read-only replica with a row limit
    return json.dumps([{"region": "north", "orders": 120}, {"region": "south", "orders": 95}])

messages = [{"role": "user", "content": "Which region had more orders last week?"}]

while True:
    resp = client.chat.completions.create(model="glm-5.3", messages=messages, tools=tools)
    msg = resp.choices[0].message
    if not msg.tool_calls:
        print(msg.content)
        break
    messages.append(msg)
    for call in msg.tool_calls:
        args = json.loads(call.function.arguments)
        messages.append({"role": "tool", "tool_call_id": call.id,
                         "content": run_sql(**args)})

Serving the weights yourself

A typical launch with a high-throughput engine looks like the following. The path is a placeholder, and parallelism settings depend on the model size and your hardware.

vllm serve /models/glm-5.3 \
  --served-model-name glm-5.3 \
  --tensor-parallel-size 8 \
  --max-model-len 65536 \
  --gpu-memory-utilization 0.90

A sizing walk-through

Memory for weights is about the parameter count times the bytes per parameter. A model with N total parameters needs roughly N times 2 bytes in 16-bit precision, N times 1 byte in 8-bit and N times 0.5 bytes in 4-bit, plus room for the KV cache and activations. For a mixture-of-experts model, N is the total, not the active, count, since every expert must be resident. The table shows how to reason about it.

The 100 billion figure is an example for the arithmetic, not a statement about GLM-5.3. Look up the real size and then plan hardware, such as NVIDIA H100, H200 or B200 class devices, with enough devices to hold weights and cache.

A coding workflow example

A review agent can be built with three tools: read a file, run tests, and post a comment. The loop is: read the diff, call tests, read failures, propose a fix, run tests again. Keep each tool narrow, return short outputs, and cap the number of steps. See long-running tasks and sub-agents for patterns that keep long jobs on track.

Evaluating GLM-5.3 on your own work

Public leaderboards are a starting point, not a decision. Build an evaluation that reflects the jobs you need done.

A coding evaluation

1. Collect 50 to 200 real tasks from your own repositories: bug fixes, small features, test writing and refactors.
2. For each task, store the starting commit, the instructions and an automated check, such as a test suite.
3. Run the model in a sandbox with the same tools your agent will have.
4. Record pass rate, number of steps, tokens used and wall-clock time.
5. Review failures by hand and sort them into causes: wrong plan, bad tool call, missing context, flaky test.

A tool-use evaluation

Create scripted scenarios with a fixed set of tools and known correct call sequences. Check that the model picks the right tool, fills arguments correctly, handles an error result, and stops when finished. Include distractor tools and ambiguous requests, since real agents face both.

A table-workflow evaluation

For data work, test whether the model produces correct code for common tasks: joins, group-bys, type fixes, missing-value handling and train and test splits. Execute the code on small fixtures and compare outputs with expected tables. Include tricky cases such as duplicate keys, mixed date formats, and numeric columns stored as text.

Regression tracking

Keep the evaluation set fixed and rerun it for each model upgrade, quantization choice and prompt change. Store results with the model version, so you can compare over time, see MLflow and promptfoo. Use judges only as a helper, and calibrate them against human review, see LLM-as-judge and RAGAS for retrieval cases.

Prompting and configuration tips

System prompts for coding agents

A good system prompt states the role, the rules for editing files, how to run tests, how to report progress and when to stop and ask. Keep it short and concrete. Avoid vague advice such as "write good code". Prefer rules the model can check, such as "run the test command after each edit and report the result".

Sampling settings

Lower temperature suits code and tool calls, where precision matters. Higher temperature suits brainstorming. Follow the recommended values on the model card, and change one setting at a time when you test.

Reasoning mode

Some releases in this family can think before answering, writing intermediate reasoning that improves results on hard problems at the cost of more tokens and latency. Use it for planning and debugging, and switch it off for simple lookups and high-volume steps. Always confirm how the feature is exposed for the exact release you serve.

Long context use

A long context window lets the model read many files at once, but quality can drop for details buried in the middle, and cost rises with length. Retrieve the relevant files instead of pasting everything, see contextual retrieval, hybrid search and LlamaIndex. Summarize older steps in long agent sessions, see agent memory.

Structured output

When another program consumes the output, ask for JSON that matches a schema and validate it, see structured outputs and Pydantic AI. Retry with the validation error as feedback if parsing fails.

Cost and capacity planning

Self-hosting changes the cost model from per-token pricing to per-hour hardware. The break-even depends on your volume and how well you keep accelerators busy.

A simple method: measure tokens per second per replica under realistic load, divide the hourly hardware cost by tokens per hour, and compare with the managed price per token for a model of similar quality. Re-do this when a new release or a new serving engine changes throughput. See cost and latency budgets.

Reliability

Plan for failures. Run at least two replicas for important traffic, add health checks, and keep a fallback route to another model. Use rate limits per user to protect capacity. Observe latency, queue depth and error rates, see Prometheus and Grafana. Deploy with containers and orchestration, see Docker, Kubernetes and KServe.

Strengths and limitations

Strengths

• Open weights give control over deployment, data residency and cost per token at scale.
• Strong coding and tool-use focus suits agent products.
• Can be fine-tuned on your own tools, code style and data, see SFT and LoRA.
• Works with the common serving stack and OpenAI-style APIs.
• Can be inspected, evaluated and red-teamed without relying on a vendor.
• Mixture-of-experts designs offer high capacity at lower per-token compute.

Limitations

• Running it yourself needs substantial hardware and operations skill.
• A large total parameter count means large memory even if few parameters are active.
• Open weights do not remove the need for guardrails, see guardrails and prompt injection defense.
• License terms vary. Read them before commercial use.
• Quality on your task must be measured. Public benchmark rankings do not predict every workload.
• Closed frontier models may lead on the hardest tasks, and the gap changes with each release.
• Agent behavior can be brittle on long tasks without good scaffolding and evaluation.

How it compares with alternatives

A practical pattern is to route. Use a managed frontier model for the hardest steps, and an open-weight model like GLM-5.3 for high-volume, private or latency-sensitive steps. Measure on your own tasks before choosing, see evals and cost and latency budgets.

Role in tabular foundation models

GLM-5.3 is a language model and not a table-native model. Tabular foundation models such as TabPFN, TabICL, TabSTAR and XTab learn from raw tables: they handle rows and columns, mixed numeric and categorical types, missing values, and often no column names, and they are pre-trained on many tables, frequently synthetic ones, so that they can predict through in-context learning. The relation between the two kinds of model is complementary. See /model/research and /model/architecture for the table-native design.

The language model as builder and orchestrator

A coding and tool-use model is well suited to the work around a table model.

An agent can wrap a table model as a tool. For example, a "predict_missing" tool takes a table reference and a column name and returns imputed values from the table model. The language model decides when to call it, checks the output for sanity and writes the summary. This keeps numeric work in the model built for it and uses the language model for planning and communication.

Why the language model is not a replacement for a table model

Language models can read a small table pasted as text, but they struggle with large numeric tables. Long tables use many tokens, numbers are tokenized into pieces, and the model has no built-in notion of columns as distributions. A table-native model processes cells as numbers and categories and uses row and column attention, see axial attention and FT-Transformer. For prediction on tabular data, table-native models and tree ensembles, see XGBoost, LightGBM and CatBoost, are usually the better tools, and the language model should coordinate them.

Handling missing values, mixed types and unnamed columns

When a language model assists with such tables, it can do three useful things. It can inspect the values and propose a type for each column when names are absent. It can write code that marks missing values consistently, since real data uses many spellings such as blanks, zeros and sentinel codes. And it can document the assumptions it made. A human should review these, as a wrong type guess leads to wrong features.

Anomaly detection and sector classification

For anomaly detection, a language model can generate the rules and explain flags, while a table model or an isolation forest does the scoring, see anomaly detection. For semantic or sector classification, it can map column descriptions to a taxonomy, or label tables by domain, which pairs well with sector heads in a table model, see semantic sector heads.

Tuning it for table work

You can fine-tune GLM-5.3 so that it knows your table tools, your schema conventions and your data quality rules. Build SFT data that pairs a task, such as "impute column X for table Y", with the correct tool calls and a final summary. See SFT, LoRA and full fine-tuning. Keep real data out of public prompts, and use synthetic or masked tables when you build examples, see synthetic data generation.

Privacy advantage of self-hosting

Tables often hold personal or confidential data. Running an open-weight model inside your own network means rows never leave your environment. Combine this with masking and tokenization, see data tokenization, Presidio and format-preserving encryption.

An end-to-end scenario: imputing a table with an agent

Suppose an analyst has a table of equipment readings with gaps and columns named only c1 to c12. A GLM-5.3 agent with three tools can handle the job.

1. profile_table. Returns row count, per-column type guesses, missing share and a few sample values.
2. impute_with_table_model. Sends the table to a table-native model endpoint and returns completed values and a per-cell confidence.
3. write_report. Saves a short summary and a list of cells that need review.

The agent calls the profile tool first, reads that c4 looks like a date, c7 has 31 percent missing values and c9 holds codes. It then calls the imputation tool, checks that imputed values stay inside plausible ranges, and flags low-confidence cells for a person. The language model never invents numbers. It routes, checks and reports.

tools_spec = [
    {"name": "profile_table", "args": {"table": "str"}},
    {"name": "impute_with_table_model", "args": {"table": "str", "columns": "list[str]"}},
    {"name": "write_report", "args": {"path": "str", "text": "str"}},
]

# Guard rails around the agent loop
MAX_STEPS = 12
ALLOWED_TABLES = {"readings_2026_q3"}

def check_call(name: str, args: dict) -> None:
    if args.get("table") and args["table"] not in ALLOWED_TABLES:
        raise PermissionError("table not allowed")

Where the pieces sit

Teaching the language model about table models

The agent needs to know what the table model can and cannot do. Put a short, accurate description in the tool metadata: which task types are supported, the limits on rows and columns, how missing values are represented and what the confidence output means. Wrong tool descriptions are a common cause of misuse. Keep them tested like code.

Practical guidance and best practices

Before you adopt it

• Read the model card for size, context length, license, recommended sampling settings and chat template.
• Build a small evaluation set from your real tasks, with pass or fail checks where possible.
• Compare against at least one managed model and one smaller open model.
• Estimate hardware and cost per million tokens at your expected load.

Deploying

• Serve with an engine such as vLLM or SGLang, behind an authenticated gateway.
• Use the exact chat template and tool format from the model card.
• Start with a quantized variant if memory is tight, then compare quality against 16-bit.
• Set limits: maximum tokens, step count and timeouts.
• Log prompts and outputs with care for privacy, see Langfuse and OpenTelemetry.
• Add caching for repeated prompts and a fallback route for outages.

Building agents

• Give each tool a clear name, a short description and a strict schema, see OpenAPI and Pydantic AI.
• Return concise tool outputs and error messages the model can act on.
• Run code in a sandbox with no network by default, see sandboxing.
• Require human approval for risky actions, see human-in-the-loop.
• Use frameworks such as LangGraph or the Claude Agent SDK for orchestration, and keep the loop simple.
• Evaluate end-to-end task success, not only single replies, see evals and LLM-as-judge.

Fine-tuning

• Start with prompts and few-shot examples. Tune only after you see a stable gap.
• Prefer LoRA or QLoRA for most adaptations of a large model.
• Keep a general regression suite to catch forgetting.
• Version data, config and weights together, see MLflow.

Security

• Treat all retrieved text and tool output as untrusted, see prompt injection defense and OWASP.
• Give agents least-privilege credentials, see OAuth for tool access and zero trust.
• Red-team before launch, see red teaming.

Governance for self-hosted models

Treat the model like any other critical component. Record which version is deployed, who approved it, which evaluation it passed and how to roll back. Keep a change log for prompts and tool definitions, since a small edit can change behavior as much as a new model. Review access to the serving endpoint, and separate keys for testing and production. For regulated data, document where prompts and outputs are stored and for how long, see GDPR and data lineage.

Upgrading to a new release

When a newer GLM release appears, run your fixed evaluation first, then shadow traffic, then a small rollout. Do not assume that a higher number is better on every task. Check coding, tool use, latency, cost and safety, and keep the old version available until the new one has proved itself.

Documentation for users

Publish a short guide for the people who will use the system: what it is good at, what it should not be used for, how to report a bad answer and who owns the service. Clear expectations reduce misuse and speed up feedback.

Common mistakes

• Trusting a benchmark rank. A model that tops a public coding list may still fail on your codebase. Test on your own tasks.
• Using the wrong chat or tool template. Odd behavior and broken tool calls usually trace back to template mismatch.
• Planning memory by active parameters. In a mixture-of-experts model, all experts must be loaded. Size hardware by total parameters.
• Skipping quantization tests. A lower-bit model can lose accuracy on code. Compare with the 16-bit version.
• Giving agents broad permissions. An agent with write access to a production database can do damage if it errs or is tricked.
• Unbounded loops. Without step and cost limits, an agent can run in circles.
• Pasting large tables into prompts. It wastes tokens and gives weak numeric results. Call a table model or a database instead.
• Putting secrets in prompts. Prompts may be logged. Keep credentials in tools, not in text.
• Ignoring the license. Open weights still come with terms.
• Fine-tuning too early. Many gaps close with better prompts, retrieval or tool design.
• No monitoring. Model behavior changes with inputs and with upgrades. Track quality in production.

Frequently asked questions

What is GLM-5.3?

GLM-5.3 is the latest release in the GLM family of language models from Z.ai, offered as open weights and known for strong coding and tool-use ability. It is used for coding assistants, agents and other workloads where a team wants to run the model on its own infrastructure.

Does open-weight mean open-source?

Not necessarily. Open-weight means the trained weights can be downloaded and run, under a license. Open-source in the strict sense also implies open code, often open data and broad rights to reuse. Always read the license of a given release to see what commercial use, redistribution and fine-tuning are allowed.

Can I run GLM-5.3 on a single GPU?

It depends on the size of the release you choose and on quantization. Large mixture-of-experts models usually need several high-memory accelerators, while smaller or heavily quantized variants may fit on fewer devices. Check the parameter count on the model card, multiply by the bytes per parameter for your precision, and add room for the cache.

Is GLM-5.3 good for coding?

It is positioned for coding and tool use, and that is the main reason teams evaluate it. How well it works for you depends on your languages, your codebase and your workflow, so run it against your own tasks with automated tests before relying on public leaderboards.

How do I use GLM-5.3 as an agent?

Serve it with an engine that supports tool calling, describe your tools with strict schemas, and run a loop in which the model proposes a call, your code runs it and returns the result, and the model continues until done. Add limits, a sandbox for code execution and human approval for risky actions.

Can I fine-tune GLM-5.3?

Usually yes, subject to the license. Most teams use LoRA or QLoRA to adapt a model of this size to their tools or style, since full fine-tuning needs a lot of memory. Begin with prompting and few-shot examples, and fine-tune only when a measured gap remains.

How does GLM-5.3 relate to tabular foundation models?

They are different kinds of model that work well together. A tabular foundation model learns from raw tables and predicts directly, while GLM-5.3 can write the data preparation code, call the table model as a tool, explain results in plain language and generate evaluation scripts. The language model orchestrates, and the table model does the numeric prediction.

Can GLM-5.3 replace a tabular model for prediction?

For anything beyond tiny tables, it is usually not the right tool. Language models process numbers as tokens and tables as long text, which is costly and less accurate than a table-native model or a tree ensemble. Use it to plan and explain, and let a model built for tables make the predictions.

Is it safe to send private tables to a self-hosted model?

Self-hosting keeps data inside your network, which removes the third-party transfer, but you still need access controls, logging policies and masking of sensitive fields. Treat the model like any other service that touches confidential data.

How do I choose between GLM-5.3 and a managed model?

Compare on your own evaluation set for quality, latency and cost at your expected volume, and weigh data control and operational effort. Many teams use both: a managed frontier model for the hardest reasoning and an open-weight model for high-volume or private steps.

Glossary

• Agent. A system that loops between a model and tools to complete a goal.
• Chat template. The text layout of roles and special tokens a model expects.
• Context window. The maximum number of tokens a model can consider at once.
• Expert. A sub-network in a mixture-of-experts layer.
• KV cache. Stored attention data that speeds up token generation.
• Mixture of experts. A design that activates only some sub-networks for each token.
• Open-weight. A model whose trained weights are downloadable under a license.
• Quantization. Storing weights in fewer bits to save memory.
• Router. The component that chooses which experts handle a token.
• Sandbox. An isolated environment for running untrusted code.
• Tool call. A structured request from a model to run a function.
• Tokenizer. The component that converts text to tokens.
• Total parameters. All learned numbers in the model, including every expert.
• Active parameters. The part of the model used for a single token.

Summary

GLM-5.3 is an open-weight language model from Z.ai that stands out for coding and tool use. Because the weights are downloadable, teams can self-host it, tune it with SFT or LoRA, and build agents around it with control over data and cost. Plan hardware by total parameters, use the exact template from the model card, evaluate on your own tasks, and wrap agents with limits, sandboxes and approvals.

For work on tabular data, treat it as the orchestrator and not the predictor. It can prepare data, call table-native models such as TabPFN or TabICL as tools, handle missing values and unnamed columns through careful code, explain anomalies and sector labels, and write the evaluation scripts. Table-native models and tree ensembles remain the right engines for numeric prediction. More on those models is in /model/research, /model/architecture and /model/benchmarks.

Related

It belongs to Open-weight models in my stack, under LLMs, retrieval, and evaluation. Others in the same group: