megara-arevaco Plan Strong, Implement Cheap
Use model specialization to reduce total cost without weakening acceptance criteria. Planning quality, implementation scope, validation, and escalation are separate decisions.
This workflow authorizes subagent delegation only for the task the user placed in scope. It does not expand filesystem, network, destructive-action, approval, or external-write permissions.
Decide Whether Splitting Saves Work
Do not delegate a trivial, one-file, obvious change when coordination would likely cost more than direct execution. Use this workflow for nontrivial work that benefits from an explicit plan and has a bounded implementation phase.
If model selection or subagents are unavailable, perform the same stages with the current agent and state that model-level routing was unavailable. Never claim a cheaper model was used unless it actually was.
Stage 1: Plan With Strong Reasoning
Use gpt-5.6-sol with high reasoning for genuinely complex planning when model override is available. If the primary agent already has equivalent capability, plan locally rather than spawning a redundant planner.
Planning is read-only unless the user has also authorized implementation. Inspect the relevant code and produce a compact implementation contract containing:
- desired outcome and in-scope files or components;
- important constraints, existing conventions, and user-owned changes to preserve;
- ordered implementation steps with clear boundaries;
- acceptance criteria and validation commands;
- risk classification: low, normal, or high;
- uncertainties that the implementer must verify rather than assume.
Avoid speculative architecture and exhaustive prose. Pass the implementer only the contract and the minimum relevant context. When spawning with a model override, use a limited history fork rather than copying the full conversation if the orchestration API requires that distinction.
Stage 2: Route Implementation by Risk
Choose the cheapest model that is still appropriate:
| Route | Model and effort | Suitable work |
|---|---|---|
| Low risk | gpt-5.6-luna, medium |
Mechanical edits, isolated UI changes, straightforward tests, formatting, repetitive migrations, and implementation with precise acceptance criteria |
| Normal risk | gpt-5.6-terra, medium |
Ordinary feature work, multi-file refactors, debugging, integration work, and changes requiring moderate judgment |
| High risk | gpt-5.6-sol, high |
Security-sensitive code, destructive migrations, concurrency, authentication or authorization, data integrity, ambiguous architecture, and failures whose impact is expensive |
Do not force Luna onto work whose correctness depends on broad architectural judgment. When uncertain between Luna and Terra, choose Terra. Preserve a user-specified model even if this table recommends another.
Use one implementation agent by default. Parallelize only when workstreams are independent, have non-overlapping ownership, and the expected latency or quality benefit outweighs duplicated context. Tell the implementer to:
- inspect current files before editing;
- preserve unrelated user changes;
- follow the implementation contract without expanding scope;
- run the specified validation;
- report changed files, validation results, remaining uncertainty, and any deviation from the plan.
Stage 3: Verify Economically
The primary agent must inspect the actual diff and validation evidence. Do not accept a subagent's success claim as proof.
- For low-risk work with passing targeted tests and a clean diff, finish without a second model review.
- For normal-risk work, review the risky portions and run proportionate validation locally.
- For high-risk work, use Sol for implementation or a focused final review; do not rely on Luna as the sole reviewer.
Prefer deterministic checks—tests, type checking, linting, builds, schemas, or reproducible commands—over additional model commentary.
Retry and Escalation Limits
Allow at most one focused retry at the same cheap tier when the failure is clear and bounded. Then escalate:
Luna failure or ambiguity -> Terra
Terra failure or high-risk discovery -> Sol
Do not bounce the whole task repeatedly between models. Escalate only the failing portion with the error, relevant diff, and acceptance criterion. Stop and ask the user when progress requires new authority or a material scope decision.
Cost Discipline
- Keep prompts lean and avoid copying unrelated conversation or repository content.
- Do not spawn separate planning, implementation, and review agents when one of those stages adds no measurable value.
- Reuse the accepted plan instead of asking the implementation agent to rediscover architecture.
- Prefer targeted tests before broad expensive suites, while still running broader validation when risk requires it.
- Report model routing and any escalation in the final handoff. Report token or monetary savings only when actual usage data is available; otherwise describe the routing without inventing estimates.
The objective is the lowest-cost path that still meets the same correctness bar, not the lowest-priced model at every stage.