Who Is Behind Ox Alpha? The API Left a Trail

A warm forensic desk where an anonymous black model core is surrounded by token strips, server photographs, and linked evidence cards

×

Ox Alpha kept its maker's name out of view. The machinery around it proved less discreet.

The model would not name its maker. Its error handler did.

A harmless malformed request sent to Ox Alpha on August 24 exposed a Java class path inside the upstream service. A second request, carrying an invalid chat role, returned a numbered error in the same dialect documented around Z.ai's GLM endpoints. Neither clue could identify a set of weights alone. Together with two tokenizer studies, they changed the question from a guessing game into a model-forensics case.

The official record remains narrower. OpenRouter's model card says an anonymous third party develops and operates Ox Alpha; OpenRouter only routes requests. The preview opened on August 20 with a 1,048,576-token context window, up to 131,072 output tokens, and text, image, and video input. No lab name, architecture, parameter count, checkpoint, or technical report came with it.

OpenRouter's Ox Alpha model card showing the anonymous third-party provider notice, free preview, 1M context, and multimodal inputs

×

OpenRouter's live card names the party it is **not**: the router is neither developer, owner, nor provider. It also states that the anonymous provider retains prompts and completions. [Open the current model card.](https://openrouter.ai/stealth/ox-alpha)

The first 68 minutes

The listing became visible at 20:04:55 UTC. OpenCode posted about the free preview at 20:59:49, roughly two minutes before OpenRouter's launch post. OpenCode also advertised enough capacity for 100 trillion tokens per day. That last number belongs to OpenCode's announcement; it is not an audited measure of the model's throughput.

Sixty-eight minutes after the listing appeared, @aitrackerbot published the earliest technical fingerprint found in the indexed public record. That is a bounded finding. Deleted posts, private chats, and pages that search engines never indexed remain outside it, so the source cannot be crowned the first person anywhere to suspect GLM.

Asking the model led nowhere

Early threads tried the obvious route: asking Ox Alpha what it was. The answers ranged from coy to contradictory. The largest public evidence archive later recovered a deployment instruction that forced the model to identify only as ox-alpha. Self-identification had been contaminated before the first question arrived.

That discovery removed the most conversational evidence from consideration. A model can repeat a supplied persona, invent a creator, or deny a capability it is already using. Token boundaries and upstream validators are harder to rehearse.

The tokenizer matched; the server stack spoke

Aseem Shrey's public archive compared 44 deliberately awkward strings across tokenizer families. Ox Alpha matched the GLM-5 generation on all 44; GLM-4.x matched 42. Joseph W. Elstner's separate study widened the test to 95 probes and 14 candidate vocabularies. The GLM-5 vocabulary matched 95 out of 95 with zero mean absolute error.

A third independent black-box study reached the same neighborhood from a different angle. After correcting for a fixed wrapper offset, Ox Alpha and a served GLM-5.3 control matched on 24 of 24 token deltas, with correlation 1.0. MiMo-V2.5 matched only five. Its authors stopped short of naming an exact checkpoint, which is precisely where the evidence stops too.

Three paper token ribbons pass through precision rollers, with two patterns aligning while a third drifts out of step

×

A tokenizer does not sign a model's name. It leaves a repeated rhythm, especially on strings chosen to make related vocabularies disagree.

←1 / 2→

The server-side trace was unusually concrete. Chetaslua first reported that a malformed top_p value exposed com.wd.paas.api.domain.v4.chat.ChatCompletionRequest. A fresh check for this article reproduced that class path through OpenCode Zen. The invalid role wizard also reproduced [1214] Incorrect role information. Z.ai's official documentation uses the related /api/paas/v4/chat/completions route family, and Z.ai-hosted GLM endpoints have returned the same numbered role error. The same GLM weights served elsewhere can produce a different validator, which points to the operator rather than merely the vocabulary.

The public Ox Alpha identification archive showing its Z.ai and GLM-5-generation verdict alongside the exact-variant limitation

×

The public archive makes a strong family attribution while preserving the boundary that matters: the exact serving, quantization, and deployment variant remains unproven. [Open the evidence archive.](https://github.com/LuD1161/ox-alpha-identification-public)

A calibrated answer: Z.ai upstream, GLM-5 family, checkpoint unknown

The converging evidence supports a high-confidence attribution of the upstream operator to Z.ai / Zhipu AI and a strong attribution to the GLM-5 generation. That conclusion rests on signals from different layers that fail in different ways: vocabulary, template behavior, validator implementation, error codes, context behavior, and modality controls.

Likely operator: Z.ai. Likely family: GLM-5 generation. Exact checkpoint: unresolved.

The final line matters. Public GLM-5 documentation describes a text model with a much smaller context window, while Ox Alpha exposes roughly one million tokens and visual input. A private multimodal successor, an extended serving tier, a distilled or quantized build, or a new checkpoint could all preserve the same family fingerprints. No public artifact selects one of them. As of August 24, OpenRouter still labels the provider anonymous.

The 80% score was ten tasks wide

The performance story moved faster than the forensics. Ben Davis's first DeepSWE subset contained ten tasks and Ox Alpha solved eight. The 80% headline was arithmetically correct, but each task moved it by ten percentage points. Davis warned that the estimate carried high variance; many retellings dropped that warning.

Davis later relayed a larger subset run near 63%, conducted by DeepSWE creator Wenqi. A separate public sweep then ran all 113 tasks for 20 hours and 39 minutes. Its auditable aggregate was 66 solved tasks, or 58.4%. These were different runs and denominators, not one model visibly losing ability over two days.

The public Ox Alpha DeepSWE repository's final-results table showing 66 of 113 tasks solved, 58.4 percent, and a Wilson confidence interval

×

The completed public run reports **66 / 113 = 58.4%**, with a 95% Wilson interval of 49.2% to 67.1%. [Inspect the run and raw artifacts.](https://github.com/MatchaOnMuffins/oxalpha#7-final-results)

←1 / 2→

The table is a compass, not a clean ranking merger. DeepSWE's official board aggregates multiple configurations and often several runs; Ox Alpha has one community run with public traces and a Docker setup. The fairest reading places that run near Claude Opus 4.8 and Qwen3.8 Max, below the current leaders. It does not support the claim that an anonymous preview has already beaten them.

Good patch instincts, unfinished agent loops

The binary score hides a model that often came close. Ninety of 113 tasks passed at least 90% of their fail-to-pass tests, yet only 66 earned full credit. Eleven tasks—9.7% of the suite—ended after repeated tool-call formatting failures. Five timed out. The public traces suggest strong repository reading and patch construction paired with a weaker habit of closing the loop cleanly.

A broader Unlock AI evaluation found the same uneven shape. Ox Alpha averaged 65 out of 100 across four work samples, reaching 92 on a knowledge-work artifact but 54 on both a data-cleaning task and a physics-heavy brick task. Its 60 on the Artemis II visualization sat close to GLM-5.2's 58 and far below GPT-5.6 Sol's 89. The site changed its harness, so historical rows are not perfectly interchangeable; the spread across tasks is more informative than the average.

The free preview has a privacy bill

The model costs zero dollars per token during the preview, but the routes do not make the same data promise. OpenRouter states that the anonymous provider retains prompts and completions, while saying those records are not used for training. OpenCode Zen's documentation describes zero retention at its own proxy. Those statements apply to different paths; one cannot silently cancel the other.

That distinction turns model identity into a practical issue. A private repository, customer record, unreleased design, or credential should not be sent to an unnamed upstream merely because the context window is generous. The safest evaluation remains a disposable repository with synthetic or public data until the operator, retention boundary, and long-term service terms are explicit.

What would change the verdict

• A provider-authenticated announcement or model card would settle the operator question.
• A checkpoint identifier, architecture report, or reproducible weight artifact would narrow the exact-model question.
• A second full DeepSWE run under a frozen route, harness, effort level, timeout, and seed would turn one score into a distribution.
• Cross-route probes with raw requests and responses would show which clues belong to the model and which belong to a gateway.

The trail is open

The useful next post will not be another confident model name. It will be a trace that another researcher can run. The OpenRouter card, public identity archive, independent fingerprint study, and full community benchmark run leave enough material to test or challenge this conclusion. Researchers who find a counterexample can add far more by publishing the prompt, route, timestamp, control models, and raw response than by adding another anonymous vote to a thread.