tai/research/cap-protocol/conclusions/cap-model-handling-practice.md

Conclusion: How tai should handle models of CAP agents

Metadata

Field	Value
Institute	Molodetz Institute — Research & Retrieval Division
Subject	cap-protocol
Document type	Conclusion
Tier	N/A
Date decided	2026-10-25 (recommendation only, retoor has not yet decided)
Decided by	tai (agent, Claude Sonnet 5) as a recommendation, pending retoor
Status	Active
Confidence	Medium

Question / problem statement

What do CAP and the neighboring protocols say about models and their usage, and what should tai's CAP side do about discovery, selection, precedence, cost and budgets.

Conclusion

Treat a model as session configuration attached to an agent, resolved by an explicit precedence, never as agent-private knowledge. (1) Discovery order: the live model-category config option from ACP session setup for acp_stdio agents, then the manifest [models] list, then the --cap-models probe (CAP itself has no model list). (2) Selection: the caller passes a name or substring hint and the side that owns the catalog resolves it (MCP sampling hints, Claude Code aliases), which tai's fuzzy matcher already does. (3) Precedence for a delegated call: per-call model, then the agent's configured model, then a global default, then the parent's model; document it, because Claude Code's own order changed between releases. (4) Pass the model through model_arg; when an agent has none, warn instead of failing (already done). (5) Count cost from cap.usage (model_id, tokens, cost_usd_estimate) and enforce budgets in the orchestrator, never in the agent. (6) Expect delegation to cost a multiple of chat tokens (Anthropic reports about 15x) and cap it.

Supporting sources

• cap-core-v1: model in session config, model_arg, cap.usage, orchestrator-enforced budgets (forward-corrected in this pass).
• cap-profile-coding-v1: no model or cost fields; per-agent permission and scope settings.
• agentclientprotocol-session-config-options: live model options, defaults, ordering.
• modelcontextprotocol-sampling-model-preferences: hints plus priorities, owner decides.
• claude-code-sub-agents-docs: per-worker model and precedence.
• anthropic-multi-agent-research-system: token multiple and model-tier results.
• lmsys-routellm-blog: two-tier routing savings.

Alternatives considered and rejected

• Wait for CAP to standardize a model list: CAP's own STATUS marks no such work, and tai needs it now.
• A trained router (RouteLLM style): needs training data and a dependency; the calling model or the user already knows when a task is hard.
• Per-agent hard-coded model tables in tai: stale within weeks as providers rename models.

Risks / open questions

• ACP discovery is not implemented in tai's CAP code; only the manifest list and probe exist.
• The precedence order is a recommendation, not something users have been asked about.
• Cost fields depend on agents reporting cost.metered; unmetered agents give no budget signal.

Action taken

Nothing built beyond what already exists (manifest list, probe, fuzzy resolution). ACP discovery and the precedence rule are specified here only.

Changelog

Date	Change
2026-10-25	Initial conclusion recorded as a recommendation.