tutti/packages/agent/runtimeprep/skill_templates/tutti-model-allocation.md

name, description

name

description

tutti-model-allocation

Allocate Tutti plan tasks to current Agent targets and models using independent effect and speed preferences, C0-C3 capability tiers, a 1-4 parallel target, hard capability constraints, and effect-scaled verification. Use when creating or revising a Tutti Mode task graph, choosing each task's agentTargetId/model/reasoningEffort, or auditing whether assignments satisfy the requested effect and speed.

Tutti Model Allocation

Choose from current runtime evidence, not from memory. This skill supplies the selection policy; agent list and agent composer-options supply the exact launch ids and current model catalog.

Workflow

1. Read preferences

• Let effect set the minimum outcome-quality tier and verification breadth.
• Let speed choose among models that satisfy that tier and set the parallel target.
• Keep them independent. Never average them.

2. Derive the parallel target

Speed	Parallel target
0-24	1
25-49	2
50-74	3
75-100	4

Treat this as an upper planning target, not a promise. Shape real independent workstreams so up to that many tasks can be ready together, but never invent tasks to fill the target. Dependencies, ownership boundaries, safe isolation, budget, ready work, and workspace capacity always win. Schedule no more than the target at one checkpoint.

3. Build the joint candidate matrix

Run agent list once. Shortlist every launchable target whose description and advertised capabilities could plausibly fit any plan task, including non-current targets. Run agent composer-options for every shortlisted target.

Compare joint (agentTargetId, model, reasoningEffort, permissionModeId) candidates. Do not select an Agent first and then limit model choice to that Agent. Do not skip a plausible non-current target merely to avoid another composer-options call.

4. Apply hard constraints

• Honor an explicit user model, model plan, or target.
• Require advertised image/tool/context capabilities needed by the task.
• Use only exact agentTargetId, model, and permissionModeId values returned by the current commands.
• Ignore a requested-origin model entry as proof of provider support.

5. Remove affinity bias

• The planning/source Agent, its provider, its current model, and provider defaults receive no suitability bonus.
• Require both Agent fit and model fit. A strong model cannot compensate for a target whose description, instructions, or call conditions conflict with the task; a familiar Agent cannot compensate for a model below the required tier.
• Rank the joint candidates from task evidence even when another Agent exposes a better model than the planner's own target.
• The planning Agent may still win when its candidate is objectively the best fit or the user selected it explicitly. Record the task-fit reason; familiarity with the current Agent is not a reason.
• When candidates are equivalently qualified for safely independent work, prefer a non-planning target so the planning Agent remains available for coordination and final integration. Never apply this tie-breaker against a stronger or safer model.

6. Classify the task

Tier	Task shape
C0	Bounded extraction, formatting, short rewrite, simple lookup, or low-risk mechanical edit
C1	Normal single-area implementation, routine debugging, ordinary analysis, or focused test work
C2	Multi-step implementation, cross-module change, difficult debugging, integration, or substantial review
C3	Architecture, high-stakes or ambiguous work, hard recovery, deep review, or final synthesis across workstreams

7. Derive the effect floor

Effect	Model floor	Verification floor
0-19	C0	One focused check or explicit inspection
20-59	C1	Relevant targeted tests/checks
60-84	C2	Relevant tests plus integration and edge coverage when applicable
85-100	C3	Broad relevant tests, edge/variant coverage, and explicit final review

The required tier is max(task tier, effect floor). A low effect never makes an intrinsically difficult or high-risk task safe for a weak model.

8. Rank eligible models

Speed	Choice within the eligible set
0-24	Prefer the strongest stable model and useful capability headroom
25-59	Prefer the balanced/default suitable model
60-84	Prefer the lowest-latency model that clearly satisfies the tier
85-100	Prefer the fastest qualified model or fast service variant; never reduce the tier or effect-derived reasoning

Rank only models at or above the required tier. Apply task-shape fit before speed: a specialist C3 route is not automatically suitable for every C3 task.

9. Encode the assignment

Write the exact assignment and concrete effect-scaled validation in every task brief. Use per-task reasoningEffort only when the task needs to differ from the plan's effect-derived reasoning intensity.

Model Evidence

Read references/model-tiers.md when exact model families must be classified. Treat that file as a routing prior, not an availability catalog:

• exact current composer-options output always wins for availability and ids;
• provider descriptions and advertised capabilities win over family-name inference;
• a -fast or service-speed variant keeps its base model's capability tier unless current provider evidence says otherwise;
• when one model spans several tiers, reasoning effort distinguishes the tiers;
• if classification confidence is low, fall back to the provider default only for C0/C1 work. For C2/C3, choose a clearly stronger described model or a different target with a known ladder, and record the assumption.

Review

Before proposing the plan, verify:

• every plausible target was considered jointly with its models, and at least one non-current target was compared when one was available;
• no assignment received a bonus for matching the planning Agent, current provider, current model, or a provider default;
• every task clears its inherent tier and the effect floor;
• speed changed the choice only within the qualified set;
• the graph exposes real safe concurrency toward the parallel target without fabricating work, and no scheduled set exceeds it;
• all launch values came from current command output;
• image and other hard capability requirements are satisfied;
• verification text is observable and proportional to effect;
• final integration/review tasks are not assigned below the strongest work they must judge.