[FEATURE] Allow subagents to target a local OpenAI-compatible endpoint for mechanically-verifiable subtasks

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 23, 2026

Preflight Checklist

  • [x] I have searched existing issues (local model, ollama, delegate, offload) and found

no duplicate. Existing "local model" issues concern running Claude Code against a local
model, which is the opposite direction.

  • [x] This is a feature request, not a bug report.

Problem Statement

Subagents can only target Claude model IDs. That's correct for reasoning work, but it means there
is no native way to route the mechanical portion of a task to a cheap local model, even when the
result can be mechanically proven correct before Claude sees it.

I measured what that costs. 66 tasks, seven families, each gated by a deterministic oracle — unit
tests, mutation testing, result-set comparison against a fixture, verbatim grounding — using
qwen2.5-coder via Ollama on a 12 GB laptop GPU. Coverage is the fraction the gate accepted:

| family | oracle | 7B | 14B |
|---|---|---:|---:|
| sql | execute vs fixture, compare rows | 100% | 100% |
| extraction | schema + verbatim grounding | 58% | 83% |
| config | real validator + semantic check | 67–83% | 83% |
| transform | exact match on canonical output | 67% | 83% |
| codegen | unit tests | 50% | 75% |
| patterns | run against a hidden example set | 50% | 64% |
| testgen | mutation testing | 33% | 50% |
| overall | | 61–64% | 77% |

At 77% coverage the accepted fraction needs no review at all — the gate is binary, so there is
nothing to weigh. The context saving matters more than the token saving: in a long session the
binding constraint is the window, and "read 200 files and report which mention X" spends context
that is then unavailable for the actual work.

This is buildable today via an MCP server, and I built one to measure it. But the gate then lives
outside the agent loop, and every existing community attempt I found gets the economics wrong by
using a model as the gate — one plugin's README honestly prices this as
tokens × (output_price − input_price), i.e. the read-back eats most of the saving.

Proposed Solution

Allow a subagent — or a narrower delegation primitive — to target an OpenAI-compatible
endpoint
(base_url + model name), while leaving verification entirely to the caller.

Deliberately not asking for Claude Code to be routed to non-Claude models, or for any built-in
notion of quality. The orchestrating model stays Claude; only clearly-scoped mechanical subtasks
are dispatched, and the plugin author remains responsible for the oracle. Something like:

# agents/local-extractor.md frontmatter
provider:
  base_url: http://localhost:11434/v1
  model: qwen2.5-coder:14b

A smaller variant that would also help: a way to mark an MCP tool result as already verified,
so the model is not inclined to re-derive it. Much of the read-back cost above is Claude
sensibly double-checking output that a compiler already proved.

Alternative Solutions

  • MCP server (what I did). Works. The gate sits outside the agent loop, and each plugin author

re-implements batching, escalation and oracle plumbing.

  • Do nothing. Defensible. The addressable workload is genuinely narrow — it needs the same

operation across dozens of items where the check can be written once. Diagnosis, design,
debugging and review have no oracle and must never be delegated.

If it's useful, one finding is worth documenting regardless of whether anything ships: select
delegation targets by oracle strength, not task difficulty.
Code generation is safer to
delegate than classification, which inverts the intuition — tests are a hard, cheap judge, whereas
classification has no oracle at all, so failure is undetectable.

Harness, all 66 tasks, and every run log (MIT):
https://github.com/slhuckstead/verified-delegation

Priority

Nice to have

Feature Category

Extensibility / plugins

View original on GitHub ↗