---
name: cost-aware-agents
description: Task-aware orchestration for coding, investigation, document processing, and batch tasks. Allocate Luna, Terra, or Sol subagents and reasoning effort to minimize expected whole-task cost subject to reliable completion and timely delivery. Use for delegable work, including simple tasks, or requests for efficient subagent allocation.
---

# Efficient agent orchestration

Minimize expected whole-task cost among execution plans that can reliably satisfy the same task, acceptance criteria, and delivery-time requirements. Quality and timely completion are constraints, not optional tradeoffs for cheaper model calls. Optimize the complete execution plan, not each worker's unit price. When this skill applies, explicitly use subagents for suitable work, including simple work; complexity is not a prerequisite. The main agent owns scope, routing, integration, and acceptance. This skill requests delegation and model/reasoning overrides within the current task, not new user-owned chats.

## Decide before doing the work

Make a lightweight routing decision before performing substantial analysis yourself. Delegate a clear, bounded task when the selected worker improves expected whole-task cost while preserving timely, reliable completion. A higher-priced model that finishes correctly in one pass may be the economical choice. Prefer one worker for a simple task; batch similar items instead of spawning per item. Do not first solve the task in the main agent and then ask a worker to repeat it.

Handle tiny answers, single trivial edits, and one-call lookups directly when delegation overhead would dominate. Also execute directly when the parent offers the best feasible overall execution plan, essential context cannot be transferred economically, or delegation tools are unavailable. Do not create agents merely to meet a quota.

Estimate total cost qualitatively as parent planning + transferred context + all worker execution + coordination + integration + verification + likely retries and rework. Estimate wall-clock time from startup, dependent steps, the longest parallel path, integration, and likely retries; do not sum parallel durations as elapsed time. Token count, latency, and billed money are different measures. Use prices or usage only when actually available; otherwise state a qualitative allocation judgment, never measured savings, guaranteed speed, or a mathematically optimal price. Respect explicit user model, budget, speed, and quality preferences.

## Choose a feasible plan

Compare a few plausible plans briefly: direct execution, one well-matched worker, or a small independent parallel split. Exclude plans with an unreasonable likelihood of missing acceptance or delivery requirements; choose the lowest expected total cost among the remaining plans. Do not spend more effort optimizing the schedule than the task warrants.

Use an explicit deadline or latency preference when provided. Otherwise aim for completion without avoidable delay relative to a straightforward competent execution: do not serially trial weak configurations to save on individual calls, or leave readily parallelizable bottlenecks idle. Ask about timing only when a substantial unresolved cost/time tradeoff materially affects the outcome; do not invent an exact deadline.

Choose adequate capability up front. Start directly with Sol or higher effort when the task's ambiguity, risk, or critical path makes cheaper trials likely to cause rework or delay. Escalation is a recovery mechanism, not a required staircase. Prefer fast decisive execution on the critical path and economical workers for independent routine work.

## Model and effort routing

Inspect the current spawn-tool schema and available model catalog before choosing identifiers and supported effort levels. The following are local defaults observed on 2026-10-28, not a permanent pricing or capability ranking:

| Work | Preferred candidate | Starting effort |
| --- | --- | --- |
| File search, extraction, formatting, repetitive clear edits, bounded summaries | Luna (`gpt-6-luna`) | low; medium if interpretation is needed |
| Local implementation with clear acceptance, ordinary tests, bounded refactors | Terra (`gpt-6.1-terra`) | medium; low for mechanical edits |
| Ambiguous bugs, cross-module design, difficult integration, consequential correctness decisions | Sol (`gpt-6.1-sol`) | high; medium when the scope is already resolved |

Choose model and effort separately. A bounded but intricate algorithm may justify Luna/high or Terra/high; a large batch of mechanical changes does not justify Sol/high merely because it is large. Terra is a coding-oriented candidate, not a verified middle price tier. When live prices or observed task performance contradict these defaults, choose the available combination with the lowest expected whole-task cost that still meets quality and timing needs.

Reserve xhigh/max/ultra for demonstrated reasoning difficulty, supported models, and a benefit proportional to the cost. Never default all workers to the parent's highest effort. Missing tools, credentials, permissions, or user decisions are not reasons to increase reasoning effort.

If a preferred model is unavailable, choose another explicitly available suitable model and disclose a material change in cost strategy. Do not invent model IDs or silently fall back to an expensive parent. If overrides are unsupported, explain that limitation and use inherited settings only when delegation still helps; do not claim cheaper execution.

## Dispatch compact, executable tasks

Use the current runtime's subagent tools. Do not use app `create_thread` to simulate workers or modify global model defaults. In runtimes exposing `collaboration.spawn_agent`, pass explicit `model` and `reasoning_effort`, and use `fork_turns: "none"` for those overrides. Full-history forks may reject overrides and also copy expensive context. In other runtimes, follow their actual schema; never copy unsupported argument names.

Send each worker only the context required to succeed:

```text
Role: execution worker, not an orchestrator. Do not spawn further agents.
Objective: [one bounded outcome and why it matters].
Inputs: [absolute workspace paths, relevant facts, minimal excerpts].
Constraints: [user requirements, applicable AGENTS.md/skills/ledger rules,
authorization limits, concurrent edits and files you may own].
Acceptance: [observable behavior and proportionate verification].
Stop/escalate: report missing inputs, access blocks, or a failed approach
with evidence; do not broaden scope or repeatedly retry the same approach.
Return: concise result, touched files, evidence/check results, unresolved risks.
```

Fresh-context workers do not inherit conversational facts: include the user's relevant decisions and constraints explicitly. They must read applicable repository instructions before editing. Keep secrets out of task briefs. Skill-directed delegation does not expand authorization for external actions or bypass approval.

Use one worker for a single bounded task. For larger tasks, choose concurrency from dependencies, critical-path duration, tool contention, and integration cost rather than a fixed headcount. Run independent substantial work in parallel when this preserves delivery speed at acceptable total cost; obey actual slot limits and avoid splitting trivial work. Do not perform redundant parallel attempts unless their expected reduction in consequential delay or failure justifies the extra cost. Assign exclusive file ownership for concurrent edits. Serialize shared-file changes and dependent steps. Parent may do complementary work while waiting, but must not duplicate worker execution. Stop obsolete workers when the user changes scope.

## Verify and adapt

Review the worker's concrete result, not just its confidence. For a small edit, inspect the diff and a relevant check; for extraction, sample source-to-output matches; for a bug fix, require evidence that the failing behavior is corrected. Scale verification to risk, and avoid re-running already credible checks without a reason. Independent review is optional for consequential changes, not a mandatory second worker on every task.

If a worker fails:

1. Distinguish missing context, access/tool failure, specification ambiguity, and reasoning failure.
2. Correct a small context gap with one focused follow-up to the same worker.
3. For demonstrated reasoning failure, raise effort one useful level or transfer to a better-suited model. Carry forward evidence, unsuccessful attempts, and existing changes so the new worker does not restart blindly.
4. Allow at most two escalations for the same bounded task before the parent reassesses the approach, takes over, or reports the real blocker. Do not create an endless retry chain. An agent whose model cannot be changed requires a new appropriately configured worker; do not pretend a follow-up changed its model.

Reassess model/effort for later mechanical work after a hard problem is resolved; switch only when expected savings exceed context-transfer and startup overhead. Worker agents receiving this skill must execute their assigned task without recursively reapplying its orchestration rules, unless the parent explicitly delegates orchestration too.

Give one short dispatch update naming the selected model/effort and purpose. At completion, summarize the outcome, verification, and any material routing limitation or escalation. Do not produce a long scheduling report unless requested. Report exact costs only with actual accounting evidence.

## Basis and limitations

[Official OpenAI subagent documentation](https://learn.chatgpt.com/docs/agent-configuration/subagents) supports skill-triggered delegation, separate model/effort selection, and lower-cost Luna use for bounded work. It also notes that multi-agent runs introduce additional token overhead. Live runtime capabilities take precedence over this skill's example identifiers. Automatic skill discovery makes this strategy eligible for selection; it is not a background service or a guarantee that every chat loads it.