DeepSeek Harness with GLM-5.2: What rc.6 Sends

Independent research — not an official Z.ai publication.Identity and provider disclosure

AI Infrastructure Editor

Editorial responsibility: GLM52.ai Editorial TeamPublished and editorially reviewed August 13, 2026

How we research and review Report a correction

Disclosed editorial pen name · AI-generated portrait

Modular agent plugins sending teal request streams through a forensic audit gate, where an amber field mismatch is isolated before a neural model core

Original editorial illustration of the audit boundary. The plugin modules represent DeepSeek Harness, the central gate represents request inspection, and the amber path represents an unresolved field—not a provider outage or a failed GLM-5.2 result.

DeepSeek Harness is now a public developer-preview coding agent, not just the benchmark environment mentioned in DeepSeek model reports. Its dsh launcher boots plugin profiles for models, tools, sessions, sandboxes, filesystems, orchestration, and a web interface. The release is interesting for GLM-5.2 because the default profile already contains a generic llm-pi-ai adapter and a built-in zai catalog entry for glm-5.2. You do not need to invent an unknown provider from scratch.

That built-in route gets much right. In our pinned @deepseek-ai/dsh@0.1.0-rc.6 test, the CLI selected zai/glm-5.2, added /chat/completions to the base URL, sent a Bearer-authenticated stream with Z.ai’s thinking object, parsed a synthetic server-sent-event response, printed HARNESS_OK, and exited zero. An unknown model and an absent named credential both failed before network I/O.

The audit also found the reason not to paste a key and grant repository write access yet: the request advertised the 131,072-token cap through max_completion_tokens. Z.ai’s model guide and Chat Completion reference use max_tokens. We did not spend a live call to guess whether the service accepts, ignores, or rejects the alternate field. This guide shows how to inspect the boundary and how to run the smallest responsible upstream test.

The short verdict

DeepSeek Harness rc.6 is locally compatible with GLM-5.2’s provider identity, path, authentication style, streaming shape, and reasoning controls. Live Z.ai compatibility remains unverified because its output-cap field differs from the currently documented API field.

Layer	rc.6 audit result	What that establishes	What remains open
CLI artifact	`dsh --version` returned `0.1.0-rc.6`	The tested binary matches the pinned npm release	npm did not identify an exact source commit
Provider catalog	`zai/glm-5.2` resolved	The catalog knows model identity and capability metadata	Account entitlement and route policy
URL construction	POST to `/api/paas/v4/chat/completions`	The client appends the Chat Completions path once	Coding Plan versus pay-as-you-go choice
Authentication	Bearer header present; value not recorded	Credential plumbing reached the HTTP layer	Whether a real key is valid for that product
Streaming	Synthetic SSE became `HARNESS_OK`	Request dispatch and response parsing work	Live latency, usage, reasoning, and answer quality
Reasoning	`thinking.type=enabled`; effort `high`	The Z.ai dialect was selected	Whether every effort maps as expected upstream
Output cap	`max_completion_tokens=131072`	Exact rc.6 wire behavior	Z.ai documents `max_tokens`; acceptance is unknown
Failure gates	`UNKNOWN_MODEL`, `MISSING_CREDENTIAL`	Two configuration faults stop before HTTP	Provider errors, retries, tool loops, and quota

The distinction matters. A configuration file can parse while a provider rejects its request. A mock response can prove stream conversion while saying nothing about model behavior. An HTTP 200 can prove neither safe tool use nor a successful coding task. Promote one layer at a time.

Pin npm and source separately

The official npm registry published @deepseek-ai/dsh@0.1.0-rc.6 on August 13, 2026. We downloaded that exact artifact from registry.npmjs.org. The tarball contained 20 files, reported 116,711 unpacked bytes, and hashed to:

package: @deepseek-ai/dsh@0.1.0-rc.6
sha1:    de9fbf39056c7f4e658a3e284cb1d66ebc86d040
sha256:  1b8a9a0ad3c7feaece47926e0bd37ca151c7ccfa997953afa5fd01261784eadc

DeepSeek’s public repository was at commit 47f943859bef60e4160492346772ded9b24f765a when checked. Its commit message publishes rc.5, and the rc.6 npm manifest contains no gitHead. We used that commit’s CLI guide and provider guide to explain the architecture. We do not claim it is the exact rc.6 source tree.

This is more than release bookkeeping. A developer-preview package can move faster than repository documentation. Preserve the npm version, tarball hash, Node version, profile dump, and observed request together. A Git commit alone cannot reproduce this installation; an unpinned npx invocation cannot reproduce it tomorrow.

What rc.6 already knows about GLM-5.2

The installed pi-ai catalog includes a first-class zai provider and a glm-5.2 model. Its entry describes:

Catalog field	rc.6 installed value	Current Z.ai documentation
Provider ID	`zai`	Z.ai API platform
Model ID	`glm-5.2`	`glm-5.2`
Protocol	`openai-completions`	Chat Completions endpoint
Default Coding endpoint	`https://api.z.ai/api/coding/paas/v4`	Coding Plan product path is distinct from general API
Input	text	text
Context metadata	1,000,000	1M; the page’s exact config uses 1,048,576 elsewhere
Maximum output metadata	131,072	128K
Reasoning levels	minimal, low, medium, high, max mappings	documented GLM-5.2 examples use high/max controls
Thinking dialect	`zai`	`thinking: {"type":"enabled"}`

The one-million labels are semantically aligned but not arithmetically identical: the installed catalog stores 1,000,000, while the pinned open model config uses 1,048,576. That difference affects when a client compacts or refuses history. Do not infer that a Coding Plan account accepts either entire value; route and plan limits can be lower than model architecture.

The provider profile also separates a credential reference from its value. apiKeyEnv: ZAI_API_KEY means the settings document stores the variable name, not the key. In the web UI, DeepSeek says credentials are write-only and live in $DSH_HOME/.credentials.yaml; in a headless shell, an environment variable can supply the same reference. A missing named reference fails rather than falling through to an unrelated ambient credential.

Install rc.6 with a reviewable boundary

For a first audit, use a disposable environment or VM. The CLI’s dependency graph is not small: our lockfile contained 588 package entries and occupied about 360 MiB after installation. Review the package metadata and pin the version before running it in a valuable repository.

mkdir dsh-glm52-audit && cd dsh-glm52-audit

npm pack @deepseek-ai/dsh@0.1.0-rc.6 \
  --registry=https://registry.npmjs.org --ignore-scripts
sha256sum deepseek-ai-dsh-0.1.0-rc.6.tgz

npm install --prefix runtime --no-audit --no-fund \
  --registry=https://registry.npmjs.org @deepseek-ai/dsh@0.1.0-rc.6

runtime/node_modules/.bin/dsh --version

The final command should print 0.1.0-rc.6. We installed with lifecycle scripts disabled for the request audit, which prevented node-pty from being built; terminal-related plugins were then disabled because the mock task needed no shell. That is an audit-specific constraint, not a production recipe.

On a normal isolated installation, allow only the reviewed lifecycle work and keep the default plugin tree intact. Do not run the developer preview globally first, and do not point its workspace at a home directory. The current working directory becomes the default workspace root.

Inspect before you run

DeepSeek documents two useful read-only commands. The first shows bundle defaults; the second adds profile, home, and explicit patch layers.

export DSH_HOME="$PWD/dsh-home"

runtime/node_modules/.bin/dsh \
  --profile headless --dump-default-config > default-config.yml

runtime/node_modules/.bin/dsh \
  --profile headless --patch ./zai-glm-5-2.yml \
  --dump-config > effective-config.yml

Review these questions before booting:

Does agent-default-model name provider zai and model glm-5.2?
Does llm-pi-ai own the zai route, with no second adapter collision?
Is telemetry disabled if your policy requires it?
Which shell, filesystem, web, subagent, workflow, and approval tools mount?
What directory appears as the sandbox workspace root?
Does the endpoint represent Coding Plan or pay-as-you-go?
Is the settings file a reference-only document with no literal key?

The default headless profile has more behavior than “send one prompt.” It includes session title generation, persistence, compaction, tools, permission policy, skills, subagents, web search, telemetry configuration, and a separate agent loop. Our supposedly one-task run generated two model requests: one 64-token title request and one main task request. Budget and audit both calls.

Use the minimum Z.ai provider override

The smallest override should reuse the built-in catalog rather than redeclare GLM-5.2’s protocol, modality, reasoning map, and limits. For the general pay-as-you-go API, use this profile patch:

- id: agent-default-model
  config:
    provider: zai
    model: glm-5.2

- id: llm-pi-ai
  config:
    providers:
      zai:
        apiKeyEnv: ZAI_API_KEY
        baseURL: https://api.z.ai/api/paas/v4
        reasoning: high
        models:
          - id: glm-5.2

The models list narrows the provider to the one audited model. It does not add to the catalog; DeepSeek’s adapter says a list replaces the served set. The single ID inherits catalog metadata. If you want other Z.ai models, list every one you intend to expose.

Do not append /chat/completions to baseURL. The adapter adds the path. Do not paste the key in YAML. Supply it only to the process that runs the bounded test:

export ZAI_API_KEY="your-zai-api-key"
test -n "${ZAI_API_KEY:-}" && echo "ZAI_API_KEY is set"

The profile sets high effort because the installed model offers it and current Z.ai examples use a high/max control. It is not a recommendation to pay for high reasoning on every title or trivial task. Remove the profile default if you want provider behavior, then verify the actual request again.

What the loopback test sent

We redirected only baseURL to a task-owned server on 127.0.0.1. The provider remained the built-in zai route, preserving its catalog and compat metadata. The mock stored no Bearer value and returned two synthetic SSE responses.

Captured field	Session-title request	Main request
Method and path	`POST /api/paas/v4/chat/completions`	same
Model	`glm-5.2`	`glm-5.2`
Streaming	`true`	`true`
Bearer header	present, value omitted	present, value omitted
Thinking	enabled; `clear_thinking: false`	same
Reasoning effort	`high`	`high`
Output-cap field	`max_completion_tokens`	`max_completion_tokens`
Output-cap value	64	131,072
Tools	0	22
`tool_stream`	absent	`true`

The complete sanitized machine-readable receipt records the package hashes, execution boundary, positive control, negative controls, sources, and limitations. It does not contain message text beyond role/type summaries, a credential, account ID, cookie, or provider output.

The main output cap deserves attention for cost as well as syntax. The catalog cap became a request default because the profile did not choose a smaller maxTokens. A short task therefore advertised the full 131,072-token ceiling. An upper bound is not a promise to consume that amount, but a narrower cap is a better smoke-test control. rc.6’s public profile schema exposes maxTokens; the problem is that its serializer places the value under the field discussed next.

The unresolved token-field mismatch

Current Z.ai GLM-5.2 documentation shows max_tokens in cURL, Z.ai SDK, Java SDK, and OpenAI Python examples. The Chat Completion API reference also names max_tokens, with an allowed range through 131,072. We found no documented max_completion_tokens parameter on the reviewed Z.ai pages.

The rc.6 installed serializer defaults many OpenAI-compatible routes to max_completion_tokens. Its Z.ai compatibility detection selects the thinking dialect and disables unsupported OpenAI behavior, but it does not switch the output-cap field to max_tokens. The llm-pi-ai profile exposes thinking compatibility switches, not the broader maxTokensField switch present inside its underlying library.

Three outcomes are possible at the real endpoint:

Z.ai accepts the alias and enforces the value.
Z.ai ignores an unknown field and uses its model default.
Z.ai rejects the body as an unsupported parameter.

Our mock cannot distinguish them. A successful request alone also cannot distinguish the first two unless the response or server behavior proves the cap was applied. For a tiny smoke prompt, choose a deliberately low cap and inspect the response’s finish reason and usage. Do not infer enforcement merely because the server returned 200.

This is why the configuration above is a candidate profile, not a working production claim. Recheck the latest package and Z.ai reference before testing; the developer preview may fix the serializer quickly.

Two controls failed before network I/O

Positive-only tests hide dangerous fallback behavior. We added two profile faults and compared the mock’s request count before and after each run.

exit: 1
error: UNKNOWN_MODEL
network requests added: 0

glm-5.2-unknown did not silently select another model. The adapter resolved the exact route catalog and stopped locally.

exit: 1
error: MISSING_CREDENTIAL
network requests added: 0

An unset DSH_TEST_MISSING_ZAI_KEY did not fall through to another provider’s ambient key. The diagnostic named the reference, not a secret value. Preserve this behavior by specifying apiKeyEnv. Removing it changes semantics: the underlying catalog may attempt its native environment discovery.

Add two more controls in your own disposable setup: a wrong product endpoint should produce a bounded authentication/entitlement failure, and a denied tool should remain denied after a model retry. Do not create a retry storm to make a misconfigured endpoint look intermittent.

Run a bounded live smoke test

Only a real endpoint can settle the field question. Use a fresh empty Git repository or scratch directory, not an active project. Keep tools read-only or disabled, set a low spend ceiling at the provider, and record no credential.

export DSH_HOME="$PWD/dsh-home"
export DSH_TELEMETRY_MODE=DISABLED
export DSH_PERMISSION_MODE=read-only
export ZAI_API_KEY="your-zai-api-key"

runtime/node_modules/.bin/dsh \
  --profile headless \
  --patch ./zai-glm-5-2.yml \
  "Reply with exactly DSH_GLM52_OK. Do not call tools."

Make one attempt. Preserve a sanitized receipt with:

CLI and dependency versions;
endpoint class, never the key;
requested and returned model identity;
HTTP status and provider request ID when safe;
whether max_completion_tokens was accepted;
finish reason, prompt/completion/reasoning usage, and cost receipt;
whether the extra session-title call occurred;
tool-call count, expected zero;
stderr and exit code.

If the endpoint rejects the token field, stop. Do not remove the cap and grant tools merely to obtain a green response. Use a package release that maps the documented field, an adapter that exposes a reviewed compatibility override, or a narrow proxy that rewrites exactly one audited field and rejects everything else. A proxy adds operational and security surface; it is not the default recommendation.

If the endpoint returns 200, verify enforcement separately with a harmless short cap before declaring the mismatch resolved. If it ignores the field, an agent could generate far more output than its local policy intended.

Do not mix the two Z.ai products

The built-in zai provider points to the Coding Plan path. The earlier YAML switches it to the general pay-as-you-go endpoint. Credentials and billing entitlements are not interchangeable merely because both speak a similar protocol.

Product	Base URL	Billing model	Use when
GLM Coding Plan	`https://api.z.ai/api/coding/paas/v4`	subscription quota and tool policy	a supported coding agent is covered by the plan
Pay-as-you-go API	`https://api.z.ai/api/paas/v4`	metered model usage	you need general API accounting and application access

A valid key at the wrong path can fail authentication or entitlement. Start with the product you bought, document that choice, and never “fix” a 401 by bouncing between endpoints in a loop. The GLM-5.2 agent setup matrix explains this boundary across established clients; the OpenCode guide contains dated live evidence for a client whose Z.ai routes were already verified. Use those if the goal is dependable work today rather than evaluating a new framework.

Add tools only after transport passes

The main mock request advertised 22 tools even though the prompt said not to call them. Tool descriptions are part of the model-visible request; prompt prose does not remove capability. A safe rollout needs an explicit permission and acceptance ladder.

Stage	Workspace	Tools	Required evidence before promotion
Request audit	loopback mock	no executable provider tools	path, auth presence, model, thinking, cap field, stream parse
Live text smoke	empty scratch repo	read-only or disabled	one bounded response, model receipt, field enforcement, zero tool calls
Read test	disposable fixture repo	exact file/list operations	allowed read succeeds; denied path stays denied
Write test	disposable fixture branch	one scoped editor	expected diff only, validation passes, rollback works
Command test	isolated container/VM	allowlisted command	no network escalation, bounded output/time, clean teardown
Production pilot	reviewed real repo	least privilege with approval	repeatable task acceptance, logs, spend/loop cap, human rollback

Keep telemetry policy explicit. The default composition includes an OpenTelemetry exporter but reads DSH_TELEMETRY_MODE; our audit set it to DISABLED. Verify the effective configuration rather than assuming a variable name works. Also budget the title request, retries, compaction calls, subagents, web search, and tool loops independently. One user instruction is not necessarily one provider call.

The current developer preview exposes subagent and workflow plugins. Their presence does not authorize delegation or background work. Disable capabilities you do not need, keep approvals fail-closed, and test cancellation. Long context can sustain a larger trajectory; it can also sustain a longer expensive or unsafe mistake.

Troubleshooting by failure layer

Symptom	Likely layer	First check	Unsafe shortcut to avoid
`UNKNOWN_MODEL`	local catalog/profile	exact provider and model IDs; replacement semantics of `models`	changing to a vaguely similar model
`MISSING_CREDENTIAL`	local credential seam	named variable exists without printing it	pasting a key into YAML or logs
401/403	product route or account	Coding Plan versus pay-as-you-go endpoint and entitlement	retrying across both endpoints
404	base URL construction	base URL must stop before `/chat/completions`	appending the path twice
400 unknown parameter	request serializer	compare observed body with current Z.ai API reference	deleting all caps and controls
response succeeds but ignores cap	compatibility semantics	tiny-cap finish reason and usage	equating HTTP 200 with policy enforcement
headless makes two calls	session title plugin	audit the title request separately	billing only the visible final answer
native `pty.node` missing	installation/lifecycle layer	package scripts and platform prebuild	disabling security plugins in a real repo
model calls tools unexpectedly	capability/prompt boundary	effective tools, permission mode, tool choice	relying on “do not call tools” prose

When reporting a bug, include the package version, tarball hash, Node/platform, sanitized effective config, exact error code, request field names, and whether the network request occurred. Do not attach credentials, $DSH_HOME credential files, session histories, or a repository archive.

Sources, method and limits

The discovery lead was the AI HOT DeepSeek Harness item, which pointed to DeepSeek’s announcement. AI HOT supplied discovery only. Product claims were checked against the official repository, the pinned provider and CLI guides, npm metadata, the installed rc.6 artifact, Z.ai’s GLM-5.2 guide, the Chat Completion reference, and Z.ai’s GLM-5.2 release.

The current search check found benchmark-harness discussion, not an rc.6 provider tutorial. That is why this page names the product and version in the title and does not reuse benchmark claims as compatibility evidence.

The audit used Node.js 24.14.1 and npm 11.11.0 on Linux x86_64. Docker was not available to the current user; no privileged retry occurred. We used an ordinary-user task directory, disabled telemetry, installed with scripts disabled, redirected generation to loopback, captured only sanitized request fields, ran two negative controls, stopped the mock server, and removed the 360 MiB task runtime after archiving the receipt.

The evidence does not prove:

that live Z.ai accepts or enforces max_completion_tokens;
that GLM-5.2 generated HARNESS_OK;
model quality, thinking quality, latency, price, caching, or context limits;
tool selection or tool-result replay;
Coding Plan inclusion for a particular account;
sandbox resistance against malicious code;
compatibility of later dsh, Node, or provider releases.

Recheck the current docs and package before following the profile. If rc.6 is no longer current, keep this page as a dated receipt and create a new test; do not rewrite the old result into a success it did not observe.

DeepSeek Harness and GLM-5.2 FAQ

Does DeepSeek Harness support GLM-5.2?

rc.6 contains a built-in zai provider entry for glm-5.2, and our loopback test proved local routing and stream parsing. We did not verify a live Z.ai response because the observed output-cap field differs from current Z.ai documentation. Call it partial compatibility until that boundary is tested.

Which provider and model IDs should I use?

Use provider zai and model glm-5.2. Avoid inventing a second provider unless you need a separate gateway. A hand-declared provider must restate protocol, base URL, model list, capacities, modalities, reasoning mapping, and credential reference, creating more places for silent drift.

Should the base URL include `/chat/completions`?

No. Use a product base such as https://api.z.ai/api/paas/v4 for pay-as-you-go or the documented Coding Plan base for a covered coding subscription. The adapter appends /chat/completions.

Why did one headless command make two requests?

The default composition includes an LLM-based session-title plugin with a 64-token cap. The main task is a separate request. Inspect or disable auxiliary model consumers according to your policy, and include them in cost and privacy review.

Can I fix the field by setting `maxTokens` lower?

A lower value controls the amount, but rc.6 still serializes it under max_completion_tokens in the audited path. The question is field semantics, not only magnitude. Verify a release or adapter change that sends the documented field, or prove the live endpoint accepts and enforces the alias.

Is the stored key safe?

DeepSeek documents credential references and a write-only local credential store, and the missing-key path failed closed in our test. That reduces config leakage but does not remove process, filesystem, dependency, telemetry, shell, or host risk. Use a scoped key, restrictive permissions, an isolated test workspace, and provider-side spend limits.

Should I use DeepSeek Harness for GLM-5.2 production work today?

Use it for a controlled developer-preview evaluation if its plugin architecture is the object of your test. For dependable work, choose a client with dated live GLM-5.2 evidence until the rc.6 field boundary is resolved, then rerun transport, read, write, command, retry, cancellation, cost, and cleanup gates before promotion.