Configuring a run
Choosing models
Balanced or Powerful, what a tier sets, and when a bigger model actually pays off.
There is one model choice to make: Balanced or Powerful. We pick and maintain the models behind each tier, so a run always uses models we have tested for RTL work.
The quick picker
The model button on the composer, and the Model control in Run setup, offer two tiers:
| Model | When to reach for it |
|---|---|
| Balanced model | The default, and the right answer most of the time. Balanced across quality, speed and cost. |
| Powerful model | Most rigorous. Worth it for intricate protocol logic, tricky clock-domain crossings, and anything you would otherwise spend an afternoon reviewing. |
What a tier sets
The tier applies to every model the run uses. In Agent mode that is the agent itself. In Plan mode a run has three roles, and the tier sets the generator and the verifier:
| Role | What it does |
|---|---|
| Planner | Writes the clarifying questions in Plan mode and folds your answers into the specification. The same model on either tier. |
| Generator | Writes the RTL and the testbench. The one that matters most. |
| Verifier | Used by Reflection to review and repair the module after a failed simulation. It is only paid for when a run actually fails. |
Note
Individual models cannot be chosen per role. When a better model is released, we switch to it and the tier you picked stays the same.
Does a bigger model actually help?
Sometimes, and it is worth being honest about when:
- It helps on specifications with several interacting requirements, multi-clock designs, protocol compliance, and code that has to fit into conventions described in prose rather than in the code itself.
- It rarely helps on a counter, a shift register, a mux, or a small state machine. A cheaper model writes those correctly, and the run finishes sooner.
- It never fixes a vague spec. If the description is ambiguous, a larger model produces a more confident version of the wrong module. Spend the effort on the spec first.
Models and cost
Model choice, context size and tools all affect how much credit a run uses; a run is charged for the work it actually did rather than at a fixed price. Your billing page quotes a typical figure so a balance means something at a glance, and lists the real charge for every completed run. See Plans and Billing and usage.