Model Routing and Job Orchestration
A subsystem study of model selection and background job routing.
How a call reaches the right model, and how work reaches the right worker.
Jennifer Naomi Nguyen · systems work · Subsystem study · February 2026 – present · built with Claude Code and Codex
README · ARCHITECTURE · TECHNICAL · source
Where this fits
This is a closer look inside Context and Memory Workspace and Multi-Provider LLM Orchestrator, originally called Journal Club. They grew their routing layers independently, and putting them side by side makes the shared problem easier to explain.
Something needs to choose which model handles a call. Something also needs to decide when background work happens and which worker does it.
Choose by what the call is for
Context and Memory Workspace uses two levels of configuration. A tier describes the size of model to use. A profile describes the job: chatter, extraction, or analysis.
That lets a call say what it's for while the configuration supplies the model and compatible settings. Changing a model becomes a configuration change, and the call sites stay readable.
Keep the conversation moving
The workspace also has a queue for background jobs. A selector finds work and enqueues it; another job handles each item. Summaries, archives, and other derived work can move through that path while a conversation gets its response.
The queue separates selection from processing: selectors enqueue bounded sets of items, and each worker job handles one item. The architecture page shows the routing chain and the queue layout.
Across providers
The orchestrator adds another version of the problem: several model providers with different request parameters and response shapes. One adapter handles Anthropic directly and GPT, Gemini, and Grok through OpenAI-compatible interfaces.
That adapter serves both the Discord reading group and the prompt-composition experiment. Sharing it made a practical problem worth investigating: when outputs differ, how much comes from the prompt, and how much comes from how the tool collects them? The research walkthrough follows the pilot and its debugging lessons. This page focuses on the machinery that supports it.
The technical page explains the profiles, compatibility checks, and queue behavior. The source excerpts show what those ideas look like at the call site.
The orchestrator's public repository includes the shared provider adapter, experiment runner, and offline tests. The workspace implementation remains a separate project; this release does not publish its backend.
The next half of the story
Once a call comes back, I want to know what actually answered and how to interpret the response. That's the Systems Logging and Telemetry study.
This page pulls out the routing work so it's easier to explore than finding it inside two full applications.