How Kiro Auto uses model cascading to match the model to the work
We start with an efficient initial model. A more capable model takes over when required.
Illustrative · not measured dataAnimated illustration. A coding session is drawn as a dotted trail that runs along flat, easy ground and then climbs steeply to a summit. At the trailhead, a small flag labeled initial model marks where the session begins on the efficient initial model. A small white Kiro ghost with blue accents dashes onto the trail and moves along the easy stretch, lighting the trail blue behind it. Above the trail, a lighthouse labeled independent check, in the background, shines a soft beam over the trail the ghost has already walked, from the trailhead to just behind the ghost; the ghost keeps moving and never stops for it. Where the trail turns into a steep climb, the lighthouse’s lens brightens once, and a bigger white ghost with purple accents arrives, takes a small glowing orb from the small ghost, and carries on up the climb, lighting the trail purple. The small ghost steps aside and waves, and the blue trail behind it stays lit. Text in the illustration reads “We start with an efficient initial model. A more capable model takes over when required.”
TL;DR. Behind the scenes, Auto uses model cascading. Every session starts on an initial model, an independent check reviews the work in the background, and Auto hands the session to a more capable model when the work calls for it. In an internal evaluation on DeepSWE v1.1, the cascade performed nearly as well as the more capable model on its own, and about four in five tasks finished without a handoff.
Auto is how we recommend most people work in Kiro. As our model docs describe, Auto picks the model for you and holds a high quality bar. On paid plans, that means Claude Opus-class quality. This post looks at one of the ways Auto meets that bar, a technique called model cascading.
You ask Kiro to fix a flaky date parser. The early steps are routine. Read the file, find the function, write a failing test. Then the test exposes a timezone assumption that runs through three other modules, and the small fix becomes a refactor. The reverse happens too, when a task that looked big turns out to be a two-line change.
As models get more capable, you hand them bigger jobs, and Kiro sessions run longer. A long-horizon session takes many steps, from reading files and editing code to running tests and trying again, and its difficulty isn’t fixed when it starts. It has a shape, and you only see that shape as you go. Figure 1 runs the same session three ways.
Difficulty shows up as the session unfolds. A choice made at the start can’t see it coming.
One session, three ways
Pick the more capable model up front
More than the easy stretch needs.
capability the easy stretch didn’t need
Pick an efficient model up front
Comes up short on the climb.
under-powered on the climb
Cascade · keep deciding
Starts lean, moves up for the climb.
not needed
hands off
Illustrative diagram, not measured data. Three stacked lanes show the same coding session, with session progress running left to right and difficulty rising upward. The opening sliver of every lane is labeled same opening request. In the default session, which turns hard, the difficulty line starts low with small bumps, climbs steeply a little before the middle, stays high, and eases near the end. Lane 1, Pick the more capable model up front, shows a flat purple capability line, decided here based on the initial request, sitting high above the whole session; the space between it and the low early difficulty is shaded and labeled capability the easy stretch didn’t need. Its verdict reads more than the easy stretch needs. Lane 2, Pick an efficient model up front, shows a flat blue line, decided at the start, sitting low; where the difficulty climbs above it, the gap is hatched and labeled under-powered on the climb. Its verdict reads comes up short on the climb. In lane 3, Cascade, keep deciding, the line starts low in blue, steps up to purple shortly after the climb begins, labeled hands off, and stays purple to the end. A dotted outline between the blue stretch and the high purple level is labeled not needed. A small ghost rides the blue part and a bigger ghost rides the purple part. Its verdict reads starts lean, moves up for the climb. As you scroll, a fog lifts from left to right, showing that difficulty is only visible as the session unfolds, while the two up-front lines are drawn in full from the start. A toggle switches to a session that stays easy. There, the up-front lines don’t change, the efficient pick fits, the more capable model is more than the session needs the whole way, and the cascade stays blue with no handoff.
When you pick a model before the work starts, the request is the only thing you have to go on. If you pick the more capable model, it handles every step, including the routine ones an efficient model could have done just as well. If you pick an efficient model, it handles the routine steps well, but when the work turns hard, it can start going back and forth and redoing work it has already done. Now switch the figure to a session that stays easy. The up-front choices don’t change, because the request is the same. The cascade stays on the initial model the whole way, because the session never gets harder than that model can handle.
Model cascading turns one model choice into a sequence of decisions, made over a whole agent session rather than a single up-front decision.
- Start on an efficient model. Every session starts on an initial model, an efficient model that handles a wide range of everyday work well. In many sessions, it’s the right choice and performs all of the work.
- Check the work in the background. An independent model reviews the session’s trajectory, or what work has been performed so far. The check runs asynchronously, so the session never waits on it, and the working model never grades its own progress.
- Keep going, or hand off. While the session makes steady progress, nothing changes. If the check sees signs that the session has stopped making efficient progress (such as repeated exploration of the same code, or redoing work that’s already done), Auto hands the session to a more capable model. The handoff carries forward the crux of the work so far, so the more capable model picks up the session as it stands instead of starting over.
- Repeat as needed. This can repeat until the session is running on the most capable model. Today, handoffs only go up. Handing a session back down to an efficient model is something we’ll explore in a future update.
For teams that manage model access, a handoff can use any model Auto can use, so it follows the same governance settings as Auto. See model governance for how administrators control model access.
Every session starts lean. A more capable model takes over when the work calls for it.
Start lean. The initial model begins the session, and often it does all of the work.
Checked in the background. An independent check reviews the work so far. The session doesn’t stop for it, and while things are on track, nothing changes.
Hand off. When the check sees signs that the session has stopped making efficient progress, a more capable model picks up the same trail, right where the session left off.
Repeat as needed. This can repeat until the session is running on the most capable model. Handing a session back down to an efficient model is something we’ll explore in a future update.
Start lean. The initial model begins the session, and often it does all of the work.
Checked in the background. An independent check reviews the work so far. The session doesn’t stop for it, and while things are on track, nothing changes.
Hand off. When the check sees signs that the session has stopped making efficient progress, a more capable model picks up the same trail, right where the session left off.
Repeat as needed. This can repeat until the session is running on the most capable model. Handing a session back down to an efficient model is something we’ll explore in a future update.
Illustrative four-step diagram of model cascading in Auto. In step 1, start lean, a small white ghost with blue accents, labeled initial model, starts a session on a winding trail, leaving blue footprints. In step 2, checked in the background, a lighthouse labeled independent check, in the background, shines its beam over the trail the ghost has already walked, from the trailhead to just behind the ghost, while the ghost keeps moving. In step 3, hand off, the trail loops back on itself, a generic picture of a session going in circles; the beam settles on the loop, and a bigger white ghost with purple accents, labeled more capable model, arrives, takes a small glowing orb from the small ghost, and continues along the same trail from that point while the small ghost steps aside and waves. In step 4, repeat as needed, the bigger ghost climbs to a summit marked with a check, leaving purple footprints, while the earlier blue footprints stay lit; a dashed upward arrow at the side runs from initial model to most capable model and reads can repeat.
Think of an engineer working a ticket with a reviewer looking over their shoulder. The engineer keeps working and never stops to grade their own progress. That’s the reviewer’s job. As long as the work keeps moving forward, the reviewer stays quiet. When the reviewer sees the work going in circles, the ticket moves to a more capable engineer, who picks it up as it stands.
This is what makes a cascade safe to run by default. The working model doesn’t grade its own progress, and a handoff builds on the work already done instead of starting over. When a session needs more capability, it gets it partway through, and when it doesn’t, it stays on the initial model.
We evaluated cascading on DeepSWE v1.1, Datacurve’s long-horizon software engineering benchmark. Its tasks are original, drawn from open-source repositories, and graded by hand-written behavioral tests, so they call for the kind of multi-step session where difficulty can shift. We ran three configurations in the Kiro agent engine, and each configuration ran on the entire benchmark three independent times.
- Initial model alone. Every task runs on the efficient initial model from start to finish.
- More capable model alone. Every task runs on the more capable model from start to finish.
- Cascade. Every task starts on the initial model, with the more capable model available for a handoff.
All three configurations used the same reasoning settings. The only difference between them is which model handles the work. We report pass@1, the share of tasks solved in a single attempt, as the average across the three runs ± one standard deviation.
Figure 3 compares pass@1 for the three configurations, and the table below it lists the same values.
Nearly the same quality as the more capable model alone. Even though every task starts on the initial model.
DeepSWE v1.1 · Kiro agent engine · 3 runs
pass@1, average ± one standard deviation across three runs
nearly equal · within run-to-run spread
Dot chart of pass@1 on DeepSWE v1.1, three runs, in the Kiro agent engine, one row per configuration. The horizontal axis is pass@1 from 60% to 74%; it does not start at zero. Initial model alone, pass@1 63.96%, plus or minus 2.70. Cascade, with the initial model starting and the more capable model available, pass@1 69.37%, plus or minus 1.56. More capable model alone, pass@1 70.57%, plus or minus 2.08. Horizontal error bars show one standard deviation across three runs. The cascade’s and the more capable model’s bars overlap, the overlap is shaded, and a bracket joining the two rows reads nearly equal, within run-to-run spread. The same values appear in the table below the figure.
| Configuration | pass@1 (average ± 1 sd, 3 runs) |
|---|---|
| Initial model alone | 63.96% ± 2.70 |
| More capable model alone | 70.57% ± 2.08 |
| Cascade (initial model starts, more capable model available) | 69.37% ± 1.56 |
The cascade solved 69.37% of tasks, nearly matching the more capable model on its own (70.57%, within the run-to-run spread) and 5.40 points above the initial model alone (63.96%). It also varied the least from run to run of the three configurations. In other words, starting every task on the initial model didn’t hold quality back.
Figure 4 shows where the cascade’s tasks finished.
Most tasks never left the initial model. About one in five handed off.
DeepSWE v1.1 · cascade · 3 runs
80.48%
finished on the initial model alone
19.52%
started on the initial model, handed off to the more capable model
Unit chart of 200 squares, each representing about 0.5% of DeepSWE v1.1 task runs in the cascade configuration, pooled across three runs. 161 solid blue squares, 80.48%, are tasks that finished on the initial model alone. 39 squares, 19.52% or about one in five, are filled purple with a thin blue outline and a white center dot. They are tasks that started on the initial model and were handed off to the more capable model. By default the handed-off squares are grouped at the end of the grid; a toggle scatters them across the grid at illustrative positions. Large labels read 80.48% finished on the initial model alone and 19.52% started on the initial model, handed off to the more capable model.
Each square ≈ 0.5% of task runs, pooled across three runs. Squares show where a task finished, not how its work was split between models. Scattered positions are illustrative.
Show data
| Outcome (cascade) | Share of task runs |
|---|---|
| Finished on the initial model alone | 80.48% |
| Started on the initial model, handed off to the more capable model | 19.52% |
Across all runs, 80.48% of tasks finished on the initial model. The other 19.52%, about one in five, were handed off to the more capable model partway through.
In our DeepSWE runs, the tasks that were handed off had something in common. They were changes that are hard to get right end to end, such as features that touch many layers at once, from types and APIs to the CLI and configuration, or behavior that depends on saved state, caching or ordering. Small, localized changes rarely needed a handoff, but a large change didn’t always need one either. What mattered was how much of the work depended on careful design and on several parts of the code staying consistent with each other.
When the handoff happened is just as telling. In these tasks, the initial model almost always got through the early steps on its own, writing the code and often getting builds and tests to pass. The handoff tended to come later, during verification and integration. That’s when the check saw signs that the session had stopped making efficient progress, as the initial model worked to show that every requirement held across the code it had changed. None of that was visible from the request. A cascade doesn’t need to know in advance when the work will get hard, because the check keeps watching and a handoff can happen at whatever point the session needs it.
This is one of the reasons Auto can take on complex work at high quality while charging a 1x credit multiplier. Most sessions finish on the initial model, and the more capable model takes over only when the work calls for it.
These numbers come from a specific run of an internal evaluation benchmark. They are not a production estimate, and results on individual customer workloads in production will vary.
The handoff rate is an average across tasks. How often a session hands off depends on the work, so individual sessions will vary. The user does not see the handoff or need to be aware that it is happening in order to gain its quality benefits.
DeepSWE numbers come from an internal benchmarking harness which is not identical to the official setup of the public DeepSWE leaderboard. Percentages should not be compared to the public leaderboard.
Model cascading is part of how Auto works, and the efficiency benefits are available to every Kiro customer. Select Auto in Kiro when you start your next session. See the models overview for documentation on how Auto and model selection work.