Latent Space Reasoning
Teaching LLMs to reason in the Latent Space to precondition responses.
Install / Use
npx skills add dl1683/Latent-Space-ReasoningInstalls into whichever agent you are using.
README
Latent Space Reasoning
This repository is a research lab for a different unit of inference.
Most reasoning systems ask a model for one completion, maybe sample a few more, then pick a winner. This project asks a stronger question:
Can a frozen model reason better if we treat its latent generation path as an editable, inspectable search space instead of a one-shot text sample?
The long-term target is a control layer for reasoning itself:
sample -> inspect -> repair -> aggregate -> verify -> realize
That means a completion is not the final object. It is evidence: a partial reasoning artifact that can be compared, repaired, merged, rejected, or used as source material for a stronger answer.
Why This Matters
Winner-take-all inference wastes partial work.
One candidate may have the right plan but miss a constraint. Another may catch the constraint but have weak structure. Another may surface a risk, preserve an exact role, or expose an edge case. A selector can only choose one. A stronger reasoning system should preserve the useful parts from several trajectories without importing contradictions or unsupported claims.
This repo explores that family:
- token and prefix perturbations as cheap trajectory diversity;
- diffusion denoise histories as intermediate reasoning state;
- latent repair as local editable-state intervention;
- candidate promotion as spend and selection control;
- multi-latent aggregation as source-supported synthesis across trajectories;
- proof objects, gates, and cost accounting as the discipline that keeps the claims honest.
Quick Start
Install from source:
git clone https://github.com/dl1683/Latent-Space-Reasoning.git
cd Latent-Space-Reasoning
pip install -e .
For quantized models (recommended):
pip install -e ".[quant]"
Compare baseline versus latent reasoning on any query:
latent-reason compare "How do I implement user authentication?"
latent-reason compare "Design a REST API" --encoder Qwen/Qwen3-4B
Or use the Python API:
from latent_reasoning import reason, compare
result = reason("How do I implement caching?")
print(result.plan)
cmp = compare("How do I implement rate limiting?")
print(cmp["baseline"])
print(cmp["latent_reasoning"])
Other CLI commands:
latent-reason run "Design microservices" --encoder Qwen/Qwen3-1.7B
latent-reason models # list recommended models
latent-reason check-gpu # check GPU availability
Minimum hardware: ~2GB VRAM (Qwen3-0.6B). Recommended: ~8GB VRAM (Qwen3-4B). CPU-only works but runs slower.
Current Evidence
| Area | Status | What It Shows |
| --- | --- | --- |
| Diffusion latent repair | Promoted public result | A frozen diffusion language model can improve on a lean mixed benchmark by repairing latent generation state. |
| Token/prefix perturbation | Measured across 6 models + text generation | 2 random embedding tokens raise Qwen3-4B from 32% to 72% (plurality@10) on nested arithmetic. Scaling from 1.7B to 32B is flat or worse (28%→36%→0%). Perturbation beats temperature sampling at equal cost (72% vs best 64%). On text generation, perturbation wins 7/15 vs baseline (1 loss) and 5/15 vs 14B (7 losses). See below. |
| Multi-latent aggregation v5 | Clean local milestone | A predeclared 48-task aggregation replay passed stricter robustness gates on planning tasks. |
| Aggregation v6-v8 | Negative transfer evidence | More repair, probes, and targeted standalone repair did not reliably create aggregation-useful complements. |
| Aggregation v9 | Post-failure design breakthrough | Complement-first packet generation passed frozen numeric replay gates on the failed v7 surface, but remains diagnostic. |
| Aggregation v10 | Fresh transfer promotion — ALL 13 GATES PASSED | Complement-first packets on fresh plan_393-plan_440 slice: 40/48 coverage, 38 promotions, 40/8/0 W/T/L, mean lift +0.077, zero contradictions. |
| Aggregation v11 | 2x replication — ALL 13 GATES PASSED | LLaDA-only 96-task replication on plan_441-plan_536: 87/96 coverage (90.6%), 87 promotions, 87/9/0 W/T/L, mean lift +0.100, Wilson lower 0.831, zero contradictions. Keyword audit RED — rubric gameable but packets are not keyword-stuffing. |
| Blinded pairwise evaluation | STATISTICAL_GO — preregistered confirmatory study | N=50, 4 arms, 3 blinded same-model judge calls. Task-specific clause-append preferred over generic boilerplate at 33/50 (66%, p=0.016, Wilson CI [52.2%, 77.6%]). Task-specificity confirmed: true > deranged 47/50. Wrong-task clauses hurt: deranged < anchor 64%. Single-model judge caveat; error gate fails narrowly (6/50 vs ≤5 threshold). |
| Separatrix probe (latent interpolation) | Exploratory — interesting structural signal | Interpolating between wrong and correct perturbation vectors reveals non-monotonic correctness landscape: 74% of tasks show interior correctness islands, 47% of transitions involve deep divergence (>50 shared tokens before branching). Two mechanisms coexist (trajectory-level and format-level). Needs controls before strong claims. |
Perturbation Unlocks Capabilities That Scaling Cannot
The standard way to make a model smarter is to make it bigger. But bigger models need more VRAM, more expensive hardware, and heavier quantization that can degrade quality. Perturbation offers a different trade: instead of adding parameters, unlock the knowledge the model already has by shifting its reasoning trajectory at the embedding level.
Two random vectors injected into the embedding space before generation, scaled to match the model's native embedding RMS. No training, no optimization. The model is frozen. The only change is where it starts thinking from.
On 25 nested arithmetic tasks (multi-step expressions requiring 3-6 sequential operations), greedy decoding, max 1024 tokens:
Parameter scaling is flat; perturbation is not

Each pair of bars shows how well a model does on the same 25 math problems. Blue = the model's default accuracy. Orange = accuracy after adding 2 random embedding vectors. The dashed red line is what you get when you run the 4B model 10 times with different perturbations and take a majority vote. Making the model bigger (moving right) doesn't help — the bars stay flat or drop. But perturbation on the smallest model jumps to 72%.
| Model | Params | Quant | Baseline | Pert mean | Plurality@10 | Oracle@10 | | --- | ---: | --- | ---: | ---: | ---: | ---: | | Qwen3-1.7B | 1.7B | 4-bit | 28% | 29% | — | — | | Qwen3-4B | 4.0B | 4-bit | 32% | 52% | 72% | 100% | | Qwen3-8B | 8.0B | 4-bit | 24% | 25% | — | — | | Qwen3-8B | 8.0B | 8-bit | 16% | 29% | 56% | 80% | | Qwen3-14B | 14.0B | 4-bit | 36% | 40% | — | — | | Qwen3-32B | 32.0B | 4-bit | 0% | 0% | — | — | | DeepSeek-R1-1.5B | 1.5B | 4-bit | 76% | 74% | — | 100% | | phi-2 | 2.7B | none | 12% | 19% | — | 28% |
Within the Qwen3 family, scaling parameters from 1.7B to 32B does not improve accuracy: 28% → 32% → 24% → 36% → 0%. The 32B model at 4-bit quantization degenerates — it produces verbose natural-language explanations, exhausts the 1024-token budget, and never states an answer. The 14B model at 3.5× the FLOPs of a single 4B pass gains only +4pp.
Perturbation×10 on the smallest viable model jumps to 72% via plurality voting. Every task in the benchmark is solved correctly by at least one of the 10 seeds (100% oracle coverage).
The bottleneck is not knowledge — it is convergence. These models already know how to solve nested arithmetic. They fail because greedy decoding locks them into a verbose reasoning path that exhausts the token budget before stating the answer. More parameters do not fix this; the 14B and 32B models fail for the same reason, just more expensively.
Perturbation shifts the generation trajectory so the model finishes what it already knows how to do. This is not a marginal improvement — it is the difference between a model that cannot solve a problem (32%) and one that solves it reliably (72%), using the same weights.
Perturbation vs temperature sampling

All five bars use the same model (Qwen3-4B) and the same number of attempts (10). The only difference is how diversity is generated. Temperature sampling (blue bars) adds randomness at the token level — the model rolls dice on each word. Perturbation (orange bar) shifts the starting point in embedding space so the model reasons along a completely different trajectory. The diamonds show plurality vote accuracy; the triangles show oracle (best of 10). Perturbation generates more useful diversity at every temperature setting.
The obvious alternative to embedding perturbation is temperature sampling: run the same model 10 times with temperature > 0. Same cost, same VRAM, same number of passes. The question is which diversity source produces better plurality votes.
| Method | Mean | Plurality@10 | Oracle@10 | | --- | ---: | ---: | ---: | | Greedy baseline ×1 | 32% | — | — | | Perturbation ×10 | 52% | 72% | 100% | | Temperature 0.3 ×10 | 38% | 64% | 88% | | Temperature 0.6 ×10 | 41% | 60% | 100% | | Temperature 0.9 ×10 | 39% | 48% | 96% |
Perturbation wins at every temperature. Higher temperature actually hurts plurality — temp=0.9 drops to 48%, worse than greedy baseline with perturbation's 72%. Token-level randomness produces different words; embedding perturbation shifts the reasoning trajectory from layer 1, producing more structurally diverse completions that agree on the right answer more often.
Inference efficiency: more capability per dollar
The conventional path to higher accuracy is a bigger model. But bigger models need proportionally more VRAM, more expensive hardware, and slower throughput. Perturbation inverts this: spend compute on diversity of reasoning paths instead
Related Skills
node-connect
385.6kDiagnose OpenClaw Android, iOS, or macOS node pairing, QR/setup code, route, auth, and connection failures.
blender-python-addon
40.5kBlender Python add-on rules for operators, panels, properties, registration, testing, and API-safe scripting
flutter-development-guidelines-cursorrules-prompt-file
40.5kCursor rules for Flutter development with MVVM architecture, Riverpod state management, Material widgets, and Dart style guidelines.
commit-push-pr
140.7kCommit, push, and open a PR
