[Avicennasis]

The expert-worker cluster mode exists in one engine, colibri.c. This gives glm53.c the same thing, same wire (COLIEX01 v1, byte-identical header and item layout), env-gated and off by default; the single-machine path is byte-identical (built the pristine glm53.c beside it and cmp'd stdout on the tiny and the streaming-int4 fixtures: identical, counters included). Delegation applies only when m->streaming (the int4 U8 container); resident-f32 experts never reach the hook, and the worker refuses such a checkpoint by name. KDA/MLA/indexer/mHC untouched; the shared expert stays on the coordinator.

One deliberate difference from colibri.c, coordinator-only: adding each worker's replies into out worker-by-worker changes the per-token float summation order against the local union-order loop. Measured here: 1 worker bit-identical; 2 workers same tokens but 66/128 last_logits differ at ~1e-8. glm53.c's cluster_moe_batch collects every worker's y first and sums in union order, so it is bit-exact for any worker count. The same order dependence exists in colibri.c (its gate is token-only, so it never saw it); I left that file alone because #1962/#1963/#1964 are open on its cluster block and will send the ~15-line fix after.

Worker: load_cfg + st_init + glm53_mirror_setup + the prefix probe (mirrors model_load_range), then expert_geometry + expert_table_init, which validates every piece up front, so an absent expert fails at start, not on first use. It also rejects layer < first_dense (dense layers have zeroed eref entries here). coli cluster worker learns the glm53 argv (cap only; precision is GLM53_BITS); WORKER_FAMILIES=("glm","glm53").

Gate (tests/test_glm53_cluster_sharding.py, GLM53_TINY_STREAM): glm53.c has no [ORACLE] mismatch mode, so the gate compares against ref.json: baseline equals the f32 oracle's teacher-forcing and greedy ids per position; delegated equals baseline byte-for-byte on teacher_forcing, greedy and last_logits, and via every prompt prefix 1..8 on last_logits at every position; delegation acted (two workers, experts hits 0 miss 0 bytes 0 on the coordinator); an unreachable worker makes the engine refuse, never fall back silently. The fixture is the text-only streaming pair from make_glm53_streaming_pair.py: the multimodal int4 CI fixture flips one teacher-forced token against its f32 ref on the pristine engine (int4 rounding on a 128-wide random model), so it cannot carry a zero-mismatch gate. Negative control: a 1e-3 nudge on the worker's output passed the first, last-position-only gate; the per-prefix per-position logit parity catches it (1 failed), reverted, 2 passed.

make glm53 colibri tests/test_glm53_cluster_protocol 0 warnings; protocol test ok; glm53 gate 2 passed; the GLM-5.2 gate still 2 passed; test_makefile_deps 8 passed; test_cluster.py + test_glm53_oracles.py 9 passed. check.yml's glm53-oracle job generates the text int4 pair and runs the gate.

Note: a sibling PR for deepseek_v41.c touches the same three need_worker_model lines in c/coli; whichever lands second is a trivial rebase.

[Avicennasis]

Closing this one: superseded by #1774.

#1774 (merged into dev 2026-10-08, merge 8da806d6, with #1977 and #1978 stacked on it) gives glm53.c expert workers on its own wire, COLIG53X. It already has what this PR proposed for glm53 over COLIEX01 v1, and more: every request of a layer goes out before any reply is read (poll), GLM53_CLUSTER_TIMEOUT bounds the connect, every message in flight and each layer's reply, ownership is a deterministic weighted hash of (layer, expert) with shares from a disk-bandwidth handshake that also rejects a worker holding a different model, CLUSTER_WORKER_BIND, and the replies are added back in the local loop's order, so a cluster run prints what a local run prints. A second glm53 worker path on the COLIEX01 wire would be two protocols for one engine, which is not what was taken, so this branch stops here. The p/glm53-cluster head 44d9ca35 stays on the fork for reference.

The remaining colibri.c-side proposals from the same batch are #1964 (v2 hello refusing a v1 worker by name, shared expert on the worker) and #1970 (a v2 request sends the batch rows once); they are being rebased onto dev 1509ea5b. #1962, #1963 and #1967 merge cleanly against that head as they stand. The union-order summation point about colibri.c's cluster_moe_batch noted in the description above is still open and is not part of any of those.