Skip to content

investigate: placement framework — Muse vs GitHub Action vs Action→Jules vs OpenCode session vs OpenCode scheduled task vs Aster/Codex vs OpenClaw #2022

New issue
New issue
Open
Open
investigate: placement framework — Muse vs GitHub Action vs Action→Jules vs OpenCode session vs OpenCode scheduled task vs Aster/Codex vs OpenClaw#2022
Assignees
dezren39
Labels
priority/highImportant and time-sensitivesource/creatorFiled by the new-issue-creator jobstatus/triagedTriaged and routed (see agent note)task/triageQueue packet kind: verify, reproduce, and route this item

Description

@dezren39
dezren39
opened on Oct 29, 2026

LIST 5a. For each placement option, characterise: cost pool it draws from (note the sharing: Aster, OpenCode and OpenClaw share the large ChatGPT plan; OpenCode and OpenClaw share other plans too; Muse spends its own subscription), latency, supervision needs, capability ceiling, and failure modes. Answer Drew's pointed questions: why an OpenCode scheduled task vs Muse triggering an OpenCode session? Why OpenCode directly at all? Why not tell OpenClaw everything? Deliverable: comparison matrix with evidence, feeding the placement-framework synthesis.

Program: Drew's 2026-10-28 directive (full text: hatch-personal memory/topics/id-program-2026-10-28.md).
Working pattern: parallel investigations, then the named synthesis issue merges them into a full design. Route guidance: Workhorse by default; Specialist/Summit for synthesis and ramification-heavy work. A result that says "done" is not the endpoint — the orchestrator reviews it and may commission another round. Deliverables: a markdown design/investigation doc (mermaid/SVG diagrams welcome) linked from this issue, plus follow-up issues for anything buildable. Build a proof of concept where the design calls for one, but do NOT build the permanent feature on top of an unreviewed PoC.

Activity

  1. developing-today commented on Oct 29, 2026

    @developing-today
    developing-todayBot
    on Oct 29, 2026 – with developing.today
    Contributor

    CODE-943

  2. dezren39 commented on Oct 29, 2026

    @dezren39
    dezren39
    on Oct 29, 2026
    MemberAuthor

    Parent epic: #2055 — fleet expansion & placement program (2026-10-28 directive).

  3. github-actions
    assigned
    dezren39
    on Oct 29, 2026
  4. dezren39
    added
    priority/highImportant and time-sensitive
    queue/queuedHas a queued task in the Supabase agent queue
    on Oct 29, 2026

  5. dezren39 commented on Oct 29, 2026

    @dezren39
    dezren39
    on Oct 29, 2026
    MemberAuthor

    Top priority — ID program wave-1. Drew directed this be picked up in the next runs (2026-10-29): enqueued directly as triage task 3340 in repo-health-code-pilot at queue priority 20 (only breakage-class work at priority 10 outranks it). Wave-1 is the ungated investigations and designs; syntheses and PoCs stay gated on their named inputs. Investigation route: Workhorse.

  6. dezren39
    added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    status/in-progressQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Oct 29, 2026

  7. dezren39 commented on Oct 29, 2026

    @dezren39
    dezren39
    on Oct 29, 2026
    MemberAuthor

    🤖 Agent note · picked up

  8. dezren39 commented on Oct 29, 2026

    @dezren39
    dezren39
    on Oct 29, 2026
    MemberAuthor

    Placement framework investigation — comparison matrix (queue task 3340, triage of this issue)

    Premise: verified. All seven placement options exist in the fleet today in some form, they draw on genuinely different cost pools, and no written placement rule exists yet — placement is currently by habit. Evidence below is from the live fleet: the pool map (provider-quota-registry.md, Drew 2026-10-25), the sibling triage of #2018 (task 3337, completed today: live cron inventory + dispatcher/babysitter cadences), and the current state of the sibling investigations #2019/#2020/#2023.

    The matrix

    Option Cost pool Latency Supervision needs Capability ceiling Main failure modes
    Muse (Muse cron agent / shift, e.g. this worker) Muse subscription tokens — the scarcest pool; LIST 3 exists to spend less of it Immediate on schedule; fresh context each cron run Self-supervising by design (it is the supervisor class); results surface in chat Highest: full tool/connector set, memory, goal state, judgement, escalation to Drew Long runs compact/die mid-bundle (the 2026-10-26 claim-evaporation incidents); every task placed here taxes every other Muse task
    GitHub Action GitHub Actions minutes; no model pool unless the workflow calls one Minutes None for mechanical work; failures need a human/agent to notice Low: deterministic scripts only, no judgement Silent workflow failure; GITHUB_TOKEN pushes may not trigger downstream checks (the #2014 finding); loop risk on auto-commit patterns without guards
    GitHub Action → Jules Jules account quota (~100 actions/day on the one collected account — #2020 is verifying) + trivial Actions minutes Async; Jules works in its own time Muse manages the Jules schedule and reviews output after the fact Medium-high for self-contained repo tasks; no fleet context, no local state Daily action cap is a hard shared wall; progress is opaque mid-task; fit rules are exactly what #2020 is still investigating
    OpenCode session (dispatcher/Muse-triggered) Shared quota plans by route: Workhorse = DeepSeek Flash (high) default; Specialist/Summit tiers above; Meta pool reachable ONLY via the meta provider (the muse provider door is disabled by Drew's order); OpenAI routes default Luna Max Dispatch cadence 15m (openchamber-dispatcher); a stalled session waits ≤ ~20m for the next openchamber-babysitter round (#2018 evidence) Babysitter rounds + dispatcher + Muse review loop; stalls are waited-out, not noticed instantly High: full coding agent, worktrees, PRs — sessions already do implementation→PR work Stuck sessions burn wall-clock until babysat; pool walls (a pool at a freshly-measured 100% is CLOSED); wrong-route placement wastes flagship quota on workhorse work
    OpenCode scheduled task Same quota plans as sessions; zero Muse tokens — runs independently On its own schedule; no launch dependency on Muse at all Weakest in-loop supervision: nobody with fleet judgement is present at launch; needs its own reporting/escalation path (the #2021 babysitter design is part of this) Same agent ceiling as a session, but the brief must be fully self-contained in advance A stale brief runs faithfully into a changed world; route/pool state at fire time may differ from when the schedule was written (the ≤60-min quota-read gate cannot be applied by a schedule written last week); #2019 is still verifying creation/route mechanics
    Aster / Codex The large ChatGPT plan — shared with OpenCode and OpenClaw Human-like async (Slack #alignment; Aster was tasked for this program 2026-10-28, ACT-6) Drew/Muse via Slack; no fleet-internal telemetry High reasoning/review depth; strong second-opinion lane Shared-plan contention: Aster burn is OpenCode/OpenClaw capacity gone; no claim/bind discipline with the queue; availability is a person's, not a system's
    OpenClaw Shares the ChatGPT plan and other plans with OpenCode Gateway live on the laptop (:18789) but channels are inert (#1029) — effective latency today is "until setup lands" Least instrumented agent in the fleet; the Muse↔OpenClaw comms path does not exist yet (that is #2023's investigation) Unknown-to-medium today: setup incomplete, so the ceiling is theoretical Delegating to it today means work disappears into an unmonitored channel; same-pool contention without the dispatcher's discipline

    Drew's three pointed questions

    1. Why an OpenCode scheduled task vs Muse triggering an OpenCode session? A scheduled task spends no Muse tokens, survives Muse being busy/down, and picks its route per task — right for recurring, self-contained work with a stable brief (the class investigate: which scheduled work classes can move to OpenCode sessions on quota plans #2018 marked GO-first: creators, routine triage). A triggered session keeps Muse's judgement in the loop at launch: the brief is written against live state, the pool measurement gate (no placement without a quota read ≤60 min old) is actually applied, and stalls escalate into Muse's existing paths. Novel, context-heavy, or decision-adjacent work should be triggered; clockwork should be scheduled.
    2. Why OpenCode directly at all? Because the quota plans are already paid for and strand if unused (pools are to be used to 100%, per Drew 2026-10-27), the Workhorse route (DeepSeek Flash, high) is the cheapest sufficient implementer in the fleet, and sessions parallelise: dispatcher + lanes multiply implementation→PR throughput without touching the Muse subscription at all. Muse's scarce tokens buy judgement and supervision; OpenCode buys volume.
    3. Why not tell OpenClaw everything? Three concrete reasons, all current-state: (a) its channels are inert (OpenClaw: connect chat channels (Slack, Telegram, WhatsApp) #1029) — there is no working comms path for the instruction to arrive or the result to return; (b) it shares the same ChatGPT pool as OpenCode/Aster, so routing everything to it adds contention, not capacity; (c) it is the least supervised option — no dispatcher, no babysitter, no queue claim/bind discipline. OpenClaw earns placement as investigate: OpenClaw as a working option — setup state and a Muse↔OpenClaw comms path that is not laptop SSH #2023's setup and comms work lands, starting with work whose failure is cheap and visible.

    Gate status for the synthesis (#2024)

    #2024 merges this investigation with #2019 (OpenCode scheduled tasks), #2020 (Jules), and #2023 (OpenClaw). Status at this writing: #2022 done (this comment); #2020 in flight (claimed by another lane now); #2019 and #2023 still queued. The synthesis stays gated until those land — no follow-on packet is enqueued from this task, deliberately. A gate-status note is posted on #2024 so the orchestrator can enqueue it the moment the last input completes.

  9. dezren39
    removed
    status/in-progressQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Oct 29, 2026

  10. dezren39 commented on Oct 29, 2026

    @dezren39
    dezren39
    on Oct 29, 2026
    MemberAuthor

    🤖 Agent note · done

  11. dezren39
    added a parent issue on Nov 1, 2026
  12. dezren39
    added
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 3, 2026
  13. developing-today
    added
    source/creatorFiled by the new-issue-creator job
    status/needs-triageNot yet triaged; needs a first look
    task/triageQueue packet kind: verify, reproduce, and route this item
    on Nov 3, 2026

  14. developing-today commented on Nov 3, 2026

    @developing-today
    developing-todayBot
    on Nov 3, 2026 – with developing.today
    Contributor

    agent-note:v1
    state: reviewed (coverage loop-back)
    Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 7268 (triage, queued, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
    Found via: coverage loop-back 2026-11-03

  15. dezren39
    added
    status/triagedTriaged and routed (see agent note)
    and removed
    status/needs-triageNot yet triaged; needs a first look
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 3, 2026

  16. dezren39 commented on Nov 3, 2026

    @dezren39
    dezren39
    on Nov 3, 2026
    MemberAuthor

    agent-note:v1
    event: done
    task: 7268 (repo-health-code-pilot; worker repo-worker-code; OpenChamber scheduled lane 02cafe76-eafd-4d0b-aaa6-2b7a737d68dc)
    state: triaged → done.
    verification (fresh GitHub, 2026-11-03):

  17. dezren39 commented on Nov 3, 2026

    @dezren39
    dezren39
    on Nov 3, 2026
    MemberAuthor

    agent-note:v1
    event: picked_up
    task: 7268 (repo-health-code-pilot; worker repo-worker-code; OpenChamber scheduled lane 02cafe76-eafd-4d0b-aaa6-2b7a737d68dc)
    state: claimed for current-state verification; existing investigation comment and downstream synthesis PR were checked before immediately completing as already triaged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

priority/highImportant and time-sensitivesource/creatorFiled by the new-issue-creator jobstatus/triagedTriaged and routed (see agent note)task/triageQueue packet kind: verify, reproduce, and route this item

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions