先看证据
把机制串起来
网页代理的账单分两层：搜索或抓取服务可能按请求收费，模型则按读入的网页内容、推理和回答所用的 token 收费。网页越杂、提取越冗长，模型读入的内容通常越多；所以“检索免费”不等于“任务免费”。
流程上，Search 返回搜索结果，Fetch 接收 URL、渲染页面并提取内容，再按 Markdown、JSON 或 HTML 等形式交给后续模型。导航栏、广告和 Cookie 提示等杂项若被清掉，模型需要读的输入就可能更少；但提取过少也可能漏掉正文信息，因此不能只按字符数判优劣。TinyFish 在一个 Daily Mail 页面上返回 4,737 个字符，Firecrawl 返回 171,095 个字符，显示同一页面的提取长度可能差异很大；这只是单页示例，不能外推到所有
['先测目标网站的提取完整度，再估算实际 token 账单。', '高频检索可利用免费额度；留意每分钟及日限额。', '用单页字符数比较时，确认各家都提取了完整正文。', '对延迟敏感任务慎选；TinyFish 榜单耗时偏长。']
免掉检索费，不等于免掉读网页的成本
TinyFish 为 AI 代理提供网页搜索与抓取基础设施，并在 2026 年 5 月宣布 Search 和 Fetch 免费：Search 不按请求收费，Fetch 不按 URL 收费，但两者仍有调用限额。它面向的是代理检索实时网页时的服务费用，而不是代理完成任务所需的全部计算开销。
区别在于，搜索或抓取只是把材料取回来，模型还要读这些材料、推理并生成答案。即使检索费为零，送入模型的网页文本仍会消耗输入 token，后续推理和输出也可能计费。把搜索 API 的单次标价当成任务总成本，会漏掉代理真正“读了多少”。
提取器的输出，决定模型面对多大的网页
Fetch 接收 URL、渲染页面，再把内容提取为 Markdown、JSON 或 HTML；清掉导航、广告和 Cookie 提示等杂项，可以减少进入上下文的无关文本。这不是免费的“清洁”步骤，而是把一部分成本控制前移到检索层：提取器返回得越精简，模型通常就越少处理无关内容。关键仍是不能为了短而丢掉任务需要的正文。
TinyFish 在 2026 年 6 月 2 日对 45 个 URL、5 家提供商按默认设置做了评估。一篇 Daily Mail 文章的正文约 4,300 个字符，TinyFish Fetch 返回 4,737 个字符，Firecrawl 返回 171,095 个，约为前者的 36 倍；Exa Contents 返回 65,793 个，Tavily Extract 返回 46,433 个，Parallel Extract 只有 600 个字符，但那是摘要片段而非整篇文章。这个对照展示了输出体量可能差得很大，却不是跨网站的普遍比例，也不能把片段和全文当作同等提取结果。
按材料采用的粗略换算——约 4 个字符折合 1 个 token，输入价格假设为每百万 token 1 美元——TinyFish 这次输出约 1,184 个 token，输入处理费约 0.00118 美元；Firecrawl 约 42,774 个 token、0.04277 美元。这里只估算这一页的输入处理，不包括检索费、推理和输出；真实 token 数会随 tokenizer 变化。更重要的是，这些字符数来自 TinyFish 自己的评估，适合说明提取长度这一变量，不足以单独证明某家在所有网站或任务上都更好。
长页面会挤占上下文，也会在循环里反复出现
单页输入费用看起来很小，放进长上下文或多步代理流程，账就不再只看一次抓取。材料中的 Firecrawl 单页估算约为 42,774 个 token，相当于 128K 上下文窗口的约三分之一；三页合计约 128,322 个 token，已经超过窗口，还没给系统指令、对话历史和回答留位置。这里假设所有提取内容都原样进入同一上下文，没有筛选、截断或摘要，因此它是压力示例，不是每个代理任务的实际消耗。
代理循环还可能重复发送已有对话。Artificial Analysis 的说明指出，每轮会重发完整对话，先前输入则按模型的缓存输入价格计费。缓存可能改变重复输入的单价，却不等于网页内容没有成本；任务中搜几次、抓几页、是否先过滤再交给模型，都会影响总量。只优化每百万 token 的价格，无法消除多余上下文带来的开销。
基准排名回答的是组合成本，不是单项能力
Artificial Analysis 在 2026 年 9 月 28 日的榜单快照展示了 12 种配置。TinyFish Search（web）得分 71，每千个基准任务成本 9.30 美元，单任务耗时 59 秒，包含模型与搜索时间；在展示的配置中，它总成本最低，但速度是倒数第二慢。Perplexity Search（medium）得分最高，为 80；不使用搜索的基线得分为 33。这个结果呈现的是特定任务、模型和检索配置组合后的成本与表现，不是搜索接口的孤立排名。
TinyFish 的 Agent 使用其面向搜索、检索和实时网站交互的网页原生模型，由 TinyFish 管理模型基础设施，并以云端浏览器处理页面；材料称无需本地 GPU，但 Agent 内置模型不能替换。对团队而言，这是一种以托管和集成换取部署简化的取舍。若工作流必须指定自有模型，免费 Search/Fetch 可作为独立检索层评估；若希望由同一产品承担浏览与模型调用，则要把模型绑定和任务延迟一并纳入比较。
预算应落在任务上，而不是免费标签上
现行定价页列出的标准额度是 Search 每分钟 30 次、每小时 500 次，Fetch 每分钟 150 个 URL、每天 1,000 个 URL；在额度内，检索服务不从 Wallet 扣款。这样的边界对原型和中等流量工作流很有吸引力，但高频任务仍须核对限额，以及超出限额时适用的处理规则。现有材料没有给出越限后的完整成本路径，因此不应据此推断任意规模下检索都免费。
更可执行的做法，是在自己的任务上同时记录检索请求数、返回字符或 token 数、上下文长度、重复轮次、模型费用和完成时间。然后比较“直接把页面交给模型”与“先做正文提取或筛选”是否改变答案质量，而不只比较账单。TinyFish 的单页数据说明了提取层可能带来的杠杆，榜单则说明低成本可能伴随更长等待；最后的选择取决于任务是否需要完整页面、延迟能否接受，以及模型是否必须可替换。