Claude Lane Orchestrator
A that hands work from a session to a chosen model running in its own separate process — a Lane — so a task can reach a wider and cheaper capacity than the built-in way of delegating allows.
The problem
If you pay for from several providers, a coding can usually reach almost none of it. The built-in way to hand work out inside Code is a , and a subagent is stuck with a fixed context budget and a choice of four generic tiers rather than a model you name. So you cannot point it at cheap capacity to save money, and you cannot give it a genuinely large input.
The result is a quiet waste on both sides. A flat-rate window you already paid for goes unused, while work that could have run for nothing runs on the most expensive capacity in the house.
What a Lane is
A Lane is the same coding agent, launched as its own separate process, with its own model, its own credential, and its own context budget. That separation is what buys the two things a subagent cannot reach: a much larger window, or a specific model chosen by name.
You do not pick the model. You say what the work is for, whether that is planning, implementing, or reviewing, and the tool asks the LiteLLM proxy which model currently fits that kind of work. If the first choice is unavailable it walks down the list on its own. You can still name a model when you want one, and a Lane can also reach a provider directly with no proxy involved.
A job's role decides what it may spend
Each kind of work declares what capacity it is allowed to use. By default that means only capacity that costs nothing at the margin: a flat-rate subscription, or a free tier. Anything that bills real money has to be named deliberately, either as a standing rule for that kind of work or as a one-off decision for a single job.
The rule is enforced before anything launches. When everything a job is allowed to spend on is exhausted, the work stops, which is the intended outcome. What comes back is enough to plan around: what ran out, what was ruled out and why, and when the soonest allowance refills. The cost of getting this wrong is easy to measure. One trivial test job dispatched to direct-billed capacity cost nearly three dollars.
It hands back evidence
A dispatch is judged rather than reported. The work happens in a tree, so the change is inspectable, and you can hand the tool your own acceptance command to run against that tree once the Lane is finished. Everything a job did is recorded, so cost and outcome can be added up later instead of taken on trust.
The same applies to what it will not do. Some work needs a bigger window than a model can honestly be given, and the tool refuses that job outright rather than starting it and letting it fail expensively three turns later.
Where it sits
It is the last of three projects, and the only one that knows anything about Claude Code specifically. The Model Discovery Feed publishes which models exist across providers. The LiteLLM Model Config Maintainer turns that into a working proxy and answers what is reachable right now. This project reads that answer and dispatches the work.
The split matters because only the last step is specific to one tool. The first two are facts about models that hold for any client.
Current state
Active and implemented, with the design decisions and the measurements behind them written up in the repository. It also ships an agent skill carrying the judgment the tool cannot make on its own: when a job is worth a Lane at all, how to brief it, and how to read the result.