Codex Orchestrator

Codex Orchestrator

Enables safe, isolated Codex implementation runs with planning approval, verification, and bounded fixes, without merging or pushing code automatically.

Category
访问服务器

README

Codex Orchestrator — Phase 7

Phase 7 implements a token-efficient adaptive coding-agent workflow. The target is to approach Sol medium-to-high reliability while avoiding Sol-scale token and price usage on every step. After plan approval, a short Luna scout trajectory chooses the smallest reliable execution shape. One Terra implementer is the default. Two or three Terra implementers run in parallel only when repository evidence proves independent, non-overlapping path groups. Sol is reserved for low-confidence review, high-risk code, retries, and verification-driven fixes.

Quality-per-token policy

PLAN
  -> Luna-low SCOUT
     -> single: one Terra-high implementer                 [default]
     -> parallel: two or three independent Terra-high implementers
     -> optional Sol-medium reviewer                       [conditional]
  -> budget admission
     -> keep plan when projected tokens and cost fit
     -> collapse parallel scopes into one implementer when they do not fit
     -> reject instead of removing a required Sol quality gate
  -> deterministic integration
  -> deterministic verification
  -> Sol fix only after verification failure or escalation
  -> verified delivery and optional Draft PR publication

The controller, not the supervisor model, owns model selection, reviewer retention, budget admission, and escalation. The supervisor cannot request extra agents or a more expensive model directly.

Deterministic routing

Work Model profile
Scout and topology selection Luna, low effort
Normal plan Terra, medium effort
Normal implementation Terra, high effort
Low-confidence or high-risk review Sol, medium effort
Critical implementation or repeated failure Sol, high effort
Deterministic verification, integration, delivery no model call

Single-agent execution is preferred because coordination is not free. Parallel mode is valid only for two or three independent implementers with non-overlapping ownership. A separate Explorer agent is not created: the bounded Luna scout performs localization and routing once. A reviewer is added when risk is high or critical, scout confidence is below the configured threshold, or a three-way parallel plan needs an additional integration check.

When the configured agent ceiling cannot hold both a parallel fan-out and a required reviewer, the implementer scopes are combined so the Sol review slot is preserved. When the projected token or dollar budget cannot hold a parallel plan, it is similarly collapsed to one implementer. If the resulting single implementation plus required review still does not fit, execution stops instead of silently reducing quality.

Token and cost controls

  • ORCH_MAX_AGENTS_PER_RUN accepts 2–4 and is a hard ceiling, not a target. A normal run still uses only one implementer.
  • ORCH_MAX_TOKENS_PER_RUN is checked as used + projected call tokens, not only after the limit has already been reached.
  • The complete Agent plan is admitted before fan-out using projected tokens and cost.
  • Tier-specific projected token defaults are configurable with ORCH_PROJECTED_CALL_TOKENS_CHEAP, DEFAULT, and CRITICAL.
  • Each live call also reserves a tier-specific projected dollar cost before invocation.
  • Actual cost is computed from uncached input, cached-read input, prompt-cache-write input, and output tokens.
  • Prompt-cache writes use the configurable ORCH_CODEX_CACHE_WRITE_MULTIPLIER, defaulting to 1.25× uncached input price.
  • A task completion transaction is rejected when accumulated adaptive-agent cost would exceed the run's max_cost_usd.
  • Dependency handoffs are schema-constrained JSON and clipped before reuse.
  • Full diffs remain artifacts; downstream agents receive only compact summaries, changed-file manifests, commit references, material risks, and focused checks.
  • Fix prompts include only the latest bounded verification tail.
  • Codex structured outputs are used for Scout plans and Agent handoffs.

Pricing and projection defaults in .env.example are configurable operating estimates, not permanent provider constants. Update them when model pricing or observed token use changes. The database records task and agent input/output usage plus estimated billed cost used by the budget gate.

Safety defaults

  • ORCH_CODEX_MODE=fake remains the default and performs no model calls.
  • ORCH_GITHUB_PUBLISH_MODE=fake remains the default and performs no remote side effects.
  • Every implementer uses an independent worktree and branch.
  • Implementers may change only declared non-overlapping owned_paths.
  • Reviewers are read-only.
  • Ownership violations and integration conflicts fail instead of being auto-resolved.
  • Integration stages implementer commits with cherry-pick --no-commit.
  • Registered verification commands run after integration and again before delivery.
  • Publication still requires a separate approval and creates only a Draft PR.
  • The orchestrator never force-pushes, marks a PR ready, merges, deploys, or trades.

Adaptive plan contract

The Luna scout returns one structured plan with:

  • mode: single or parallel
  • confidence: 0–1
  • a short rationale
  • one to three independent implementers with precise path ownership
  • an optional reviewer declaration

The deterministic policy then adds or removes the reviewer based on risk and confidence, preserves a required reviewer by collapsing implementers when necessary, and performs full-plan budget admission. Plans are rejected for cycles, unknown dependencies, sequential implementers, overlapping ownership, unsafe paths, or more than four total agents.

Durable execution

Each agent_assignments row records role, dependencies, ownership, worktree, Codex thread, changed files, commit SHA, token usage, and estimated cost. Ready tasks are claimed through PostgreSQL FOR UPDATE SKIP LOCKED. Each implementer produces one cumulative local commit; retries amend that commit rather than creating an ambiguous chain. The integration branch contains staged combined changes, and the existing DELIVERY stage creates the one final verified run commit.

Worktree layout

runtime/worktrees/
├─ <run-id>/                         final integration and delivery worktree
└─ agents/<run-id>/<assignment-key>/ independent agent worktrees

Agent branches use orchestrator/run-<run-id>/agent-<assignment-key>. The final run branch remains orchestrator/run-<run-id>.

Setup and migration

Copy-Item .env.example .env
python -m pip install -e ".[dev]"
docker compose up -d postgres
alembic upgrade head

Phase 7 adds migration 0002_agent_assignments.py. Existing Phase 6 databases must run alembic upgrade head before starting the server or worker.

Register the target repository and optional verification commands:

orchestrator-admin repository add `
  --name toss-trader `
  --path "C:\Users\dbals\Documents\toss-trader" `
  --default-branch main `
  --verification-config verification.json

Run locally

# terminal 1
orchestrator-server

# terminal 2
orchestrator-worker

MCP endpoint: http://127.0.0.1:8000/mcp

Public tools remain list_repositories, create_run, get_run, approve_plan, approve_delivery, approve_publish, finish_run, and cancel_run. get_run includes agent ownership, dependency, thread, commit, token, cost, and status data.

Zero-cost integration check

ORCH_CODEX_MODE=fake
ORCH_GITHUB_PUBLISH_MODE=fake
ORCH_MAX_PARALLEL_WORKERS=3
ORCH_MAX_AGENTS_PER_RUN=4

Fake mode selects the single-agent path and produces no file changes, model calls, pushes, or GitHub API requests. The workflow still exercises durable supervision, agent execution, integration, deterministic verification, delivery approval, and the verified no-op delivery path.

Live execution

Live Codex is opt-in:

ORCH_CODEX_MODE=live
ORCH_CODEX_MODEL_CHEAP=gpt-5.6-luna
ORCH_CODEX_MODEL_DEFAULT=gpt-5.6-terra
ORCH_CODEX_MODEL_CRITICAL=gpt-5.6-sol
ORCH_PROJECTED_CALL_TOKENS_CHEAP=12000
ORCH_PROJECTED_CALL_TOKENS_DEFAULT=60000
ORCH_PROJECTED_CALL_TOKENS_CRITICAL=100000

The model IDs, effort levels, prices, cache-write multiplier, projected call reserves, maximum tokens, and confidence threshold are explicit environment settings. Keep GitHub publication fake unless remote Draft PR creation is intentionally approved.

Validate

python -m pip install -e ".[dev]"
alembic upgrade head
ruff format --check .
ruff check .
pyright
pytest -q

推荐服务器

Baidu Map

Baidu Map

百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。

官方
精选
JavaScript
Playwright MCP Server

Playwright MCP Server

一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。

官方
精选
TypeScript
Magic Component Platform (MCP)

Magic Component Platform (MCP)

一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。

官方
精选
本地
TypeScript
Audiense Insights MCP Server

Audiense Insights MCP Server

通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。

官方
精选
本地
TypeScript
VeyraX

VeyraX

一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。

官方
精选
本地
graphlit-mcp-server

graphlit-mcp-server

模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。

官方
精选
TypeScript
Kagi MCP Server

Kagi MCP Server

一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。

官方
精选
Python
e2b-mcp-server

e2b-mcp-server

使用 MCP 通过 e2b 运行代码。

官方
精选
Neon MCP Server

Neon MCP Server

用于与 Neon 管理 API 和数据库交互的 MCP 服务器

官方
精选
Exa MCP Server

Exa MCP Server

模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。

官方
精选