2026年10月9日，Reddit 用户 u/Intelligent-Crew-576 在 r/ClaudeAI 发帖，介绍一款 Claude Code mod。作者称，它用 Haiku 5.5 或 Jev 阅读当前工作和较早消息，为每条提示在 Haiku、Sonnet、Opus 之间挑选模型，并估计 effort 档位；若判断维持当前选择更好，则不在任务中途切换。作者还称，这款 mod 免费、以 MIT 协议开源，安装站为 heycubit.github.io/effortless ，设置分三步。作者写这个工具的原因是自己经常忘记换模型，于是一直开在高档位上跑。
据帖文，mod 会在提示缓存变冷、对话变得拥挤时发出警告。作者称，effort 只是估计，但在其使用中，选出的档位几乎每次都接近自己会手动选的结果。
关于缓存，作者称：在 Opus 和 Sonnet 上切换 effort 不会重建缓存；在 Fable 上会重建，因此那里关闭自动切换，因为改 effort 的花费会超过省下的部分。帖文下由机器人在超过 50 条评论后自动生成的摘要称，mod 会在提示发出前拦截，选定模型和 effort 再发送；用户可以关掉自动模式、改为手动设置。同一摘要称，部分讨论者指出跨模型切换会烧掉缓存，作者则表示 mod 会计算成本，只在仍然更省时才切换。
作者称，运行时的判断由 Haiku 5.5 完成，Jev 是可选项；代码大部分由 Claude Code 写出，作者负责测试、决定功能并修正自己觉得不对的地方。自动生成的评论摘要还称：Jev 稍快、更便宜，Haiku 版更容易设置，因为不需要 API key。摘要中的这些对比并未在帖文正文里展开。
作者称，mod 还提供 smart handoff：若注意到任务发生变化，会给出建议，并允许把用户已有的 skill 当作交接模板。评论用户 touchet29 解释：handoff 为下一次会话生成 HANDOFF.md，或打开菜单、用交接上下文自动启动下一次聊天，当前会话的上下文保持展开；compact 则是压缩当前会话里的上下文。另一位用户 kruszkush25 补充安装最后一步：对话变长时，插件会生成可供粘贴到新对话的 handoff；“Full”是完整版，默认由插件自带的 “effortless (built in)” 撰写，也可以改选已安装的 skill。
用户 BanjoThunderbird 评论称，作者放在 heycubit.github.io/effortless/bench/ 的基准看起来只有 4 个测试任务，他认为远远不够。作者此前回复称自己有一些测试数据，会放到仓库和网站上，并给出上述基准页链接；页面上的具体数字，这篇帖子的可见原文并未列出。BanjoThunderbird 还说，他自己做过按模型（而非按 effort）选择的 Jev 路由器：用自己历史中约 200 个任务，在项目历史的对应提交上用不同模型重放，再加上 1000 多个来自多种公开基准的任务；喂给 Jev 的包括提示文本、git 状态、提到的计划文件和 issue，以及 AGENTS/CLAUDE 等。据他自述，在个人历史上，强/弱模型对的路由相比一直用强模型大约有 15% 优势，但更大的模型虽然更费 token，也常常更快把事做完；在公开基准上，Jev 预测难度与标注难度的相关性约 0.55。他最终没有采用这套路由器，因为自己手动选择的结果更好。这些数字是评论者对自己实验的描述，不是该 mod 的测试结果。
用户 -WhateverDude 认为用 Haiku 当裁判不可靠，低估任务会让人在更弱的回答上兜圈子；又指出缓存按模型区分，升级到 Opus 时整段上下文会按完整输入价重读，而不是缓存价。只切 effort 可以避开这一点，切模型则不能。作者回应称：Haiku 裁判多数时候是对的，猜低时偶尔会得到稍差的回答；它很便宜，且不会超过当前聊天所用的模型；缓存按模型计费，切换有成本，所以只在值得时向下切换；也可以设成只调 effort，或直接关闭。
用户 lordboos 询问终端视图是否可用，因为演示都是聊天视图。作者回复称目前不支持（“not atm no”），正在做。自动生成的摘要还提到，有人表示干脆全程使用 Opus 5.5；作者在线程中回应功能请求（例如更保守的模式）并修过界面问题（例如浅色模式下的可读性）。摘要由机器人自动生成，不等同于作者逐条确认。
