Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add rules/hamzaamjad/cursor-rules/303-multi-model-tool-integrationgit clone --depth 1 https://github.com/hamzaamjad/cursor-rulesWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.00999 |
| Opus 5 | $0.00000 | $0.00500 |
| Sonnet 5 | $0.00000 | $0.00200 |
| Haiku 4.5 | $0.00000 | $0.00100 |
Grade A, and why
303-multi-model-tool-integration scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 61 lines — stays where its author put it; the contents beside it link to each section on GitHub.
multi-model-tool-integration.mdc
-
Purpose: To guide the effective design and implementation of workflows involving multiple LLMs and external tools (APIs, functions), ensuring robustness, appropriate model selection, and reliable orchestration.
-
Requirements:
- Model & Tool Selection Strategy:
- Define clear roles for each model and tool within the workflow.
- Choose the LLM for each sub-task based on its specific requirements:
- Use faster/cheaper models (e.g., Haiku, Sonnet, GPT-3.5-Turbo) for simple tasks like classification, extraction, formatting, or routing.
- Use more capable models (e.g., Opus, GPT-4) for complex reasoning, generation, summarization, or tasks requiring deep understanding.
- Document the rationale for model and tool choices per step.
- Workflow Orchestration:
- Design clear sequences for tool calls and model interactions. Use established patterns where applicable (e.g., ReAct, RAG).
- Plan data flow meticulously between steps.
- For complex workflows, manage intermediate state explicitly (e.g., pass necessary context between steps, use a state machine or persistent memory).
- Prompt Management:
- Centralize prompt templates for consistency and reusability.
- Version control prompt templates alongside agent/workflow code.
- Error Handling & Resilience:
- Implement robust error handling for both model calls and tool executions.
- Use retries (with exponential backoff) for transient network issues or temporary model/tool unavailability.
- Define clear fallback logic (e.g., use a simpler model, return a default response, skip an optional step, alert a human) for persistent errors or unexpected outputs.
- Data Privacy (PII Protection):
- Before calling external tools or models (especially those outside a defined trust boundary), identify and strip/mask Personally Identifiable Information (PII) from the data being sent.
- Logging & Observability:
- Log all significant inputs, outputs (or summaries of large outputs), and latencies for both model calls and tool interactions.
- Include comprehensive metadata for traceability (e.g.,
traceId,agentId, model/tool name, timestamp, version). - Log errors clearly and comprehensively for debugging and monitoring.
- Model & Tool Selection Strategy:
-
Validation:
- Check (Design Review): Review the workflow diagram or plan. Is the model/tool selection justified for each step? Is the sequence logical? Are potential failure points and their mitigations identified? Is PII handling considered?
- Check (Code Review): Inspect model/tool call logic for robust error handling (retries, fallbacks). Verify PII stripping occurs before external calls. Review state management and logging logic.
- Check (Testing): Include tests for various error conditions (e.g., tool API failure, model timeout, unexpected model output) to verify fallback logic. Test PII stripping effectiveness. Verify logs contain required information.
-
Examples:
- Model Selection Rationale: "Step 1 (Intent Recognition): Use Claude Haiku for speed/cost as it's a simple classification task. Step 3 (Draft Response): Use Claude Opus for higher quality generation based on retrieved context."
- Error Handling (Conceptual):
try: result = call_external_api(query) except TransientError as e: # Retry logic with exponential backoff time.sleep(2**retry_count) result = call_external_api(query) # Simplified retry except PersistentError as e: logger.error(f"API call failed permanently for traceId {trace_id}: {e}") result = None # Fallback: proceed without API data or trigger alert - PII Stripping (Conceptual):
user_query = "Find docs about project X for user [email protected]" cleaned_query = strip_pii(user_query) # -> "Find docs about project X" search_results = call_search_tool(cleaned_query)
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 61 lines · 0 tokens per session scan A 2cdab3fa2c6c
303-multi-model-tool-integration is a cursor rule published in the GitHub repository hamzaamjad/cursor-rules (2 stars, last pushed 1y ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 999 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other cursor rules, from other repositories
angular-20
This rule provides comprehensive best practices and coding standards for Angular development, focusing on modern TypeScript, standalone components, signals, and performance optimizations.
dev-standard
Apache Superset development standards and guidelines for Cursor IDE.
cli-error-handling
CLI command error handling patterns.
prefer-direct-imports-over-module-mocks
Prefer extracting a testable core over vi.mock / vi.resetModules when unit tests need to reach production logic entangled with config, env, or singletons.
control-plane-descriptors
Control plane descriptor and instance implementation patterns.
family-instance-domain-actions
Family instance domain action implementation patterns.