PT EN

Blog

Notas sobre dados, arquitetura e nuvem.

Every task on the right model

Would you call a senior dev with 20 years of experience to rename a variable? Neither would I. But that is more or less what happens when every subagent runs on the same model.

I built a Claude Code plugin to try to fix that.

The problem

When Claude Code spawns a subagent, it runs on the session’s model, even if the task is small and mechanical. Renaming a field and redesigning a module cost the same “brain”.

Even when you write a prompt or a spec, the one choosing the model and the effort is the model that is already running.

In the end, we spend our usage on these tasks, when we could be spending it on actual development.

The idea

Think of a service desk. Someone with a simple question talks to the front desk. Someone with a hard case goes to the specialist. Nobody finds that strange. Routing each task to the right model is the same thing.

The plugin intercepts Claude Code’s subagent spawns (the Agent tool) and asks JEV, from TypeSafe, what that task needs: model (haiku, sonnet or opus), effort and tool profile.

Installation

In a Claude Code session:

/plugin marketplace add hiyoku/jev-orc
/plugin install jev-orchestrator@jev-orc

The second command opens the details so you can pick the scope: user, project or local. After that, you just set the JEV key, in the typesafeApiKey field (stored in the macOS Keychain) or in the TYPESAFE_API_KEY variable.

You don’t call JEV yourself. With the plugin on, spawns go through it. By default, only Claude Code’s own agents are routed. /jev-orc turns it on and off, and /jev-orc status shows the current state. There is also an explicit mode, which only routes spawns whose description starts with [jev].

What JEV decides

JEV reads the task text (up to 4000 characters) and returns numbers: complexity and confidence, deliberation, and whether the task edits files, runs shell, searches the web, looks up library docs or uses a browser.

What turns that into a choice is the plugin’s policy:

  • Low complexity goes to haiku, medium to sonnet, high to opus.
  • Low confidence goes up one level.
  • File editing gets a profile with edit access. Otherwise, the profile is read-only.

The two skills

Routing works best with well-sliced tasks. That’s why the plugin has two skills.

/jev-orchestrator:plan <request> only writes files, it doesn’t run anything. It creates docs/dev/NNN_<ShortDescription>/ with:

  • prompt.md: goal, context, constraints, definition of done, a task table and the execution “waves” (which tasks can run in parallel).
  • One file per task (01_..., 02_...): each one small, with at most 3 files and about 60 lines of diff, with exact paths and a verification command.

An example from the README:

/jev-orchestrator:plan Add the --json flag to the export command. Files:
src/cli/export.ts and its test. Default output unchanged. Done when
`npm test` passes and `export --json` prints valid JSON.

Add docs/dev/ to your project’s .gitignore: the plan is local and shouldn’t go into the repository.

The README tip: ask an AI to write the full request before calling plan.

/jev-orchestrator:run 001 reads the plan and spawns one agent per task, wave by wave. Without a number, it uses the most recent folder. If a task fails, the waves that depend on it stop and you get notified. The independent ones keep going. At the end, it reports what was done, what failed and what was skipped. Commit only if you ask.

Why does the plan matter? Small, mechanical tasks are exactly what JEV sends to the cheapest model, haiku. The savings come mostly from the plan.

What if JEV fails?

Missing key, timeout, network down: the spawn runs anyway, with sonnet and medium effort. The plugin never blocks the spawn.

Savings and privacy

The plugin shows a status line. This is the README example, in the plain style:

jev ON · haiku·low·t-read · 42k tok $0.08 · vs opus/high ~$0.31 (-74%) — high

Heads up: the savings shown are an estimate, not a measurement, and this number is just a README example, not a general result.

Decisions are kept in a local log, at ~/.claude/jev-orchestrator/decisions.jsonl. The key, the full prompt and tool results are never written. On the other hand, the task text (up to 4000 characters), the agent name and the description are sent to the JEV endpoint on every routed spawn. Worth knowing before you turn it on.

What I’m working on right now

  • The cutoffs for model and effort haven’t been calibrated with enough data yet. I’m using the plugin day to day, and the decision log, to calibrate them.
  • The savings are just an estimate.
  • JEV’s confidence tends to come back high even for vague requests.

If anything here is useful, or you have a suggestion, reach me on LinkedIn. Or, if you prefer, open a PR at hiyoku/jev-orc and I’ll be happy to have your contribution.

If everyone who can chips in a little, we end up with something that helps everyone.

← todos os posts