✦
Cheap executor decision checklist
operations / playbooks/cheap-executor-decision-checklist.md
project-doc Live smoke test — 2026-04-08 project-doc Knowledge Hub session log project-doc Knowledge Hub simplification plan capture Knowledge Hub session — pi-teams prompt modes and cheap executor experiment lesson Pi-teams prompting and cheap executor lessons playbook Cheap executor decision checklist playbook Pi team lead playbook unknown Operations
Home / operations / playbooks / cheap-executor-decision-checklist.md

Cheap executor decision checklist

Properties
Type
playbook
Status
active
Curation state
canonical
Created
2026-04-08T02:30:48Z
Updated
2026-04-08T02:30:48Z
Tags
cheap-executor playbook prompting codex
ID
playbook-cheap-executor-checklist-001
Source agents
pi
Summary
Cheap executor decision checklist
operations / playbooks/cheap-executor-decision-checklist.md

Cheap Executor Decision Checklist

Use this checklist before assigning a task to a cheaper/faster model.

A. Is the slice a good candidate?

Answer yes/no: - Is it bounded to a small number of files? - Is the outcome visible or easy to verify? - Is the blast radius low? - Can a strong reviewer validate it quickly? - Is it completion/polish/integration work more than open-ended design work?

If most answers are yes, the slice is a good cheap-executor candidate.

B. Is the repo state verified?

Before assigning: - [ ] I confirmed the slice is still open in current code - [ ] I checked relevant tests - [ ] I am not assigning stale roadmap work blindly

If not checked, audit first.

C. Is the model/provider path explicit?

Before spawn: - [ ] I know which provider should serve the model - [ ] I used a fully qualified model ID when needed - [ ] auth/provider configuration is available in the spawned environment

Preferred pattern: - provider/model

Example: - openai-codex/gpt-5.4-mini

D. Is the prompt sized correctly?

Default to outcome-first.

Prompt should include: - [ ] objective - [ ] desired outcome - [ ] why it matters - [ ] context to read - [ ] necessary constraints with reasons - [ ] definition of done

Prompt should usually avoid: - [ ] unnecessary step-by-step instructions - [ ] style-only constraints - [ ] speculative guardrails not backed by evidence

E. Does the task need stronger scaffolding instead?

Use a stronger model or tighter prompt if: - the task has major ambiguity - the task requires architectural judgment - the task crosses many contracts at once - previous cheap runs failed for capability reasons, not config reasons - review overhead is already eating the savings

F. Is fallback in place?

Before starting cheap execution: - [ ] a stronger reviewer is assigned - [ ] a fallback implementer exists if needed - [ ] success/failure can be judged quickly

G. Review questions after execution

Reviewer should answer: - Did the implementation satisfy the outcome? - Did the task stay bounded? - Were tests adequate? - Did the cheap executor need more scaffolding? - Was any failure actually a provider/config problem instead of a capability problem? - Was the savings worth the review burden?

H. Decision after review

Keep cheap execution for this class of task if:

  • implementation quality was acceptable
  • review burden stayed low
  • no major prompt tightening was needed

Tighten prompts slightly if:

  • one or two repeated misses occurred
  • the fix is clearly better context or one missing constraint

Move back to a stronger model if:

  • repeated capability misses remain after minimal tightening
  • review/correction cost exceeds the savings
  • the task class is too judgment-heavy

Rule of thumb

Cheap executors are best for: - bounded UI polish - narrow integration fixes - repetitive implementation with clear done conditions

Cheap executors are poor fits for: - open-ended architecture - major refactors - high-stakes security design - ambiguous multi-boundary work without a strong contract