Skip to content

Design: session conductor — merge OpenChamber dispatcher + babysitter into one job (implements #2021 as the merged job) #2132

New issue
New issue
Open
Open
Design: session conductor — merge OpenChamber dispatcher + babysitter into one job (implements #2021 as the merged job)#2132
Assignees
dezren39
Labels
priority/highImportant and time-sensitivesource/creatorFiled by the new-issue-creator jobtask/triageQueue packet kind: verify, reproduce, and route this item

Description

@dezren39
dezren39
opened on Oct 29, 2026

Implement #2021 as a MERGE of openchamber-dispatcher + openchamber-babysitter into one session conductor with two phases (Drew approved 2026-10-29):

  • DISPATCH: take from the queue head, launch the session on the chosen pool (Workhorse default; Specialist/Summit for complex work), bind session↔task, log, move on to the next. Fire-and-forget; never babysit inside the dispatch phase.
  • SWEEP: one pass over ALL live sessions — answer their questions, nudge or kick stalls, and escalate when a session cannot crack its issue: change its routing pool (e.g. Workhorse → Specialist) or move it off an exhausted pool. A session that stops gets restarted or handed back to the queue with a reason, never left silent.

Cadence ~20m. Success metric: combined input per cycle ≤ 60% of the current pair's (dispatcher 149M + babysitter 124M per ~15h window at check-in #5), at equal sessions served. Update the fleet-watchdog roster to the merged job id. Keep the measurement gate binding: no dispatch without a quota picture ≤60 min old covering all pools.

Activity

  1. developing-today commented on Oct 29, 2026

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

    CODE-1030

  2. dezren39
    added
    priority/highImportant and time-sensitive
    on Oct 29, 2026

  3. dezren39 commented on Oct 29, 2026

    @dezren39
    dezren39
    on Oct 29, 2026
    MemberAuthor

    TOP PRIORITY (Drew, 2026-10-29 01:23 CDT): Batch 3 fleet consolidation — pick this up in the next runs, ahead of routine work. Being enqueued to repo-health-code-pilot at top priority now.

  4. dezren39
    added
    queue/queuedHas a queued task in the Supabase agent queue
    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

  5. dezren39 commented on Oct 29, 2026

    @dezren39
    dezren39
    on Oct 29, 2026
    MemberAuthor

    🤖 Agent note · picked up

  6. dezren39 commented on Oct 29, 2026

    @dezren39
    dezren39
    on Oct 29, 2026
    MemberAuthor

    🤖 Agent note · done

    Triage verdict — premise CONFIRMED, design decided, implementation routed

    Premise check (live cron state, 2026-10-29): openchamber-dispatcher (15m, enabled, timeout 2700s) and openchamber-babysitter (20m, enabled, timeout 1800s) both work the same OpenChamber session population from two separate instruction files and two separate runs, delivering to the same chat. Each run independently rebuilds the session inventory and (dispatcher) the quota picture — exactly the duplicated fixed cost the merge removes. Baseline stands as filed: 149M + 124M input per ~15h window at check-in #5 (~273M combined). No premise corrections needed.

    Design decisions (the parts the issue left open)

    1. One job, one picture per cycle. openchamber-conductor, 20m cadence. Each run builds the capacity inventory and quota snapshot once and shares it across both phases — this sharing, plus halving the run count (7 runs/hour → 3), is where the ≤60% target comes from. Timeout 2700s (the dispatcher's, the larger of the pair).
    2. Phase order: SWEEP first, then DISPATCH. Sweeping first means stalls are answered and reroutes decided before new launches compete for the same pools, and capacity freed by hand-backs is available to the same cycle's dispatch. Dispatch stays fire-and-forget; nothing babysits inside the dispatch phase.
    3. Escalation ladder (answers design: scheduled OpenCode preliminary babysitter — sweep sessions, fix easy stalls, escalate the rest #2021's open question — the mechanism is internal, not a new channel): (a) answer/nudge/kick in place, within the babysitter's existing limits → (b) reroute the session's pool (Workhorse → Specialist; Summit only for synthesis-class work) → (c) move the session off an exhausted pool → (d) stop the session and hand its task back to the queue parked with the reason recorded — never silent. A GitHub issue is filed only when the blocker is a genuine decision/access item, per the standing escalation rules; routine stalls never become issues.
    4. Measurement gate stays binding across both phases: one quota picture ≤60 min old covering all pools gates dispatch and reroutes; no fresh picture → the cycle does observation and hand-backs only.
    5. Cutover is reversible: create the conductor, disable (never delete) the pair, update the fleet-watchdog roster to openchamber-conductor in the same pass. Rollback = re-enable the pair and disable the conductor.
    6. Success metric, made checkable: the daily token check-in compares the conductor's input per ~15h window against the 273M baseline for 48h after cutover, at equal sessions served (sessions swept + dispatched per window, from the conductor's log); target ≤60% (≈164M). First comparison is reported on Design: session conductor — merge OpenChamber dispatcher + babysitter into one job (implements #2021 as the merged job) #2132.

    Routing

    Implementation filed as #2153 (conductor job + merged instruction, cutover, watchdog roster, 48h cost comparison) and enqueued as queue task 3173, flagged live-fleet-change. Role note: the conductor is one Do job in the #2131 map, replacing the two Do entries for dispatcher and babysitter.

  7. dezren39
    removed
    status/in-progressQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Oct 29, 2026
  8. github-actions
    assigned
    dezren39
    on Oct 29, 2026
  9. dezren39
    added
    queue/queuedHas a queued task in the Supabase agent queue
    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

  10. 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 7294 (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

  11. dezren39
    added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    status/in-progressQueue worker lifecycle state
    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

  12. dezren39 commented on Nov 3, 2026

    @dezren39
    dezren39
    on Nov 3, 2026
    MemberAuthor

    🤖 Agent note · done

    Re-triage verdict — design already done, cutover already live and verified; the one remainder is owned by task 8468

    Fresh verification this claim (gh + cron status, 2026-11-03):

    1. The design triage is already complete. Task 3163 (2026-10-29) verified the premise and decided the design on this issue (one job / one picture per cycle, SWEEP-then-DISPATCH, the escalation ladder, measurement gate binding, reversible cutover, checkable success metric). Nothing in the design is left open.
    2. The implementation already landed. Issue Implement the session conductor: merge openchamber-dispatcher + openchamber-babysitter into openchamber-conductor #2153's cutover (task 3806, 2026-10-30) created openchamber-conductor (20m, 2700s), disabled — not deleted — openchamber-dispatcher and openchamber-babysitter, updated all three fleet-watchdog roster touch points, and first-run verification passed the same day.
    3. Current fleet state (fresh cron reads today): openchamber-conductor is now disabled, last run Mon 2026-11-02 12:15 CST, succeeded. The dispatcher and babysitter remain disabled (last runs 2026-10-30), so the rollback pair is intact but not exercised. The conductor's log (hidden_files/conductor-log.md) ends with the 2026-11-02 11:52 CST cycle. Whatever superseded the conductor after 2026-11-02, it was not a rollback to the pair.
    4. The single remaining acceptance item is the 48h cost comparison (conductor input per the daily token check-in vs the 273M dispatcher+babysitter baseline, normalised by sessions swept/dispatched from the conductor log, target ≤60% at equal sessions served, to be posted on this issue). That item is already owned: task 8468 (issue Implement the session conductor: merge openchamber-dispatcher + openchamber-babysitter into openchamber-conductor #2153 acceptance remainder) is parked with the exact method recorded, and it already posted the owed design: scheduled OpenCode preliminary babysitter — sweep sessions, fix easy stalls, escalate the rest #2021 link addendum. No new task or issue is created here — duplicating that ownership is the failure this re-triage exists to avoid. Note for task 8468's resume: the conductor stopped running on 2026-11-02, so the comparison window is bounded by the 2026-10-30 → 2026-11-02 live period.

    Disposition: triage task 7294 completes as triaged. Issue #2132 stays open until task 8468 posts the cost comparison here; that comparison is its only remaining acceptance item.

  13. dezren39
    removed
    status/in-progressQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 3, 2026

  14. dezren39 commented on Nov 4, 2026

    @dezren39
    dezren39
    on Nov 4, 2026
    MemberAuthor

    Conductor 48h cost comparison — acceptance item for #2153

    Window: the conductor's first 48h live, 2026-10-30T22:13Z (cutover, queue task 3806) → 2026-11-01T22:13Z.
    Source: the daily token check-in attribution (muse.db agent.agent_message_token_usage joined to agent.agents on spawn_metadata_json ->> 'scheduler_cron_job_id'), the same source as check-in #5. Method cross-validated: this attribution reproduces check-in #8's published conductor figure for the overlapping window (96.39M measured vs 96M published).

    Conductor (single merged job, 20-min cadence)

    • Input tokens in window: 398.35M (output 1.98M)
    • Runs: 139 (scheduler job_runs; matches 139 cycle entries in hidden_files/conductor-log.md)
    • Input per run: 2.87M; input per hour: 8.30M
    • Work served in window: every cycle swept the full live OpenChamber session population; 14 sessions dispatched (summed from the conductor-log cycle entries in the window)

    Baseline — dispatcher + babysitter (daily token check-in #5, 2026-10-28 09:17→23:56 CDT, ~14.7h)

    • Dispatcher 149.4M (49 runs) + babysitter 124.2M (43 runs) = 273.6M input
    • Input per hour: 18.68M; combined input per 20-minute slot: 6.23M

    Verdict vs the ≤60% target

    • Per hour: 8.30M / 18.68M = 44% of baseline
    • Per 20-minute cycle slot: 2.87M / 6.23M = 46% of baseline

    PASS — the merged conductor runs at roughly 44–46% of the dispatcher+babysitter pair's input cost, comfortably under the ≤60% target, while covering both jobs' sweep+dispatch function every cycle.

    Caveat on "equal sessions served": the pair's per-cycle swept-population counts for the baseline window were not recorded in a single comparable log, so the comparison is stated per hour and per cycle slot (the form the #2153 acceptance specifies: conductor input per cycle against the pair's ~15h baseline). The conductor's dispatched count for its window is 14 sessions; no dispatch was suppressed for cost reasons in any cycle entry in the window (hand-backs were gate/ownership/packet-validity dispositions, with the Workhorse gate open).

    Posted by queue task 8468 (lane code-i). This completes acceptance item 1 of #2153; item 2 (#2021 linked from the #2153 cutover report) was completed earlier (comments 6614026909 / 6614030429 on #2153 / #2021).

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 jobtask/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