ce-code-review: allow user-configured cross-model peer routes (e.g. GLM via an Anthropic-compatible endpoint)

[jkleske]

What I ran into

I wanted to use GLM-5.3 (served over z.ai's Anthropic-compatible endpoint) as the independent cross-model adversarial peer in ce-code-review. There is no supported way to do that today, even though the mechanism it would need already exists.

Two hard stops in scripts/cross-model-adversarial-review.sh:

1. CROSS_MODEL_FIXED_ROUTE only accepts codex | claude | grok-cli | grok-cursor | cursor | composer. Anything else fail-closes, which is correct behaviour — but it means the route set is not extensible.
2. validate_model_override accepts claude:opus|sonnet|haiku|claude-* only, so binding a non-Anthropic model id to the claude route is rejected as a cross-family substitution — also correct, and also a dead end for this case.

The only mechanically working workaround is to export ANTHROPIC_BASE_URL (or shim a claude binary) so the sanctioned claude route silently reaches a different provider. That defeats the entire point of the disclosure and receipt machinery: the pre-egress announcement would name Anthropic while the diff goes somewhere else. I am not doing that, and I don't think anyone should.

Why this seems worth supporting

The design already separates "which provider" from "which model/effort", already has a user-facing preference key (cross_model_peer: in .compound-engineering/config.local.yaml), and already distinguishes receipt-verified from receipt-less routes in the announce wording. A user-defined route would slot into that structure rather than fight it.

Concretely, several strong coding models now ship an Anthropic-compatible endpoint and are driven by the same claude -p adapter you already have. The delta is a base URL, an auth source, and a model id — not a new adapter.

Rough shape of a proposal

Something like a cross_model_custom_peers: block in config.local.yaml:

cross_model_custom_peers:
  - name: glm
    adapter: claude          # reuse the existing claude -p adapter
    base_url: https://api.z.ai/api/anthropic
    model: glm-5.3
    family: glm              # participates in same-family host exclusion
    receipt: false           # announce as 'serving model unverified on this route'

with, I would suggest:

• a custom peer never being reachable by default — it must be named in cross_model_peer: or CROSS_MODEL_PEERS, so nothing changes for existing users;
• the announce naming the endpoint host alongside the model, since the recipient is no longer implied by the route name;
• receipt: false being the default for custom peers, so the existing "requested X at Y; serving model/effort unverified on this route" wording carries the honesty burden;
• the declared family feeding the same host-exclusion check, with unknown skipping the pass exactly as it does today.

Happy to be told this is out of scope — the curated-route model is a defensible position, and a self-declared family field is weaker evidence than an attested host. But if the answer is "curated only", it would help to say so in references/cross-model-review.md, because the presence of cross_model_peer: reads like an extension point.

Context: I got here from a project that already treats external review egress as an explicitly authorized, provider-named decision in its own conventions file. The thing I most want to avoid is people reaching for the base-URL workaround because the honest path does not exist.

[jkleske]

Follow-up with concrete data on the model I used as the example, since it cuts both ways for the proposal above.

A colleague on the same project finished an unrelated evaluation of glm-5.3 today — a content-generation benchmark, not a code-review one, so treat it as adjacent evidence rather than a measurement of peer-review quality. Two observations from it bear directly on how a custom route would have to behave:

1. Self-reported model identity is unreliable, which argues for receipt: false as a hard default. Asked to state its own model id, glm-5.3 identified itself as glm-4.6 in one run and left the field empty in another. This is a good argument for never letting a custom route's self-report stand in for a serving-side receipt. Your current design already handles this correctly for receipt-less routes ("requested X at Y; serving model/effort unverified") — a custom-peer feature should simply be unable to opt into receipt: true, rather than trusting a declaration.

2. Output-shape instability is a real risk for the schema-enforcing adapters — a caveat against my own suggestion. The same prompt returned JSON sometimes fenced in Markdown and sometimes bare, with response length varying between roughly 1.8k and 10.7k tokens. Reasoning tokens counted against the same budget: in one run reasoning consumed 7538 of an 8192 cap and truncated the actual answer.

That matters because the claude -p adapter I proposed reusing runs with --json-schema and a turn cap, and out_missing_or_invalid() discards anything that isn't findings-shaped. A model with an Anthropic-compatible endpoint is not automatically a model with Anthropic-compatible output discipline. So if custom peers are worth doing, they probably need at least a configurable token budget, and possibly a tolerant unwrap for fenced JSON on custom routes only — leaving the curated routes' strictness untouched.

None of this changes the core request. It does sharpen it: the interesting question is not "can we point the adapter elsewhere" (trivially yes) but "what must a route prove before its findings are allowed into the synthesis". Right now the answer is "be on the curated list", which is defensible. If it stays that way, saying so explicitly in references/cross-model-review.md would still be worth it.