工具调用横向对比：27 个模型，三种请求结构
目录里每一个文本模型都支持 tools。真正的区别在路由——/v1/messages、/v1/responses、/v1/chat/completions——以及多轮循环在各个价位上要花多少钱。
工具能力筛不掉任何东西
目录 31 个条目里有 27 个列了 tools。27 个文本模型全部在内：12 个 Claude id、7 个能处理文本的 OpenAI id、grok-4.6、grok-4.5、grok-composer-2.5-fast，以及 5 个 Gemini id。没有的四个是 gpt-image-2、grok-imagine-image、grok-imagine-image-quality 和 grok-imagine-video-1.5——它们生成的是媒体，不调用函数。
这个情况值得直说：拿"支不支持工具"去筛，只能从 31 缩到 27，然后就没用了。只靠这个能力位做的对比，本质上是把同一批模型列两遍。
真正决定选择的差异在另外三栏——路由、上下文与输出上限、价格。这一页就按这个顺序讲，因为路由是唯一一个要你改代码的。
三个路由，三种工具结构
目录给每个模型都标了 apiRoute，而支持工具的模型分散在其中三个上。13 个走 /v1/messages：所有 Claude id 再加 stable-gpt-6-astra。6 个走 /v1/responses：gpt-5.6-sol、gpt-5.6-terra、gpt-5.6-luna、gpt-5.5、gpt-5.4、gpt-5.4-mini。8 个走 /v1/chat/completions：grok-4.6、grok-4.5、grok-composer-2.5-fast 和五个 Gemini id。
这些不是表面差别。/v1/messages 上声明一个工具用的是 name、description、input_schema 三件套，鉴权是 x-api-key 加 anthropic-version，max_tokens 必填；/v1/chat/completions 上则是 {"type": "function", "function": {name, description, parameters}}，鉴权是 Authorization: Bearer。工具结果回来的封装也不一样，所以跟着路由变的不只是 model 字段，还有你派发工具调用的那段代码。
对 agent 来说的实际后果是：同一个路由内换模型是改一个字段，跨路由换模型是一次改造。另外记一下 stable-gpt-6-astra 这个例外——它出自 OpenAI 这条线，却走 Anthropic 形状的路由，所以它对 Claude 客户端是即插即用的，对 Responses 客户端反而不是。
# Anthropic shape — claude-sonnet-5 (also stable-gpt-6-astra)
curl -sS https://token-share.app/v1/messages \
-H "x-api-key: $TOKEN_SHARE_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5",
"max_tokens": 1024,
"tools": [{
"name": "get_build_status",
"description": "Return the status of a CI build.",
"input_schema": {
"type": "object",
"properties": {"build_id": {"type": "string"}},
"required": ["build_id"]
}
}],
"messages": [{"role": "user", "content": "Did build 4417 pass?"}]
}'
# OpenAI shape — grok-4.6 (also every gemini-* id)
curl -sS https://token-share.app/v1/chat/completions \
-H "Authorization: Bearer $TOKEN_SHARE_KEY" \
-H "content-type: application/json" \
-d '{
"model": "grok-4.6",
"tools": [{
"type": "function",
"function": {
"name": "get_build_status",
"description": "Return the status of a CI build.",
"parameters": {
"type": "object",
"properties": {"build_id": {"type": "string"}},
"required": ["build_id"]
}
}
}],
"messages": [{"role": "user", "content": "Did build 4417 pass?"}]
}'工具循环会把账单推成什么样
工具型 agent 每一轮都会把累积的上下文整个重发一遍：system prompt、工具声明、之前所有消息、所有工具返回结果。于是输入 token 一步步往上堆，输出大致维持恒定——十步的循环，同一段前缀可能付了十次钱。
这就让输入单价在 agent 场景里的分量远大于单次问答，也让上下文上限直接变成循环长度的天花板。支持工具的这些 id，输入单价从每百万 0.050 美元（gemini-3-flash）起，经 0.075（gemini-3.7-flash-high、gemini-3.6-flash-high、gpt-5.4-mini）、0.20（gpt-5.6-terra、gemini-3.1-pro-low）、0.30（claude-sonnet-5）、0.40（grok-4.6、grok-4.5，单次请求到 20 万 token 起翻倍为 0.80）、0.50（claude-opus-5、gpt-5.6-sol），一路到 Fable 专用通道的 4.00 美元。
另一半是上下文。跑在 grok-composer-2.5-fast 上的循环，20 万 token 就到头；gpt-5.6-sol 是 37.2 万；grok-4.6 是 50 万；claude-sonnet-5 和任何一个 Gemini id 是 100 万。目录里这些模型的缓存读取与新输入分开计价——这个机制存在的理由，恰恰就是 agent 的前缀会不停重复。
怎么挑，以及目录答不了的那部分
按这个顺序过一遍。先看路由，因为它要花的是代码：客户端已经在说某一种结构的话，那这种结构下的候选一开始就占便宜。再看上下文上限，它是循环能跑多长的硬边界。然后看输入单价，因为不断变长的对话记录乘的就是它。27 个里有两个没有 thinking 可花——stable-claude-haiku-4-5 和 grok-composer-2.5-fast——如果推理这件事本来就交给工具做，这是个值得知道的成本属性。
能力位记不下来的是可靠性：模型吐出来的参数格式规不规整、压力下守不守 schema、知不知道什么时候该停手别再调工具了。真正把 agent 搞崩的是这些，而 models.json 里没有哪一栏描述它们。
所以只能测。给两三个候选同一套工具、同样二十个任务，然后去数格式错误的调用、选错工具的调用、停不下来的循环——不要只数成功的。再把每次跑掉的输入 token 乘上各自的单价。一个四轮收工、单价 0.30 美元的模型，完全可能赢过九轮才收工、单价 0.075 美元的模型；不测就不知道是哪一种。