B7 reference-prefix check rejects honest GLM Coding Plan responses: new buyer gets 502 after match

[Community-AI-tools]

Summary

On current 0.2.1 source (846f8e5b39ee28df99fdce5ebe201a568911b0eb), an honest GLM seller can reach a matched/streaming deal but a new buyer's first consumer request returns HTTP 502 at B7 content-identity verification. The fixed-prefix reference check rejects independently generated responses from the same provider/model.

Observed on Shellnet, Linux, GLM Coding Plan. This is not a claim that every GLM deployment or every model is affected, and we have not reproduced this specific failure on mainnet.

Duplicate check

Checked open/closed issues and related PR searches before filing:

• Seller: make deterministic probe seed capability profile-configurable #145 concerns providers rejecting the optional seed parameter with HTTP 400. Here the seeded requests succeed with HTTP 200; their generated prefixes differ.
• buyer --local-listen: real inference never reaches the consumer despite successful match+handover, on both v0.0.12 and v0.0.14 #74 tracks post-handover consumer failures, primarily transport/session failures. This report isolates a successful upstream response rejected by the B7 reference comparator.
• v0.0.7 buyer local API returns 503 before quote/match when using on-demand mode #18 is an older pre-quote 503/name-only-verification report, not this comparator failure.

No exact existing report of this same-model prefix false rejection was found.

Exact binding and environment

• CLI source: 846f8e5b39ee28df99fdce5ebe201a568911b0eb (upstream HEAD rechecked 2026-09-07).
• Active executable SHA-256: 2682971b3fa797687340f78d6db7a2d7e485846e3d13946e723318a588cb16cb.
• Chain frame: GLM-5.3-Flash.
• Configured provider request/served model: glm-4.5.
• Provider-reported response model: glm-5.3-flash, accepted through native identity_aliases.
• Reference is derived from the same configured upstream/model, with the real reference key available. No --allow-unverified-model, removed key, lowered threshold or custom identity alias layer.

Evidence without another funded purchase

Send the native B7 probe to the configured upstream repeatedly with identical settings:

{
  "model": "glm-4.5",
  "messages": [{"role": "user", "content": "What is 17 times 23? Show your step-by-step reasoning."}],
  "temperature": 0,
  "seed": 0,
  "max_tokens": 64,
  "stream": false
}

Use the native content_or_reasoning extraction and prefix_agreement comparator. Our existing four-response diagnostic measured:

Observation	Result
HTTP success	4 / 4
Exact provider-reported response model	4 / 4
Distinct response hashes	4
Extracted word counts	30, 35, 34, 33
Pairwise prefix agreement	min 0.060606, max 0.529412
Native acceptance threshold	0.25

Thus the same official reference route produces scores on both sides of the rejection threshold. Temperature/seed do not make its leading reasoning/text prefix stable.

Actual buyer impact

Our native pool had one seller process, one gateway and two distinct streaming/probe-accepted contracts. The second buyer's consumer endpoint returned HTTP 502, classified as content_identity_preflight, with a native reference-spotcheck rejection. Chain topology/matching worked; successful consumer delivery did not.

A separate existing buyer later returned HTTP 200 with nonempty content, ordinary stop/[DONE], exact local model and 109 newly accounted tokens. That does not disprove the new-buyer failure: ContentGate caches a definitive verdict per deal.

Source-level diagnosis

• Probe constants and threshold calibration: 64-token probe, 0.25 threshold; the documented calibration population is Groq models, not this GLM route.
• Reference comparison and extraction: independently generated official reference, content-or-reasoning extraction.
• Prefix comparator: matching leading normalized words divided by the full reference word count.
• One-per-deal gate: rejection is cached and triggers native verification-failure recovery before ordinary consumer delivery.

Seller and reference use the same prompt, configured model, temperature zero, seed zero and cap. Seller is streaming whereas reference is non-streaming. This discrepancy deserves checking, but cannot alone explain away the evidence: the four non-streaming reference calls themselves disagree. No causal wiring fix was found in our independent review.

Expected resolution

Please provide the supported native identity-verification path for this nondeterministic GLM route, or fix B7 so an honest provider is not classified as a substituted model merely because independent generations differ. Any replacement needs both honest-model evidence and genuinely different-model negative controls; catalog aliases are not valid independent controls.

We are not asking to disable identity checks, drop the reference key, lower the threshold blindly, or retry funded buys until a random pass. Ideally unsupported reference reproducibility should be detectable before funding a deal, with an actionable diagnostic rather than a post-match 502.

The algorithm is shared, so other nondeterministic providers could be affected. Our confirmed scope is this GLM Coding Plan route only. No credentials, private endpoints, prompts from users, wallet material or buyer authorization are included here.