- Qxern (this work) — differs from C2C and LatentMAS in medium (explicit compact packet vs KV-cache fusion vs shared hidden states), in question, and in its negative results: the flat 8→64-token capacity curve,
names = 0.00, and the name-invariance probing. - C2C — Cache-to-Cache, arXiv:2510.03215 (ICLR'26).
- LatentMAS, arXiv:2511.20639 (ICML'26).
Abstract
Why should AI agents talk to each other in a human language that isn't their native one?
Models think in continuous vectors; text is a lossy, token-by-token serialization imposed on them
for our convenience. Qxern v6 lets model A (Qwen2.5-Coder-1.5B) encode a code
snippet into 32 latent tokens via a trained Q-Former adapter, and a frozen decoder
(Qwen3.5-0.8B) answers questions about the code from that latent packet alone — no code
text is transmitted.
Measurements show where the dream breaks: a continuous latent channel carries behavioral
semantics well and discrete symbols not at all (function names: 0.00 vs
0.70 for text relay; code differing only in identifier names collapses to one point in
latent space — cos = 0.985). Qxern v6 is the pragmatic answer: a hybrid packet
[semantic latents] + [deterministic AST sidecar] (signature / arity / behavioral flags /
literals — parsed with ast, no LLM, microseconds, ~30 tokens), plus an adaptive
router that picks latent-only / latent+sidecar / text relay per question type. Guard gates and
paired bootstrap CIs are passed for both hybrids: the significant win is param count
+0.30 [95% CI +0.10, +0.50] at 2.39× lower latency than the strengthened text relay,
with nothing degraded.
One honest sentence: continuous latents are a fast semantic channel between two LLMs,
but they are structurally unable to carry exact symbols; a tiny deterministic AST sidecar
restores exactness for tens of tokens — and every claim on this page is locked behind guard gates and
paired bootstrap CIs computed from the raw run data.
Method: two channels, routed per question
The packet travels as [32 latent tokens × 1024 dims ≈ 64 KiB] plus a sidecar of a few
dozen text tokens. The sender runs an AST parse in parallel with the encoder (microseconds, no LLM),
the frozen instruct-decoder reads both, and a regex router decides how much to pay:
Sender: codePython function, ≤ 256 tok
→
Encoder AQwen2.5-Coder-1.5B
→
32 latent tokensQ-Former · 64 KiB
→
Decoder BQwen3.5-0.8B · frozen
→
Answerno code text was sent
AST parserstdlib · µs · no LLM
→
Sidecardef name(…), arity, flags ≈ 20 tok
↗
joins the decoderexact symbols restored
semantic path (latents)
symbolic path (sidecar)
The channel-geometry problem. Contrastive probing: code differing only in identifier
names collapses to (almost) one point in latent space — cos(original, renamed) = 0.985
vs cos(original, other function) = 0.930. Identifiers physically never reach the decoder;
names = 0.00 is channel geometry, not a bug. That is why the sidecar is an
architectural necessity, not a crutch — and why retraining alone (qxern_struct) fails the
guard gates.
0.00 → 0.87
function-name accuracy with the sidecar
2.39×
lower p50 latency vs text relay (hybrid)
+0.30 [+0.10, +0.50]
significant bootstrap gain on param count, n=30
Interactive demo
The router in action. Not a simulation. Every answer on this page was produced by the
real Qxern pipeline — Qwen2.5-Coder-1.5B (fp16) encoder + Qwen3.5-0.8B (fp32) decoder +
the trained 32-token Q-Former adapter, greedy decoding — run as a Kaggle notebook on a
Tesla P100 GPU on 2026-08-03 (~1 s per answer, ~4 minutes total). The router decision
shown is computed by the same regex as the deployed sidecar_router.py; the demo
replays the stored real outputs on demand and shows what the router paid for the answer.
1 · pick a code sample
2 · exact sidecar facts AST · no LLM
3 · the question
4 · routed answer
Pick a sample and ask a question. The adaptive router will pick the
cheapest channel — pure latents, latents + sidecar, or text relay.
Every channel, side by side
Same sample & question as in the demo. Answers are real generations from the actual pipeline (Kaggle P100, 2026-08-03, greedy decode; wall times shown per card). Latencies in the headers are the paper's measured p50 (RTX 5090) — the two machines are different, so timings are not directly comparable.
Results
n=30 held-out functions for AST facts (n=50 for SemSim/latency; CodeSearchNet, repo-level split, one GPU, one seed). Accuracy/SemSim are means, latency is p50. Full raw per-example data in the repo.
Main ablation (AST exact-match facts)
| System | func name | param count | returns | SemSim | p50 ms |
|---|
✓ = both hybrids pass all five guard gates (returns ≥ 0.88, SemSim drop ≤ 0.01,
names ≥ 0.65, params ≥ 0.60, speedup vs relay ≥ 2×).
qxern_struct (retrained, no sidecar) fails on names (0.20) — architecture, not training,
restores exact symbols.
Guard gates
Paired bootstrap vs relay (10,000 resamples, 95% CI)
- hybrid: param count +0.30 [+0.10, +0.50] — significant; names +0.17 [−0.03, +0.37] and returns +0.07 [0.00, +0.17] positive but not significant at n=30; SemSim indistinguishable — all at 2.39× lower p50 latency.
- hybrid_struct: all accuracy diffs statistically indistinguishable from relay, at 2.91× lower p50 latency.
- qxern_struct: retraining buys speed (223 vs 202 ms), not symbols — names 0.20 < 0.65 gate.
Honest limitations
- The names gain is not statistically significant (95% CI crosses zero at n=30). The significant win is param count (+0.30) at 2.4× lower latency.
- Retraining is not a free win:
hybrid_structis faster (420 vs 511 ms) but drops param count to 0.73 vs 0.93. - SemSim is computed against teacher answers — relay (same family as the teacher) has a built-in advantage; SemSim also favours verbose answers.
- n=30 eval functions (50 for SemSim/latency), one GPU (RTX 5090), one seed, small models (1.5B + 0.8B). Directional evidence, not a paper-grade eval.
- Latency numbers are single-GPU p50 with warm-up, CUDA sync and randomized order — hardware-specific.
- The interactive demo answers are real generations (Kaggle P100, 2026-08-03); the latencies shown next to them are the paper's RTX 5090 p50 measurements, not P100 timings — the P100 runs took ~0.5–5 s per answer.