diff options
Diffstat (limited to 'project_claudomator_distributed_execution_idea.md')
| -rw-r--r-- | project_claudomator_distributed_execution_idea.md | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/project_claudomator_distributed_execution_idea.md b/project_claudomator_distributed_execution_idea.md new file mode 100644 index 0000000..6b195e5 --- /dev/null +++ b/project_claudomator_distributed_execution_idea.md @@ -0,0 +1,18 @@ +--- +name: claudomator-distributed-execution-idea +description: "Retro — user has other machines with more horsepower for local models; simplest distribution model is reusing NativeRunner per machine, not new RPC" +metadata: + node_type: memory + type: project + originSessionId: 560b9055-7a3f-483e-b1a0-1a4c70419390 +--- + +User asked (2026-07-11) whether claudomator could be made distributed, to farm work out to other machines with more horsepower for local models — "what's the simplest reasonable model." Not yet implemented; captured as a design idea with a recommendation. + +**Recommendation:** reuse `internal/executor.NativeRunner` (the existing `"local"` runner, already an OpenAI-compatible HTTP client currently pointed at `localhost:11434`) rather than building any new distribution/RPC layer. Register one `NativeRunner` per remote machine, each pointing at that machine's own Ollama/vLLM/llama.cpp-server endpoint, under a distinct provider key (e.g. `"local-machineA"`). A role's `EscalationLadder` can then round-robin across them via the existing multi-candidate tier selection (`Pool.selectRung`, which already skips rate-limited runners and round-robins otherwise) — claudomator's own dispatcher becomes the scheduler across those endpoints for free. This needs only config entries plus a few lines registering the new runners in `internal/cli/serve.go` — no new distributed-systems code at all. + +**Why this is the right "simplest" answer:** the load-balancing/rate-limit/escalation machinery this session grounded in repeatedly (`Pool.execute()`'s role-based dispatch, `Scheduler`'s retry-then-escalate) already treats "which provider/model backs this dispatch" as a pluggable, multi-candidate choice — distributing across machines is just adding more candidates to that same list, not a new concept. + +**Open question to verify before relying on this for more than plain `builder` work:** whether `NativeRunner`'s tool-use loop (`internal/agentloop`) has full parity with the MCP-only tools added in later phases -- `report_verdict` (arbitration), `propose_role_config`/`propose_epic` (retro/planner) -- see `internal/agentloop/tools.go` vs. `internal/executor/agentmcp.go`. If it doesn't, distributed local models would be usable for `builder`/evaluator work but not yet for arbitration or retro roles. + +**Secondary consideration, not yet explored:** local models are typically much weaker than Claude for judgment-heavy roles (arbitration, correctness evaluation) -- this likely fits best as a cheap first tier in an escalation ladder (fast/free triage) with real Claude models still backing the tiers that matter most for quality, rather than a wholesale replacement. |