{"slug": "show-hn-sol-luna-adaptive-codex-orchestration-that-can-choose-zero-workers", "title": "Show HN: Sol-Luna – adaptive Codex orchestration that can choose zero workers", "summary": "Sol-Luna, an MCP server for OpenAI Codex, lets a supervising GPT-5.6 Sol agent delegate bounded implementation tasks to isolated GPT-5.6 Luna worker threads, with scope enforcement and verification. In six measured free-choice runs, Sol declined to delegate every time, and forced delegation was slower on each fixture, supporting the model that strong supervisor first and additional agents only when they provide enough value. The tool is installed via npm and requires Codex authentication.", "body_md": "An MCP server that lets a supervising OpenAI Codex agent delegate bounded implementation tasks to isolated worker threads — one at a time, or several in parallel in their own git worktrees — with a declared file scope per task, scope-violation detection, and results the orchestrator verifies instead of taking on trust.\n\nThe supervisor (`gpt-5.6-sol`\n\n, with high effort recommended) decides *what*\nshould happen, whether delegating is even worth it, and reviews what comes back.\nWorkers (`gpt-5.6-luna`\n\n, at an effort chosen per task) do the contained\nimplementation work in their own Codex threads.\n\n```\ndelegate_tasks({\n  mode: \"parallel\",\n  tasks: [\n    { objective: \"Implement the retry helper...\", effort: \"medium\",\n      allowedFiles: [\"src/retry.mjs\"],  verificationCommands: [\"node --test test/retry.test.mjs\"] },\n    { objective: \"Implement money formatting...\", effort: \"high\",\n      allowedFiles: [\"src/money.mjs\"],  verificationCommands: [\"node --test test/money.test.mjs\"] },\n    { objective: \"Diagnose the ordering bug...\", effort: \"xhigh\",\n      allowedFiles: [\"src/pool.mjs\"],   verificationCommands: [\"node --test test/pool.test.mjs\"] },\n  ],\n})\n→ 3/3 passed · 3 isolated worktrees · no integration conflicts · changes merged\n```\n\nTwo ideas do most of the work here: **a worker's PASS is a claim, not a\nconclusion**, and\n\n**not every task should be delegated**.\n\nSol first decides whether delegation is worthwhile at all. More agents are not automatically better, and the optimal worker count can be zero. Good orchestration is not about maximizing agent count; it includes knowing when one strong Sol should do the work itself.\n\nAcross the six measured free-choice runs in the scale suite, Sol declined to\ndelegate every time, and forced delegation was slower on each corresponding\nfixture. That supports a deliberately scoped mental model for the workloads\nmeasured here: **strong supervisor first; additional agents only when they\nprovide enough value to justify coordination cost.** More agents are a tool, not\nan objective. It does not prove that single-agent systems are universally better\nthan multi-agent systems.\n\nThere is a second adaptive layer when Sol does choose to delegate: each Luna\nworker gets `medium`\n\n, `high`\n\n, `xhigh`\n\n, or `max`\n\nreasoning effort based on that\ntask's difficulty. Worker count and worker effort are separate decisions.\n\nPrerequisite: [OpenAI Codex](https://developers.openai.com/codex) installed and\nauthenticated (`codex login`\n\n).\n\n```\nnpm install -g sol-luna-orchestrator\nsol-luna-orchestrator init\n```\n\nThen open Codex, select **GPT-5.6 Sol at High effort**, and work normally.\n\n```\nYou're the supervisor. src/auth/, src/payments/ and src/search/ each need their\nfailing tests fixed, and they don't touch each other. Use delegate_tasks in\nparallel mode with one worker per module and a disjoint scope each. Pick each\nworker's effort yourself, then review the diffs and run the full suite.\n```\n\n`init`\n\nregisters the MCP server with Codex and applies the two settings Codex\nneeds for delegation to work at all. It changes only the keys it owns — your\ncomments, formatting and other MCP servers are left exactly as they were. Run it\ntwice and it says `Already configured`\n\n.\n\n```\nsol-luna-orchestrator doctor      # diagnose, with the fix for anything broken\nsol-luna-orchestrator status      # short summary\nsol-luna-orchestrator uninstall   # remove this project's entry, nothing else\n```\n\n## Why two commands and not one `npx`\n\nline\n\nA single `npx sol-luna-orchestrator init`\n\nwould be shorter and would work today.\nIt would also write a Codex config pointing into npm's `_npx`\n\ncache, which npm\ndeletes whenever it feels like it — leaving a configuration that silently stops\nworking weeks later with no obvious cause. `init`\n\nrefuses that by default.\n\nIf you want it on one line, chain the two commands your shell's way:\n`npm i -g sol-luna-orchestrator && sol-luna-orchestrator init`\n\nin bash, zsh or\nPowerShell 7; use `;`\n\ninstead of `&&`\n\nin Windows PowerShell 5.\n\nHonest answer, from this project's own measurements:\n\n**Use Sol directly when** the task is small, touches one or few files, has no\nuseful decomposition, or when explaining it would take longer than doing it. On\nsmall tasks delegation measured ~2.3x slower and ~3.5x the tokens, with no\nquality difference.\n\n**Orchestration is worth considering when** a task has two or more genuinely\nindependent workstreams, when you want a declared file scope per unit of work\nwith violations reported rather than discovered later,\nwhen you want verification re-run independently of the agent claiming it passed,\nor when one long session would lose coherence.\n\n**What the benchmarks have and have not shown.** Parallel delegation beat\nsequential delegation in every task and every repetition (median 155s vs 248s).\nOrchestrated execution has **not** beaten Sol High working alone on any fixture\nin any suite. A dedicated crossover investigation at four and six independent\nworkstreams did not find a break-even point either — and going from four streams\nto six moved orchestration further behind (+46% → +108%), because solo cost grows\nsublinearly in stream count while parallel cost is set by the slowest single\nworker. No token saving and no cost saving has been demonstrated; orchestration\nshowed no token crossover. Forced-parallel used about 5.1× the known tokens on\nTier B and 4.8× on Tier C versus solo-high; adaptive and coupled ratios differed.\nDetails in [ bench/RESULTS.md](/mahadansar/sol-luna-orchestrator/blob/main/bench/RESULTS.md).\n\nNot because delegation is always cheaper. On small tasks it measurably is not —\nthis project's own benchmark says so, and that result is\n[documented rather than buried](#benchmarks). Delegation earns its keep when work\nstops fitting in one head: when a session is long enough to lose coherence, when\nchanges need a declared scope with post-execution scope-violation detection, when\n\"it passed\" needs to mean more than the model saying so, or when several\nindependent pieces of work can genuinely run at the same time.\n\nThe split is the one most teams already use with people:\n\n**The supervisor** holds requirements, architecture, decomposition, cross-cutting decisions, and review. It has the context; it makes the calls.**Workers** do bounded implementation, test writing, mechanical refactors, and focused investigation. They need a clear brief, not the whole picture.\n\nThe second idea is that **reasoning effort should be allocated, not fixed**.\nRunning every worker at maximum effort wastes time and tokens on work that was\nmechanical to begin with. The supervisor picks effort per task from *that task's*\ndifficulty — and a batch of three workers routinely runs at three different\nefforts.\n\n- Developers using OpenAI Codex who want more structure than one long session.\n- Engineers in medium or large repositories where \"change these three files\" is a genuinely separable unit of work.\n- People experimenting with multi-agent coding who want the delegation boundary to be explicit, declared, and checkable rather than emergent.\n- Anyone who wants reasoning effort allocated per task rather than fixed for a\nwhole session — mechanical work at\n`medium`\n\nwhile the hard task gets`xhigh`\n\n.\n\nNot, on current evidence, anyone looking to spend fewer tokens: orchestration used more of them in every configuration measured so far.\n\nThere are three execution modes, and choosing between them is the supervisor's job. The tool descriptions push it to justify the choice rather than reach for delegation reflexively.\n\n| Mode | When | Isolation | Can save wall-clock? |\n|---|---|---|---|\nSol only |\nSmall, mechanical, one-file, or already-known edits | — | n/a — usually the fastest option |\nSol + sequential Luna |\nSubstantial work; later tasks depend on earlier ones | Shared workspace, one worker at a time | No |\nSol + parallel Luna |\nTwo or more genuinely independent pieces of work | One git worktree per worker | Yes |\n\nSequential mode deliberately shares the workspace: a later task is *supposed* to\nsee the earlier one's changes. Parallel mode deliberately does not.\n\n``` php\nflowchart TD\n    User([You]) --> Sol\n\n    subgraph Session[\"Codex session\"]\n        Sol[\"<b>Supervisor</b> · gpt-5.6-sol<br/>medium · <b>high</b> · xhigh · max<br/>decompose · decide · review · integrate\"]\n    end\n\n    Sol -->|\"worth delegating?\"| Decide{\"independent<br/>subtasks?\"}\n    Decide -->|\"no, and small\"| Selfdo[\"Sol implements it directly\"]\n    Decide -->|\"dependent\"| Seq[\"delegate_tasks · sequential\"]\n    Decide -->|\"independent\"| MCP[\"delegate_tasks · parallel\"]\n\n    subgraph Orch[\"sol-luna-orchestrator (MCP, stdio)\"]\n        MCP --> Guard[\"Reject overlapping scopes<br/>check git base is clean\"]\n        Guard --> WT[\"Create one worktree per task\"]\n    end\n\n    WT --> W1\n    WT --> W2\n    WT --> W3\n\n    subgraph Workers[\"Isolated Codex threads · no delegation tools\"]\n        W1[\"<b>Luna A</b> @ medium<br/>.sol-luna/worktrees/t1\"]\n        W2[\"<b>Luna B</b> @ high<br/>.sol-luna/worktrees/t2\"]\n        W3[\"<b>Luna C</b> @ xhigh<br/>.sol-luna/worktrees/t3\"]\n    end\n\n    W1 --> Check\n    W2 --> Check\n    W3 --> Check\n\n    subgraph Verify[\"Checked, not trusted\"]\n        Check[\"Re-run verificationCommands<br/>compare claims vs observed edits<br/>detect integration conflicts\"]\n    end\n\n    Check -->|\"clean\"| Merge[\"Integrate into workspace\"]\n    Check -->|\"collision\"| Keep[\"Integrate nothing<br/>keep worktrees for review\"]\n\n    Merge --> Sol\n    Keep --> Sol\n    Seq --> Check\n    Sol -->|\"reads diffs · runs full suite · accepts\"| User\n\n    style Sol fill:#1f2937,stroke:#4b5563,color:#f9fafb\n    style W1 fill:#312e81,stroke:#4f46e5,color:#eef2ff\n    style W2 fill:#312e81,stroke:#4f46e5,color:#eef2ff\n    style W3 fill:#312e81,stroke:#4f46e5,color:#eef2ff\n    style Check fill:#7f1d1d,stroke:#dc2626,color:#fee2e2\n    style Guard fill:#7f1d1d,stroke:#dc2626,color:#fee2e2\n    style Keep fill:#78350f,stroke:#d97706,color:#fef3c7\n```\n\nThe red boxes are what separates this from a plain \"spawn subagents\" tool: a batch is refused before it starts if the scopes collide, and worker output is treated as evidence to be checked rather than as a result.\n\n**Node.js ≥ 22.12**— tested in CI on 24 (active LTS) and 26 (current). Node 20 and earlier are end-of-life and are neither tested nor supported.**OpenAI Codex CLI**, logged in (`codex login`\n\n). Built against`codex-cli 0.147.0`\n\n.**git ≥ 2.20**— only for parallel batches, which use`git worktree`\n\n.- Access to\n`gpt-5.6-sol`\n\nand`gpt-5.6-luna`\n\n. Check with`codex exec -m gpt-5.6-luna \"say ok\"`\n\n.\n\n`sol-luna-orchestrator doctor`\n\nverifies all of this and tells you what to do\nabout anything missing.\n\n`init`\n\nis the supported path. These notes are for people who want to know what it\ndoes, or who prefer to do it themselves.\n\n```\ngit clone https://github.com/mahadansar/sol-luna-orchestrator.git\ncd sol-luna-orchestrator\nnpm install && npm run build\nnode dist/cli.js init\n```\n\nOne table in `~/.codex/config.toml`\n\n(or `$CODEX_HOME/config.toml`\n\n):\n\n```\n[mcp_servers.sol-luna-orchestrator]\ncommand = \"/path/to/node\"\nargs = [\"/path/to/sol-luna-orchestrator/dist/server.js\"]\ntool_timeout_sec = 3600                   # default is 60s; delegations take minutes\ndefault_tools_approval_mode = \"approve\"   # \"auto\" does NOT work here\nstartup_timeout_sec = 30\n\n[mcp_servers.sol-luna-orchestrator.env]\nSOL_LUNA_LOG = \"/path/to/sol-luna-orchestrator.log\"\n```\n\nBoth of the first two settings are required and were found the hard way: Codex's\n60s default tool timeout aborts every delegation mid-flight, and\n`default_tools_approval_mode`\n\nmust be `\"approve\"`\n\n— `\"auto\"`\n\n, despite the name,\nmakes non-interactive runs cancel the call.\n\nA fully annotated example is in [ examples/codex-config.toml](/mahadansar/sol-luna-orchestrator/blob/main/examples/codex-config.toml).\n\n`init`\n\ndoes not use `codex mcp add`\n\n. That command round-trips the whole config:\nmeasured against codex-cli 0.147.0, adding a server deleted the comment above an\nunrelated `context7`\n\ntable and rewrote that server's `startup_timeout_sec = 15`\n\nas `15.0`\n\n. `init`\n\nedits only the keys it owns, so comments, formatting, key order\nand other servers survive byte for byte. Every write is atomic and leaves a\n`config.toml.sol-luna-backup`\n\n.\n\n`npx sol-luna-orchestrator init`\n\nworks, but `init`\n\nwill refuse to register a\npackage running from an npx cache: npm can evict that directory, leaving a Codex\nconfig that points at nothing. Install it properly, or pass `--allow-ephemeral`\n\nif you understand the trade.\n\nOne bounded task, run directly in the workspace. No git requirement.\n\nSeveral tasks, `mode: \"parallel\"`\n\nor `mode: \"sequential\"`\n\n. Each task carries its\nown contract and its own effort. Parallel mode:\n\n- refuses up front if two tasks declare overlapping\n`allowedFiles`\n\n- refuses if the repo has uncommitted changes inside a declared scope\n- gives every worker its own detached worktree branched from\n`HEAD`\n\n- integrates results only when no two workers changed the same file\n- keeps the worktrees when they collide, so you can merge them yourself\n\nBoth tools share the same task contract: `objective`\n\n, `effort`\n\n, `effortReason`\n\n,\n`taskCategory`\n\n, `allowedFiles`\n\n, `forbiddenFiles`\n\n, `acceptanceCriteria`\n\n,\n`verificationCommands`\n\n, `previousAttempts`\n\n.\n\nEverything is environment variables set by *you* — never by the model. That\nseparation is the core of the security model.\n\n| Setting | Value | Why |\n|---|---|---|\n`tool_timeout_sec` |\n`3600` |\nCodex's 60s default aborts every real delegation |\n`default_tools_approval_mode` |\n`\"approve\"` |\nPermits the tool without prompting. `\"auto\"` causes `user cancelled MCP tool call` |\n\n| Variable | Default | Purpose |\n|---|---|---|\n`LUNA_MODEL` |\n`gpt-5.6-luna` |\nWorker model |\n`LUNA_TIMEOUT_SECONDS` |\n`1800` |\nWall-clock budget per delegated task |\n`LUNA_SANDBOX` |\n`workspace-write` |\nCodex sandbox mode for workers |\n`LUNA_NETWORK_ACCESS` |\noff | `1` allows workers network access |\n`SOL_LUNA_MAX_PARALLEL` |\n`3` |\nConcurrent workers; hard ceiling 8 |\n`SOL_LUNA_WORKTREE_LINK` |\n`node_modules` |\nDirectories linked into each worktree |\n`SOL_LUNA_KEEP_WORKTREES` |\n`onFailure` |\n`always` , `never` , or `onFailure` |\n`SOL_LUNA_ALLOW_DIRTY` |\noff | `1` permits parallel batches over uncommitted in-scope changes |\n`SOL_LUNA_VERIFY_MODE` |\n`allowlist` |\n`allowlist` , `off` , or `shell` — see\n|\n`SOL_LUNA_VERIFY_ALLOW` |\n— | Extra permitted executables, comma separated |\n`SOL_LUNA_VERIFY_ENV_PASSTHROUGH` |\noff | `1` stops withholding credential-shaped env vars |\n`SOL_LUNA_ALLOWED_ROOTS` |\n— | Confine delegation to these directory trees |\n`SOL_LUNA_SERVER_NAME` |\n`sol-luna-orchestrator` |\nMust match the name registered in Codex |\n`SOL_LUNA_LOG` |\n— | Tee diagnostics to a file (best troubleshooting signal) |\n`SOL_LUNA_EVENTS` |\n— | JSONL telemetry: batches, workers, worktrees, conflicts |\n\nSet `SOL_LUNA_EVENTS=/path/to/events.jsonl`\n\nand every run appends structured\nrecords: batch start and finish, each worker's start, completion, effort and\nmodel, worktree creation and removal, verification outcomes, scope and\nintegration conflicts.\n\nPer worker, the following are recorded exactly as the Codex SDK reports them on\n`turn.completed`\n\n:\n\n| Field | Meaning |\n|---|---|\n`inputTokens` |\nPrompt tokens for that worker's turn |\n`cachedInputTokens` |\nPortion of the input served from cache |\n`outputTokens` |\nTokens the worker generated |\n`reasoningOutputTokens` |\nReasoning portion of the output |\n`model` , `effort` |\nWhich model and effort that worker ran at |\n`durationSeconds` |\nWall-clock for that worker |\n\nThe supervisor's own usage is not visible to this server — Codex does not report\nthe parent turn to an MCP server it launched. The benchmark harness records it\nseparately because it drives the supervisor itself. Anything unavailable is\nwritten as `null`\n\nrather than zero, so absent data is never mistaken for free.\n\n**Token counts are measured.** They come from the API, per turn, per worker.**No currency figure is produced, by design.** Prices are not exposed through this integration.**Your Codex subscription is not a function of token counts.** Multiplying tokens by a public price list would produce an API-equivalent number that has no relationship to what you are actually billed.- If you want an estimate, export the JSONL and apply your own pricing — the raw per-worker numbers are all there.\n- Nothing in this project claims a cost saving, because none has been measured.\n\nThe supervisor model is `gpt-5.6-sol`\n\n. Its effort is yours to set, not the\nmodel's to change mid-session.\n\n| Effort | Use for |\n|---|---|\n`medium` |\nSimple but non-trivial work whose decomposition is already obvious |\n`high` |\nRecommended. Architecture, decomposition, delegation, review, normal multi-file engineering |\n`xhigh` |\nDifficult architecture, subtle production bugs, cross-service reasoning, tricky concurrency, hard decomposition |\n`max` |\nExceptional supervisor-level problems only — not a routine setting |\n\nThe orchestrator does not set the parent Sol effort; select it in the Codex\nsession. `ultra`\n\nis a separate Codex multi-agent execution mode, not another\nreasoning-effort value.\n\nChosen per task by the supervisor, defaulting to `high`\n\n. In a parallel batch each\nworker can differ — and in practice they do.\n\n| Task shape | Effort |\n|---|---|\n| Rename, move, boilerplate, applying an existing pattern | `medium` |\n| Obvious test cases for already-defined behaviour | `medium` |\n| A new endpoint or feature with real business logic | `high` (default) |\n| A bug fix with a reliable repro | `high` |\n| A focused refactor inside one module | `high` |\n| Concurrency, ordering, transactions, tricky state | `xhigh` |\n| A bug whose cause is not yet identified | `xhigh` |\n| Intricate algorithmic work with real correctness risk | `max` |\nAnything that already failed at `xhigh` |\n`max` |\n\nTwo rules carry most of the weight:\n\n**Importance is not difficulty.** A critical but mechanical task is`medium`\n\n.**Escalate rather than start high.** Run at`high`\n\n; if it fails*because the task was hard*, re-delegate at`xhigh`\n\nwith`previousAttempts`\n\n. If it failed because the brief was vague, fix the brief. A scope violation or a timeout is never an effort problem.\n\nAcross the committed runs in all three benchmark suites, no worker was assigned\n`max`\n\n. That is a statement about the fixtures — bounded and well-specified — not\nevidence that `max`\n\nis useless. It is the setting the policy reserves, and no\nmeasured task was hard enough to reach for it.\n\nFull rules are in [ SOL_RULES.md](/mahadansar/sol-luna-orchestrator/blob/main/SOL_RULES.md). They also reach the supervisor\nautomatically through the MCP tool descriptions, so no setup is needed.\n\nThis is the most important section in this README, and it is backed by measurement rather than opinion.\n\nOn four small single-file tasks, 16 runs, delegating was **worse on every axis**:\n\n| Arm | Passed | Median wall-clock | Median output tokens | Median input tokens |\n|---|---|---|---|---|\n| Sol high, solo | 8/8 |\n41s |\n921 |\n67,805 |\n| Sol high + Luna | 8/8 |\n96s | 3,275 | 229,854 |\n\n~2.3x slower, ~3.5x the tokens, no measurable quality difference. If your task is\nsmall, well-specified and solvable in one pass, **do it yourself**. The tool\ndescriptions tell the supervisor exactly this.\n\nThe parallel suite runs two projects that each contain three independent modules. 24 runs across six arms, all passing. Three findings, all measured:\n\n**Parallel delegation beats sequential delegation, every time.** With delegation\nmandated so both arms genuinely delegate three workers:\n\n| Task | Sequential | Parallel | Solo (high) |\n|---|---|---|---|\n| parallel-toolkit | 225s | 164s |\n62s |\n| parallel-httpkit | 402s | 144s |\n73s |\nmedian, all runs |\n248s |\n155s |\n63s |\n\nParallel won in every task and every repetition, and was far more consistent (122–183s vs 193–565s). Sequential pays the sum of three worker times, so one slow worker drags the whole run.\n\n**But neither beat the supervisor doing it directly** on fixtures this size. Each\nmodule is 15–30 lines against a fixed test file — too small to amortise a contract\nper task, a thread per worker, a verification pass per worker and an integration\nstep.\n\n**And the supervisor mostly declined.** When left to decide, it used zero workers\nin 5 of 8 runs, implementing the modules itself instead. Those decisions avoided\nthe forced-delegation overhead measured on the same fixtures; stochastic runs do\nnot prove why Sol made each choice.\n\nSo the honest rule is qualitative, not numeric: **when you delegate independent\nwork, use parallel — but \"should I delegate at all?\" is a separate question, and\nfor small work the answer is usually no.** Full data, including a `solo-xhigh`\n\narm that varied 4x between two repetitions, is in\n[ bench/RESULTS.md](/mahadansar/sol-luna-orchestrator/blob/main/bench/RESULTS.md).\n\nA third suite tested whether larger measured workloads reached a point where orchestration became competitive with Sol working alone. It did not observe one; whether a crossover exists beyond the tested regime remains unknown.\n\n| Fixture | Independent streams | Sol High solo | Free choice | Mandated parallel |\n|---|---|---|---|---|\n| scale-svckit | 4 | 171.5s | 120s |\n250s (+46%) |\n| scale-datakit | 6 | 189.5s | 186.5s | 394.5s (+108%) |\n| scale-coupled | 1 (no natural seam) | 113.5s | 87.5s |\n347s (+206%) |\n\n19 runs, all passing. Three findings worth more than the table:\n\n**More streams did not improve relative performance in V6.** From four to six\nindependent modules, solo time moved from 171.5s to 189.5s while forced-parallel\ntime moved from 250s to 394.5s. In the observed parallel runs, elapsed time\ntracked the slowest worker plus roughly 70s of coordination and review.\n\n**The measured fixed cost was supervisor coordination and review, not the\nmachinery.** Worktree creation and integration together took ~1.2s. The\nsupervisor's contract-writing and review portions took ~70s.\n\n**The slow-worker tail is a strong candidate for the dominant remaining\nparallel-latency constraint.** In one six-stream run, four workers finished\nwithin 95s while the slowest took 333s; the other run also had a long tail. As a\ncounterfactual, replacing each run's worker times with that run's median produces\nabout 176s against solo's 189.5s. That is arithmetic on measured times, not an\nobserved crossover, and two Tier C repetitions are not enough to characterize\nthe tail distribution.\n\n**And left to decide for itself, Sol never delegated** — 0 of 6 free-choice runs,\nat one, four and six streams alike — while passing every time and being the\nfastest arm on two of the three fixtures.\n\nAcross the scale suite's parallel-mode batches that actually launched workers —\n6 batches, 25 workers — there were **zero integration conflicts**: the supervisor\nproduced disjoint scopes every time and every batch merged cleanly. No scale-suite\nworker was assigned `max`\n\n, which says these fixtures did not warrant it rather\nthan that `max`\n\nhas no use.\n\nThree suites, all reproducible, all graded by the harness after the agent stops — never by the agent:\n\n```\nnpm run bench:validate                    # proves fixtures discriminate; no model calls\nnpm run bench -- --suite micro            # small tasks: delegation overhead\nnpm run bench -- --suite parallel         # multi-module projects: 4 arms\nnpm run bench -- --suite scale            # 4- and 6-stream projects + a coupled control\nnpm run bench:report                      # summarise the newest raw results\nnpm run bench:analyze                     # crossover verdict across every results file\n```\n\n`bench:validate`\n\nand `bench:analyze`\n\nspend nothing. The three `bench`\n\ncommands\nmake live model calls.\n\nA task passes only if its checks exit 0, files marked immutable are\nbyte-identical (SHA-256), and — where a fixture defines one — the authored test\nsuite actually fails against a deliberately broken implementation.\n`bench:validate`\n\nproves every fixture fails in its starting state and passes with\na committed reference solution, so a green score cannot come from a broken grader.\n\nFull methodology, per-task numbers and what could not be measured are in\n[ bench/RESULTS.md](/mahadansar/sol-luna-orchestrator/blob/main/bench/RESULTS.md). Raw records are committed alongside it.\n\nRead [ SECURITY.md](/mahadansar/sol-luna-orchestrator/blob/main/SECURITY.md) before pointing this at anything you care\nabout. The short version:\n\n**Enforced**\n\n- Verification commands are parsed into argv with\n**no shell**.`;`\n\n,`&&`\n\n,`|`\n\n, backticks and`$(…)`\n\nare rejected, not executed. Only allowlisted executables may launch, and never via a path. - Credential-shaped environment variables are withheld from verification commands, whose output flows back into a model transcript.\n- Workspace escapes are caught after resolving symlinks.\n`allowedFiles: [\"**\"]`\n\nstill cannot authorize writing outside the workspace. - Workers cannot delegate — enforced by config\n*and*by an environment marker that makes a worker-side server register zero tools. - Parallel batches are refused when scopes overlap, and worker changes are never merged when two workers touched the same file.\n\n**Not enforced — know this**\n\n**Scope is checked after the fact, not prevented.** Workers really write files.**Verification runs outside the Codex sandbox**, with your user's permissions.`npm test`\n\nruns your project's test code, which can do anything you can.**Parallel batches write inside your repository**, under`.sol-luna/worktrees/`\n\n, and add that path to`.git/info/exclude`\n\n. Integration copies files into your working tree.`SOL_LUNA_VERIFY_MODE=shell`\n\ndisables all command protections. Opt-in, logged loudly.- This is a set of guardrails,\n**not a sandbox**.\n\nStatuses reflect what has actually been executed, not what the code intends.\n\nTwo different things get called \"supported\", so they are reported separately.\n**Deterministic CI** runs the build, typecheck, format check, unit, security,\nparallel-orchestration and CLI suites, the MCP protocol handshake and the\nbenchmark fixture validation — no model access. **Live model testing** drives\nreal Codex sessions with real Sol and Luna turns.\n\n| Platform | Deterministic CI | Live Codex delegation | Notes |\n|---|---|---|---|\nWindows 11 |\nVerified | Verified |\nSingle + parallel delegation, worktree lifecycle, CLI lifecycle, benchmarks |\nLinux |\nVerified | Not yet run | `ubuntu-latest` , GitHub-hosted |\nmacOS |\nVerified | Not yet run | `macos-latest` , GitHub-hosted |\n\nPlatform-specific behaviour is exercised by real code paths rather than mocked:\nworktree tests create actual git worktrees and directory links, and the CLI tests\nspawn the real binary, so each runner tests its own filesystem and process\nsemantics (path separators, case sensitivity, symlink support, file locking).\nWindows uses junctions and `taskkill /T`\n\nfor process-tree cleanup; POSIX uses\ndirectory symlinks and process-group kills.\n\nWhat that means in practice: the code paths that differ per platform are proven on all three, but only Windows has been driven end to end with a live model. Treat Linux and macOS as expected-to-work with the mechanics verified, rather than as proven end to end.\n\n`SOL_LUNA_LOG`\n\nis ground truth for the first three. Model self-reports are not: a\nlow-effort model will cheerfully claim it has a tool it does not have.\n\n| Symptom | Cause |\n|---|---|\n| Log file never created | Codex never started the server — config or path problem. Check `codex mcp get` . |\nLog has `client connected` but no `delegate_task` line |\nThe server is fine; the model chose not to call it. Prompt more directly. |\n`user cancelled MCP tool call` |\n`default_tools_approval_mode` missing or `\"auto\"` . It must be `\"approve\"` . |\n| Delegations die at ~60 seconds | `tool_timeout_sec` is missing. |\n`not inside a git repository` on a parallel batch |\nParallel mode needs git worktrees. Use `mode: \"sequential\"` , or `git init` + one commit. |\n`uncommitted changes inside the file scopes` |\nWorkers branch from `HEAD` and would not see that work. Commit, stash, narrow the scopes, or set `SOL_LUNA_ALLOW_DIRTY=1` . |\n`overlapping file scopes` |\nWorking as intended. Give disjoint scopes or use sequential mode. |\n| Verification fails with \"module not found\" in a batch | The worktree link for `node_modules` failed. Check the task warnings; see `SOL_LUNA_WORKTREE_LINK` . |\nWorktrees left in `.sol-luna/worktrees/` |\nExpected after a failure or a conflict (`SOL_LUNA_KEEP_WORKTREES` ). Safe to delete; a later batch prunes stale ones. |\n`Command refused by verification policy` |\nWorking as intended. One command per entry, no `&&` ; or permit the executable via `SOL_LUNA_VERIFY_ALLOW` . |\n| A worker appears able to delegate | Don't trust the model's answer. Run `npm run smoke:isolation` . |\n\n**Delegation is not free**, and for small tasks it is measurably worse. See[When NOT to delegate](#when-not-to-delegate).** Parallel mode requires git**with at least one commit and a clean in-scope working tree.** Integration is a file copy, not a merge.**It is only attempted when worker file sets are disjoint; anything else is handed back to you.** Workers are verified in isolation.**Passing separately is not passing together — the supervisor is told to run the full suite after integration.** Verification is not sandboxed.**See Security.** File-scope validation is detective, not preventive.**Scope violations are detected after worker execution; declared scope does not prevent writes.** Built against experimental surfaces.**Several behaviours this depends on are undocumented and were established by testing (see`CHANGELOG.md`\n\n). Upstream changes may break it.**Linux and macOS are CI-verified only**— no live model runs there yet.** Benchmarks are small.**Directional, not statistically significant.\n\nNot built yet — listed as intent, not as features:\n\n**Live orchestration activity and worker visibility.** Plan`sol-luna-orchestrator activity`\n\n,`activity --watch`\n\n, and`activity --json`\n\nto show the Sol supervisor, active batch and mode, Luna workers, task, model, effort, state, elapsed time, current and peak concurrency, and useful verification or worktree status. Supervisor state would report only what the MCP/orchestrator actually knows; it cannot observe Sol activity after an MCP call returns. A focused`workers`\n\ncommand or alias may also be considered.**Characterize and bound slow-worker tails.** V6 found no observed latency crossover, but the six-worker runs showed substantial straggler effects. A clearly labelled counterfactual suggests that reducing worker-tail latency could materially improve parallel performance. First gather targeted additional Tier C forced-parallel repetitions to characterize the tail more reliably. If confirmed, investigate bounded execution, re-delegation, or related mitigation. Two Tier C repetitions do not establish the tail distribution.**Optional worker continuation**— letting the supervisor resume an existing Luna thread for bounded follow-up or revision work instead of always starting a fresh worker. Supervision, file scope and the no-recursive-delegation guarantee would have to hold for the resumed turn exactly as they do for the first.**Fixtures larger than one supervisor context.** Every suite so far fits comfortably in a single Sol session, which structurally favours solo. Finding out whether that changes needs workloads big enough to strain one session — which is also where deterministic grading becomes hard, so it is a real research problem rather than a bigger fixture file.**Sandboxed verification**— investigating whether verification commands can run inside the Codex sandbox rather than in the orchestrator's own process. Today they run beside it, with your user's permissions; see[Security](#security). Whether this is achievable depends on upstream Codex capabilities and is not committed to.- Automatic retry with reasoned effort escalation, driven by\n`previousAttempts`\n\n- Live end-to-end verification on Linux and macOS\n\nMIT — see [LICENSE](/mahadansar/sol-luna-orchestrator/blob/main/LICENSE).", "url": "https://wpnews.pro/news/show-hn-sol-luna-adaptive-codex-orchestration-that-can-choose-zero-workers", "canonical_source": "https://github.com/mahadansar/sol-luna-orchestrator", "published_at": "2026-08-16 09:57:30+00:00", "updated_at": "2026-08-16 10:10:34.716833+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["OpenAI Codex", "Sol-Luna", "GPT-5.6 Sol", "GPT-5.6 Luna", "npm"], "alternates": {"html": "https://wpnews.pro/news/show-hn-sol-luna-adaptive-codex-orchestration-that-can-choose-zero-workers", "markdown": "https://wpnews.pro/news/show-hn-sol-luna-adaptive-codex-orchestration-that-can-choose-zero-workers.md", "text": "https://wpnews.pro/news/show-hn-sol-luna-adaptive-codex-orchestration-that-can-choose-zero-workers.txt", "jsonld": "https://wpnews.pro/news/show-hn-sol-luna-adaptive-codex-orchestration-that-can-choose-zero-workers.jsonld"}}