How I Route Kanban Workers to the Right AI Model

Recently I changed how my Hermes Kanban board chooses an AI model.

Previously, every profile used the same model. It was simple, but it was also lazy. A worker reviewing a release decision and a worker helping me edit documentation do not have the same job. Why should they have the same capacity and the same cost?

The board now routes workers by responsibility.

The central part of the routing update. I cropped out the account and session sidebars before putting this into the draft.

The split

The live authenticated Codex catalog exposed three models I could use: gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna.

I assigned them to three rough tiers:

• Sol for work where a bad answer has a real engineering or operational cost.
• Terra for coordination, API implementation, and general-purpose work.
• Luna for drafting, documentation, and other work where efficiency matters more than maximum coding capability.

In the board configuration, that became:

This roughly matches how the board has actually been used. Backend consumed the most capacity recently, followed by QA and release work. Those are the profiles where a little more model capability is easiest to justify.

OpenAI’s positioning also gives the split a useful shape: Sol is the flagship coding tier, Terra is the balanced everyday tier, and Luna is the cost-efficient tier. I am using that positioning as a practical configuration signal, not as a reason to write benchmark fan fiction.

Risk is a better routing rule than prestige

The obvious way to choose a model is to give the best one to everything. That is also the easiest way to lose the economic benefit of having several models.

A release worker may need to understand a diff, CI failures, deployment behavior, and rollback consequences. A QA worker has to notice a regression that looks harmless in a small patch. A backend worker may be changing policies, migrations, or shared domain logic. These jobs deserve the stronger model because the review cost of a wrong answer is high.

The documentation worker has a different failure mode. It can still produce bad work, and I still review it. But the job is mostly organizing known material, improving wording, and keeping release notes consistent. Spending the maximum model budget there does not buy the same amount of risk reduction.

This is the same principle I use for infrastructure: put reliability effort where failure is expensive. Model selection is another resource allocation problem.

The important operational detail

Changing a profile’s model does not teleport an already-running worker into a new model.

A worker keeps the model it started with. The new setting applies to the next spawned session. This matters when changing a live board: the configuration can be correct while the currently running worker is still using the old model.

That is a small detail, but it is exactly the kind of detail that creates confusing incidents. You change the setting, look at the worker, and wonder why its behavior has not changed. The answer is that the worker is a process with state, not a static row in a configuration table.

What I will watch

This routing is a policy, not a conclusion. I want to observe a few things:

• whether Sol actually reduces review and rework on backend, QA, and release tasks;
• whether Terra is enough for decomposition and API work;
• whether Luna produces documentation that needs more editing than it saves;
• whether the workload changes and makes the current split obsolete.

The board should make the cost and capability decision explicit. It should also make changing that decision cheap.

For now, this is a better default than pretending every worker has the same responsibility. Use the stronger model where judgment is expensive, the balanced model for the middle, and the efficient model for prose. Then check whether reality agrees.