Ecomode

Ecomode deprecated

Hard-deprecated. Do not invoke or route this skill. Use $ultrawork directly for maintained high-throughput execution workflows.

What Ecomode Does

Overrides default model selection to prefer cheaper tiers:

What Ecomode Does NOT Do

• Persistence: Use ralph for "don't stop until done"
• Parallel Execution: Use ultrawork for parallel agents
• Delegation Enforcement: Always active via core orchestration

Combining Ecomode with Other Modes

Ecomode is a modifier that combines with execution modes:

Ecomode Routing Rules

ALWAYS prefer lower tiers. Only escalate when task genuinely requires it.

Agent Selection in Ecomode

FIRST ACTION: Before delegating any work, read the agent reference file:

Read file: references/agent-tiers.md

This provides the complete agent tier matrix, MCP tool assignments, and selection guidance.

Ecomode preference order:

// PREFERRED - Use for most tasks
use /prompts:executor for this scoped task
use /prompts:explore for this scoped task
use /prompts:architect for this scoped task

// FALLBACK - Only if LOW fails
use /prompts:executor for this scoped task
use /prompts:architect for this scoped task

// AVOID - Only for planning/critique if essential
use /prompts:planner for this scoped task

Delegation Enforcement

Ecomode maintains all delegation rules from core protocol with cost-optimized routing:

Background Execution

Long-running commands (install, build, test) run in background. Maximum 20 concurrent.

Token Savings Tips

1. Batch similar tasks to one agent instead of spawning many 2. Use explore (LOW tier) for file discovery, not architect 3. Prefer LOW-tier executor routing for simple changes - only upgrade if it fails 4. Use writer (LOW tier) for all documentation tasks 5. Avoid THOROUGH-tier agents unless the task genuinely requires deep reasoning

Disabling Ecomode

Ecomode can be completely disabled via config. When disabled, all ecomode keywords are ignored.

Set in ~/.codex/.omx-config.json:

{
  "ecomode": {
    "enabled": false
  }
}

State Management

Use the CLI-first state surface (omx state ... --json) for ecomode lifecycle state. If explicit MCP compatibility tools are already available, equivalent omx_state calls are optional compatibility, not the default.

• On activation:

omx state write --input '{"mode":"ecomode","active":true}' --json

• On deactivation/completion:

omx state write --input '{"mode":"ecomode","active":false}' --json

• On cancellation/cleanup:

run $cancel (which should call omx state clear --input '{"mode":"ecomode"}' --json)

Agent Tiers

This file defines practical tier guidance for OMX agent routing.

Mental Model

OMX now separates three concepts:

• role: what the agent is responsible for (executor, planner, architect)
• tier: how much reasoning/cost to spend (LOW, STANDARD, THOROUGH)
• posture: how the role behaves (frontier-orchestrator, deep-worker, fast-lane)
• exactModel: optional role pin that bypasses tier defaults when a role needs a

specific model contract.

Use role to choose responsibility, tier to choose depth, and posture to choose operating style.

Tiers

• LOW:

Fast lookups and narrow checks. Use for simple exploration, style checks, and lightweight doc edits. Typical roles: explore, style-reviewer, writer.

• STANDARD:

Default tier for implementation, debugging, and normal verification. Typical roles: executor, debugger, test-engineer, quality-reviewer.

• THOROUGH:

Use for architectural, security-sensitive, or high-impact multi-file work. Typical roles: architect, critic, security-reviewer, executor. Note: deep-executor is deprecated; route implementation to executor.

Selection Rules

1. Start at STANDARD for most code changes. 2. Use LOW only when the task is bounded and non-invasive. 3. Escalate to THOROUGH for:

• security/auth/trust-boundary changes
• architectural decisions with system-wide impact
• large refactors across many files

4. For Ralph completion checks, use at least STANDARD architect verification.

Posture Guidance

• frontier-orchestrator:
• Best for steerable frontier models and leader-style roles.
• Prioritizes intent classification, delegation, verification, and architectural judgment.
• Typical roles: planner, analyst, architect, critic, code-reviewer.
• Ralplan keeps planner and architect in this posture but pins them to

exact gpt-5.4-mini with high reasoning; the critic consensus gate stays on the frontier lane.

• deep-worker:
• Best for implementation-heavy roles that should carry work to completion.
• Prioritizes direct execution, minimal diffs, and strict verification.
• Typical roles: executor, debugger, test-engineer, build-fixer.

• fast-lane:
• Best for cheap/fast models used for triage, search, and narrow synthesis.
• Prioritizes quick routing, concise search, and escalation over deep autonomous work.
• Typical roles: explore, writer, and lightweight research/search specialists.