Release Notes: Adaptive Model Control
Plan with the strongest models, execute with cheaper capable models, and switch back anytime in Neo.
You now have real model-layer flexibility.
Use premium models like Opus 4.7 and GPT 5.5 for planning and architecture decisions, then switch to lower-cost models like Qwen 3.6 27B (OpenRouter) or GPT 5.4 mini (OpenAI) for execution-heavy loops. Neo keeps the workflow stable while you change model strategy as requirements change.
Why this release matters
Phase 1: Plan with high-capability models
Use models like Opus 4.7 or GPT 5.5 when you need better decomposition, stronger reasoning, and cleaner execution plans before any heavy run starts.
- Complex planning and architecture choices
- Risky refactors and deep debugging strategy
- Better first-pass plans, fewer wrong turns
Phase 2: Execute with cost-efficient models
Once the plan is clear, switch to models like Qwen 3.6 27B via OpenRouter or GPT 5.4 mini via OpenAI to run iterative implementation cycles at lower cost.
- Code edits, retries, and repetitive transforms
- Validation loops and test-driven iterations
- Lower unit cost while preserving useful quality
Reswitch whenever needed: If execution quality drops or scope changes, move back to a stronger model for a difficult step, then return to a cheaper model for bulk implementation.
Provider flexibility in practice
Neo does not lock you into a bundled model layer. You keep provider control, and choose model/provider per workflow need.
| Workflow phase | Recommended model posture | Example options |
|---|---|---|
| Planning and scoping | Higher-reasoning, premium models | Opus 4.7, GPT 5.5 |
| Execution and iteration | Cost-efficient capable models | Qwen 3.6 27B (OpenRouter), GPT 5.4 mini (OpenAI) |
| Hard blockers or regressions | Temporarily move back up-model | Return to Opus 4.7 or GPT 5.5 for critical steps |
What shipped
Execution speed improvements
- Faster preprocessing, feature engineering, and evaluation loops
- Up to 7x acceleration across common AI engineering workflows
- Higher throughput for iterative coding cycles
Execution clarity in chat
- Upfront execution plans before long runs
- Clearer step-level progress and state visibility
- More context on reasoning and approach decisions
Runtime reliability upgrades
- Improved stability under long, multi-step sessions
- Fewer runtime interruptions and retries
- Stronger recovery behavior when failures occur
Benchmarks snapshot
Data preprocessing
Before: 5-8 minutes for 1M rows
Now: 1-2 minutes (about 5-7x faster)
Model training
Before: 15-20 minutes for ensemble runs
Now: 3-5 minutes (about 4-6x faster)
Feature engineering
Before: 10-15 minutes for complex transforms
Now: 2-3 minutes (about 5-7x faster)
End-to-end workflow
Before: 45-60 minutes
Now: 10-15 minutes (about 4-5x faster)
Migration notes
- Fully backward compatible with existing tasks.
- No syntax changes for task descriptions.
- Existing provider keys and workflows continue working.
- Recommended: review your default model strategy by phase to optimize cost and quality.
Need help choosing model strategy? Start with Bring Your Own LLM Keys, then review FAQ and Getting Started.