Skip to content

Prism routes delegated work through Chromeria's thread tools; retire the Python runner #92

Description

@lukemaj

What: Prism becomes the whole router inside Chromeria: a planner's dispatcher runs workers and reviewers through Chromeria's thread tools, and the Python runner (toolboxmd/model-router) retires.
Why: The runner duplicates what Prism and the thread tools already do, and its own controller layer caused most failures: of 23 runner jobs since 2026-09-24, 2 succeeded and 14 were cancelled, while 184 of 200 direct spawn_thread children finished their last turn cleanly.
So what: Done except one proof: the first real usage-limit or stale child that a coordinator interrupts and replaces gets recorded here; the planner records it when it happens, then closes this Issue.

Outcome

A planner in a Chromeria thread hands a task to a dispatcher thread (spawn_thread(role: dispatcher)). The dispatcher starts workers, a reviewer, and retry or escalation threads with spawn_thread, Prism picks each role's model, and the job ends in one open, independently reviewed PR reported back to the planner. No Python runner is involved, and the runner's hooks and repository are retired.

Problem Statement

Delegated work runs through a separate Python runner that starts every T3 thread itself, parses the dispatcher's JSON replies, keeps its own job database and recovery, and re-implements model choice and stall handling that Prism already provides. That layer is where jobs fail (#132, #142, #143 in toolboxmd/model-router; stuck cancels, failed resumes and interrupts in the runner ledger), and Prism's names and permissions are a second vocabulary that confuses users and agents.

Solution

  • Prism (in Chromeria) is the router: six roles (planner, dispatcher, worker, reviewer, retry, escalation), each with an ordered model list (the worker one per lane), instructions and skills; the picker inside spawn_thread(role) takes the first eligible model and skips used-up limits; stall detection notifies the parent.
  • Chromeria's thread tools are the mechanism: spawn_thread, message_thread, read_thread, list_child_threads, list_threads, plus a new interrupt_thread; report-back wakes the parent.
  • The dispatcher's routing rules (lane choice, retry then escalation, independent review on the exact head, one open PR, report to the planner) live in the dispatcher role's default instructions, versioned in code.
  • Retired: the five prism_* tools, /api/prism/snapshot and /api/prism/liveness, the runner exceptions, and the toolboxmd/model-router repository.

Elon record

  • Requirements and who asked: the user (2026-10-01) asked that routing stay, use spawn_thread, and drop duplicated work; Prism roles use the role names only; every role gets every thread tool; the runner retires and its repo is archived. Mission: choose model, harness and effort from evidence, fall back on capacity, keep agents visible.
  • Deleted: the runner's controller, job database, relaunch and recover, JSON reply protocol, baseline proof, completion gate, its copy of model choice and stall handling (about 12,000 lines of Python); the prism_* tools and both runner routes; per-role thread-tool limits and their level names; the correction/recovery internal names.
  • Bottleneck: the runner's controller and thread plumbing, not routing decisions.
  • Checked myself: the runner ledger (23 T3-era jobs, which logic fired), a copy of T3's thread database (249 child threads), Chromeria's roles.ts, prism.ts, prism routes and their callers (only the runner), fix(server): recognize remotes in partial clones #138's evidence that role limits blocked review, and the AgentsMD orchestration and verification procedures that already own Issue context, proof and review.

Acceptance criteria

  • One real task goes planner, dispatcher, worker, reviewer and ends in an open PR with an approving independent review on its exact head, reported back to the planner, with no runner process or prism_* call.
  • A child that hits a usage limit or is marked stale is interrupted and replaced by the next eligible model in its role without a second writer on the branch.
  • Every role can use every thread tool; Settings, spawn_thread and the code use the same six role names.
  • A child's report-back still reaches its parent once after a server restart.
  • The prism_* tools, both runner routes and the runner exceptions are gone from Chromeria; toolboxmd/model-router is archived.

User stories

  1. As the user, I want to hand work to my planner and get a reviewed PR without choosing models or watching a runner.
  2. As a planner, I want to start one dispatcher with a task and be woken only for a decision or the result.
  3. As a dispatcher, I want to start, message, read and stop my own workers and reviewer directly.

Implementation decisions

  • Role permissions are removed rather than reconfigured; misuse is watched by Agent Observer (runaway nesting, messages into threads that are not the sender's child) and limits return only on evidence.
  • interrupt_thread mirrors upstream V2's t3_thread_interrupt so it ports when orchestration V2 lands.
  • Default dispatcher instructions point at the AgentsMD orchestration and verification procedures instead of restating them.

Testing decisions

  • Unit tests at the existing thread-toolkit and Prism contract seams for names, permissions, report-back restore and interrupt.
  • One live end-to-end task as the final proof, recorded on this Issue.

Non-goals

  • Porting to upstream orchestration V2.
  • Capability-based routing or a learned routing policy.
  • Merging Agent Observer into Chromeria.
  • Planners outside Chromeria.

Blockers

None.

Required proof

  • Each sub-Issue's tests and CI on its exact head, with independent review.
  • The live end-to-end task: thread ids, PR URL, review verdict and SHA.

Further notes

Watching for misuse after permissions open: a toolboxmd/agent-observer Issue. Direction change: Chromeria MISSION.md and OBJECTIVE.md.

Activity

  1. lukemaj commented on Oct 1, 2026

    @lukemaj
    ContributorAuthor

    Status 2026-10-01T16:04Z: all sub-Issues closed (#93-#98). Acceptance:

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions