Shinka Evolve routes code mutations across frontier models in real time, and the architecture paper confirms it
Sakana AI's Shinka Evolve does not pick one large language model and commit to it. It selects among competing frontier providers on the fly, using a bandit algorithm to route each program mutation to whichever model has been performing best. The architecture is more ambitious than most automated code-evolution systems, and the published paper backs the claim.
Robert Lange, a researcher at Sakana AI, has described how Shinka Evolve handles one of the central engineering decisions in any system that relies on large language models: which model to use, and when. The answer the team settled on is that no single model wins across all situations. The system queries multiple frontier providers and determines, program by program and mutation by mutation, which one is currently the better choice.
The claim is specific. Lange says the system draws on “basically all frontier model providers,” naming GPT and Gemini as examples, and that it routes work through what he calls an adaptive prioritization scheme capable of adjusting the evolutionary algorithm in real time. That is not a general aspiration toward multi-model flexibility. It describes a mechanism that changes its own behavior based on observed performance.
Sakana AI’s published paper on Shinka Evolve, posted to arXiv in September 2025 and accompanied by a blog post on the company’s site, confirms the architecture in concrete terms. According to that paper, the system incorporates GPT, Gemini, and Grok as providers and uses an Upper Confidence Bound bandit algorithm to adaptively route each program mutation to whichever model has been performing best at that point in the run. The Upper Confidence Bound approach is a classical method in reinforcement learning for balancing exploitation of known-good options against exploration of alternatives that might outperform them. Applying it to model selection in an evolutionary code search is less standard, and the paper’s description maps directly onto Lange’s account.
We're not using just Gemini but we're using basically all frontier model providers and figuring out a smart way how to use each model for a given parent, if you have a certain program in some situations it might be better to use a sort of GPT model in other settings it might be better to use Gemini model. And we sort of introduce a sort of adaptive prioritization scheme that can adapt sort of the evolutionary algorithm on the fly Robert Lange
The significance of that design choice is worth unpacking. Most systems that use large language models for code generation or program search pick a provider and stay there. The cost of routing dynamically is coordination overhead and the engineering work required to maintain live performance estimates across providers. The benefit is that no single model’s weaknesses become the system’s ceiling. If GPT handles one class of program transformation better and Gemini handles another, a static choice leaves performance on the table. A bandit-based routing layer, in principle, captures both.
Lange frames the adaptive prioritization as something that operates “on the fly,” meaning it is not a configuration set once at the start of a run. The evolutionary algorithm itself is the subject of the adaptation. That distinction matters because it places the routing logic inside the search loop rather than upstream of it. The system is not just selecting a model at initialization; it is continuously updating its own model preferences as the search progresses and the evidence about which provider is outperforming changes.
The external record adds two further details that Lange’s description gestures at but does not specify. The Sakana AI blog and GitHub repository indicate that Grok is among the providers alongside GPT and Gemini, and the Upper Confidence Bound framing gives the prioritization scheme a precise algorithmic identity. The paper does not contradict any element of what Lange described. It extends it with technical specificity.
What the combination of Lange’s account and the published materials establishes is that Shinka Evolve is an architectural bet on model diversity rather than model loyalty. The assumption built into the system is that frontier models are not interchangeable, that their relative strengths vary by task, and that a routing layer capable of learning those strengths in real time will outperform any static selection. Whether that bet pays off at scale is what the benchmarks in the paper address. The architecture itself is already in the public record.