Compression models

Compression models are variants of glm-5.2 that carry a built-in output-compression instruction: same upstream model, same price per token, same CO₂ per token, but the answer comes back shorter. You select one by model id; there is no extra parameter, header, or SDK feature to adopt.

{
  "model": "glm-5.2-caveman",
  "messages": [{ "role": "user", "content": "Explain database connection pooling." }]
}

Available ids

Nine ids: three families, each at three intensities.

Output reduction

Two independent sources measure these rulesets, on different models and different kinds of work. Read the combined range as the plausible span for your workload, not as a promise:

GreenPT's figures are the reduction in completion_tokens against base glm-5.2 on identical prompts: eight single-function coding specs run three times each plus three prose prompts run twice each, 300 generations in total, against baselines of 1423 output tokens for the coding tasks and 1590 for the prose ones.

The right-hand column is each skill's own committed benchmark, which measures a coding agent rather than a raw chat completion: caveman over 10 prompts on the Claude API, honey over 23 tasks on Claude Opus 4.8 scored by a four-model quality panel, and ponytail over 12 feature tickets in a real repository on Haiku 4.5.

The two sources differ mainly in what they compare against. GreenPT's baseline is an unprompted glm-5.2 chat answer, which is verbose and reasons at length, so there is more to cut. An agent's baseline is already terse, so the same ruleset saves less. Expect your own saving to land between the two, closer to the low end the tighter your existing prompts already are.

Intensity

The upstream skills are untiered; -lite and -ultra are GreenPT additions that layer one extra line onto the shared ruleset. They select where in the family's range you land:

This ordering is the designed intensity of the rules. It is not a per-tier measurement: in GreenPT's runs the gaps between tiers of the same family mostly sat inside run-to-run noise, so pick a tier by the behaviour you want in the column above rather than by chasing a percentage. The one tier that behaves distinctly is honey-lite, whose rule is to keep the explanation intact — it sits firmly at the bottom of honey's range, around −36% on coding work, by design.

Treat all of this as the shape of the ladder, not a guarantee: a request is never run both ways, so GreenPT cannot tell you the exact saving on yours.

One further result is worth knowing: most of the saving is not the code. In GreenPT's coding runs the delivered function was only about 13% shorter under compression. The drop from 1423 to roughly 400 output tokens comes almost entirely from shorter reasoning and less explanation around the code.

These counts include reasoning tokens. glm-5.2 reasons before answering and roughly a third to a half of the output you are billed for is reasoning the rulesets do not shorten, so the visible answer shrinks by more than the table shows. Sending "reasoning_effort": "none" alongside a compression id cuts the remainder and composes well with them.

Effect on correctness

Across the same 240 coding generations, 237 passed a hidden test suite for the requested behaviour. The three failures were one malformed code fence and two genuine edge-case bugs in CSV field parsing, spread over three different ids. On inputs the prompt never mentioned (null, wrong types, cyclic objects) the compressed ids held between 77% and 84%, against 86% for base glm-5.2 — the cases that throw are overwhelmingly ones base glm-5.2 fails too.

These are single-function, fully specified tasks. They do not tell you whether cutting reasoning hurts on multi-file changes, ambiguous requirements or algorithmic design, where the reasoning is doing more of the work.

These counts include reasoning tokens. glm-5.2 reasons before answering and roughly a third to a half of the output you are billed for is reasoning the rulesets do not shorten, so the visible answer shrinks by more than the table shows. Sending "reasoning_effort": "none" alongside a compression id cuts the remainder and composes well with them.

caveman: terser prose

Strips filler and decoration from natural-language answers while keeping every technical token intact. -lite keeps full sentences and articles and removes only filler and hedging; the unsuffixed id drops articles, allows fragments and prefers short synonyms; -ultra strips conjunctions where cause and effect stay unambiguous and states each fact once.

ponytail: less generated code

A "lazy senior developer" ruleset for code-heavy answers: YAGNI first, stdlib and platform natives before custom code, no boilerplate or speculative abstractions, while never compromising on validation, security, or anything you explicitly ask for. -lite builds what you asked and names the lazier alternative in one line; the unsuffixed id enforces the ladder; -ultra prefers deletion over addition and pushes back on the requirement itself.

honey: both

Combines the two: minimal code (ponytail's ladder) plus terse prose (answer first, no hedging or narration). The suffix tunes the prose intensity: -lite keeps the explanation intact, the unsuffixed id allows fragments and at most one line of rationale per code block, -ultra is near answer-only (code plus at most one line naming the main caveat).

Which id should I pick?

Pick the family from what your workload actually emits, then the intensity from how much context you are willing to lose.

A shorter rule of thumb: ponytail for code, honey for a mix, caveman for prose, base glm-5.2 for anything short or shape-sensitive.

For the intensity, start on the unsuffixed id: it is the ruleset as its authors wrote and benchmarked it. Step down to -lite when losing an explanation would cost you more than the tokens save, and up to -ultra when you want the answer and nothing else. In GreenPT's measurements the tiers within a family were much closer together than the naming suggests, so a tier change is a change in behaviour first and a change in token count second.

These rulesets also exist as installable coding-agent plugins: see Token compression.

How it works

1. Inject: the ruleset is attached to the model itself as a system prompt and prepended before your request is forwarded upstream, the same mechanism green-l and green-r use.
2. Merge: if your request contains its own system message, both are combined into a single system message: your instructions first, the compression rules last, so the style you selected by model id wins any conflict.
3. Echo: the response's model field is the compression id you asked for, both on complete responses and on every streamed chunk.

Each id keeps its own prompt cache, inherited at the same discounted rate as glm-5.2. Because the ruleset sits in the prompt, identical user content sent to glm-5.2-caveman gains nothing from glm-5.2-honey having cached it, nor from plain glm-5.2. Stick to one id across a run to keep the prefix warm.

Send your own system prompt

Coding agents and other clients that always send a system prompt work with these ids. Your system message is kept in full and the compression rules are appended after it:

{
  "model": "glm-5.2-honey",
  "messages": [
    { "role": "system", "content": "You are a code reviewer for a Python repo." },
    { "role": "user", "content": "Review this diff." }
  ]
}

Several system messages are concatenated in the order you sent them, then the compression rules are appended. Because the compression rules come last, an instruction like "always explain your reasoning at length" in your own system prompt will not override the terser style of the id you picked. The same applies to mechanical requirements, not just style: if your prompt depends on a required marker, a fixed JSON envelope or a citation footer, state it in the user message as well, and prefer -lite or base glm-5.2 when the exact output shape matters more than its length.

Pricing, energy and CO₂ accounting are identical to glm-5.2; the saving comes entirely from generating fewer output tokens.

Examples

curl:

curl https://api.greenpt.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-your_api_key" \
  -d '{
    "model": "glm-5.2-honey",
    "messages": [{ "role": "user", "content": "Add retry with backoff to this fetch call." }]
  }'

OpenAI SDK, where only the model id changes:

client.chat.completions.create(
    model="glm-5.2-honey",
    messages=[{"role": "user", "content": "Add retry with backoff to this fetch call."}],
)

Streaming works the same way:

stream = client.chat.completions.create(
    model="glm-5.2-caveman-ultra",
    messages=[{"role": "user", "content": "Why does my React component re-render?"}],
    stream=True,
)
for chunk in stream:
    print(chunk.choices[0].delta.content or "", end="")

Related