Introducing Sanad 0.1

Reason together before the answer is finished

Most model ensembles make their decision late. They sample complete answers, rank candidates, vote, or ask another model to synthesize the finished outputs. That diversity can be useful, but by the time the system chooses a direction, each model has already spent most of its reasoning budget.

Sanad 0.1 starts from a different hypothesis: on a software task, the direction of a solution can matter as much as the final wording. A wrong invariant, a misread API, or an early architectural mistake can shape everything that follows. We want models to exchange useful signal while those choices are still reversible.

Phase-Locked Consensus Decoding

We call the mechanism Phase-Locked Consensus Decoding. Participating models advance in a synchronized reasoning rhythm. A consensus layer examines their emerging trajectories, estimates where useful convergence is forming, and returns a steering signal before the answer is complete.

This is not intended as a winner-takes-all vote. A promising trajectory may exert more influence for one phase, while the other models retain the capacity to object, branch, or repair. Synchronization matters because heterogeneous models can use different tokenization and move through a solution at different speeds. Combining every signal at every token would be both expensive and brittle.

How it differs from nearby approaches

Sanad 0.1 belongs in a broader line of inference-time work rather than outside it. Self-consistency samples multiple reasoning paths and selects the most consistent completed answer. Mixture-of-Agents passes outputs through layers of model agents. Debate and reranking systems similarly use model diversity to refine or select responses.

Our narrower question is about timing: can coordination become useful earlier, while a coding plan or repair is still forming? Sanad 0.1 keeps whole models active at inference time. It is not weight averaging, task arithmetic, or expert routing inside a single checkpoint.

Why begin with software engineering

Software work provides unusually strong feedback. Repositories expose architecture and conventions. Compilers and type systems reject invalid assumptions. Tests, diffs, stack traces, and runtime output make many errors observable. These signals give a coordinated system something concrete to inspect before committing to a patch.

The evaluation landscape also spans several useful levels. HumanEval established functional correctness and showed that repeated sampling can improve the chance of producing a working program. SWE-bench moves into real repositories and issue-driven repair. LiveCodeBench broadens evaluation to contamination-resistant generation, self-repair, execution, and test-output prediction.

That progression matches what we need to learn: whether synchronized multi-model inference improves not just fluent code, but working changes that remain faithful to a real project.

What we plan to measure

The first release is not a benchmark victory announcement. The evaluation must separate the architecture from the strength of its constituent models and account for the additional compute it consumes.

• Functional correctness: pass rates on synthesis and repair tasks, including comparison with repeated sampling from a single model.
• Repository fidelity: whether changes solve the requested issue without introducing unrelated edits or violating local conventions.
• Coordination value: ablations for model diversity, consensus sharpness, steering cadence, and the number of participating models.
• Systems cost: wall-clock latency, synchronization overhead, compute budget, and marginal gain per added submodel.

A useful result must improve software outcomes enough to justify the coordination cost. Anything less is an interesting mechanism, not a useful product.

Limitations are part of the design

Parallel inference is expensive. Different tokenizers and low-consensus phases can make coordination unstable. Correlated models may agree on the same mistake, turning consensus into amplification rather than correction. Continuous influence also makes attribution more difficult than simple best-of-N selection.

Those are central constraints, not edge cases. Sanad 0.1 is our first test of whether selective, synchronized steering can handle them well enough for development work. We will publish measured results separately when the evaluation is ready.