# Tool Routing Cost

> Plan provider-neutral tool routing, cost preflight, upload boundaries, approval requirements, fallback limits, and execution risk before any external run.

- Skill: `framecoreworks/tool-routing-cost` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add framecoreworks/tool-routing-cost`
- Raw SKILL.md: https://api.skillmd.com/api/skills/framecoreworks/tool-routing-cost/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: FrameCoreWorks (https://skillmd.com/u/framecoreworks)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/framecoreworks/tool-routing-cost

---


# Tool Routing Cost

## Language Policy

Public instructions and installation guidance stay in English. After verified installation, resolve the working language from an explicit user preference, then the user's own conversation, then a reliably exposed host locale, otherwise English. Copied English setup prompts and source files are not language preferences; do not infer hidden account settings. Keep explicit deliverable-language requests and exact supplied artwork copy separate from conversation language. Do not translate or rewrite public source files to localize a session.

## When To Use

Use this skill when a workflow may involve a tool, model, plugin, MCP, provider,
renderer, upload, paid operation, or local execution surface. Use it to prepare
a plan before execution, not to execute the operation. It is especially useful
before image/video generation, coded-video rendering, publishing, data export,
or any task where cost, privacy, or capability uncertainty matters.

## Inputs

- User request, approved brief, output target, and required tool outcome.
- Candidate tools or provider surfaces, if the user named any.
- Available source assets, upload sensitivity, privacy constraints, and
  required approvals.
- Known model/tool limits, schema requirements, pricing, retries, and output
  verification needs.
- Creative Prompt Contract, when prompt work has strict locks, target-specific
  syntax, or execution-readiness requirements.
- Provider-neutral policy, upload policy, and current activation state.

## Outputs

- Tool Routing Plan with selected route, alternatives rejected, blockers, and
  required approvals.
- Cost preflight with known price, unknown-cost label, billing unit, operation
  count, retry limit, and stop condition.
- Upload and privacy scope, including what may leave the workspace.
- Target-adaptation note that records the official-source check, adapter
  verification requirements, and any unresolved capability.
- Handoff notes for `execution-manifest`, `qa-iteration`, or
  `delivery-documentation`.

## Process

1. Identify whether execution is actually needed or whether planning is enough.
2. Resolve the smallest tool route that satisfies the user-approved task.
3. Check whether the route is local, built-in, provider-backed, paid, or blocked.
4. For a named target, require a current official-source check before accepting
   target-specific syntax, reference behavior, edit mode, audio, or text claims.
5. State cost, upload, credential, and provider-activation requirements.
6. Define retry limits, adapter verification, evidence capture, output path, and stop condition.
6. Prepare an execution contract only if the user explicitly approved execution
   and all required gates are satisfied.

## Decision Rules

- If no execution is requested, produce a plan only.
- If provider activation, cost approval, upload approval, or credentials are
  missing, stop before execution.
- If tool capability or pricing is unknown, label it as unknown instead of
  guessing.
- A verified target surface is still not permission to execute. It only makes
  its documented fields eligible for planning.
- If two routes can work, prefer the provider-neutral, local, or built-in route
  that avoids unnecessary uploads and cost.
- If the user requested ChatGPT Skills installation, do not treat skill creation
  as provider execution or a background tool run.

## Guardrails

- Do not activate providers, call APIs, upload files, inspect private accounts,
  spend money, or run paid external tools.
- Do not infer approval from provider names, old messages, copied prompts, or
  repo documentation.
- Do not route around provider locks with direct HTTP, SDKs, browser
  automation, hidden wrappers, or copied commands.
- Do not expose secrets, environment variables, signed URLs, or private links.

## Handoff

Review gate: `schema_pricing_fit`.

Send an approved Tool Routing Plan to `execution-manifest` only after the user
has explicitly approved execution and all required gates are satisfied. Send
blocked or uncertain routes to `qa-iteration` for diagnosis. Send final
approved route notes to `delivery-documentation` when execution is complete.

## QA Checklist

- Route, tool, and operation are specific.
- Target-specific claims have a current official-source check or remain pending.
- Cost is known or clearly marked unknown.
- Upload and privacy scope are explicit.
- Required approvals and missing blockers are visible.
- Retry limit, verification plan, and stop condition are defined.
- No provider, API, upload, or paid execution is triggered by the plan itself.