Skip to main content
Glama

Split a task across models

plan

Split a multi-part task into routed parts with cost, time and model for each, letting Leanfare run the simple ones on cheaper or free models so your plan lasts longer.

Instructions

Before a task with several parts (a feature, a fix across files, a refactor, research across many files, reverse engineering a project), ask Leanfare how to split it. It answers with a short table: each part, its kind, where it runs (you, or Leanfare on a local, free or pay per use model), the model, about how long, the tokens it keeps out of the user's plan, and the cost; then what to do next. Leanfare starts its own parts at once by itself (local and free ones, paid ones within the user's cap) and this answers with those that finish within about 25 seconds: do not run them again with delegate. Do the parts it leaves to you, then call plan_status with the plan's id (wait 50) for the rest of Leanfare's answers, and review and grade each. Name the files or folders the task is about in files: here Leanfare only measures them, it reads them when delegate runs a part. A model the user ticked does the split (a few cents or less, $0 on free models; one that takes more than 40 seconds is let go, and the rules split it); split rules makes it by rules, with no model.

Input Schema

NameRequiredDescriptionDefault
runNofalse: only split the task; Leanfare runs nothing. By default Leanfare starts its parts at once.
taskYesThe whole task, as the user gave it, with what you already know about it.
filesNoThe files or folders the task is about: full paths, ~/ paths, or paths relative to folder. Only their names and sizes are used here.
levelNoThe Leanfare level for this chat or session, as the level tool or Leanfare's prompt line gave it. Leave it out when none was given.
partsNoAt levels 1 to 4, your own split: the task in parts, each with its kind (code changes the project; act needs your own tools), effort, the parts it needs and the files it reads (named as in files). Leanfare places each part. At level 5 leave it out: Leanfare's model makes the split.
splitNoauto (the default): a model the user ticked splits it. rules: Leanfare splits it by rules, with no model call.
checksNoOnce per project: the short list of cheap checks its work must pass, kept for the folder and shown with every plan made there. Each a line: "run: bun test" (a command you run yourself at the end), "words: utilize, leverage" (words Leanfare keeps out of what comes back, checked by itself) or anything to look at ("the Savings page fits one screen"). Giving it again replaces the list. Needs the project's folder.
folderNoThe folder relative paths start from. By default, the folder the MCP client started Leanfare in (in Claude Code, the project).
privateNotrue keeps the whole plan on the user's computer: the split and every Leanfare part go only to models there (Ollama), and a part none of them can take stays with you. Use it for anything sensitive or personal, or when the user asks.
your_modelNoThe model you run on, as your own instructions name it (for example claude-opus-5-5). Leanfare names it for the work that stays with you, and the report shows it as the prompt's main model.
your_effortNoThe thinking effort you run at, when you know it. The report shows it with your model.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.15.1

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only say it is not read-only, open-world and non-idempotent; the description adds what actually happens: Leanfare starts local/free/paid parts on its own within the user's cap, returns only parts finishing in about 25 seconds, and a split model costing more than 40 seconds is abandoned. It also discloses pricing ("a few cents or less, $0 on free models") and the private-mode behavior of keeping every part local, none of which is inferable from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every clause carries information, but it arrives as one dense run-on paragraph mixing the return table, the async handoff, files semantics, pricing and split modes. Semicolons do the work of structure, and key operational rules (don't re-delegate, wait 50, grade each part) are easy to miss on a first read.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter orchestration tool with no output schema, the description does the heavy lifting: it sketches the returned table's columns and states the follow-up call and grading step. What it leaves thin is the level/parts interaction (only the schema spells out levels 1-4 vs level 5) and what happens when a placed part fails.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the property descriptions already carry the run/default, files, split, checks, private and parts semantics, so most of the description's parameter prose is restatement. The genuinely additive piece is the cross-tool note that files are only measured here and read when delegate runs a part, plus that checks is once per project and replaces the prior list.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Before a task with several parts ... ask Leanfare how to split it" names the verb (split) and the resource (a multi-part task) and enumerates qualifying task types. It also separates this tool from its neighbors by naming delegate and plan_status and stating what each does instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit trigger (multi-part tasks), an explicit exclusion-by-redirect ("do not run them again with delegate"), a follow-up sequence (do your parts, then plan_status with the plan's id at wait 50), and a variant switch (split: rules when no model should be used). The only weakness is that the guidance is buried in a run-on paragraph rather than sequenced.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.