不死心又试了一次，DeepSeek 1017终于让我死心了 DeepSeek-V4.1-Flash-1017（以下简称1017）的能力确实在线。这两天测试下来，至少在我自己的项目中，感觉已经有点GPT 6.1 Sol的水平了。 但是， 直接用官方API，这个价格实在有点扛不住。 昨天用DSH跑了一个模块重构，花了4.6元。虽然觉得贵，但考虑到涉及的代码量比较大、上下文也比较多，倒也勉强接受了。 今天还是不死心，决定再试一次。 这次特意选了个相对简单的任务：使用frontend-design这个Skill完善一个界面，顺便调整一处业务逻辑。 整个过程也比较常规，一轮主要开发，加上三轮微调。1017的表现依然不错，需求理解、界面调整和业务逻辑处理都比较到位，最终成果我也挺满意。 先看看DSH的使用统计。 这次任务累计执行了302步，发起303次API请求，消耗约8684万Token，缓存命中率高达99.7%。 看到这里，我还是有点吃惊。 这么一个界面调整，居然跑出了将近8700万Token？ 当然，绝大多数都是缓存命中的Token，实际重新处理的内容远没有这么多。但缓存命中不等于免费，调用次数一多，上下文反复传递，费用照样会往上涨。 然后打开DeepSeek后台看了一眼，心里凉了半截。 5.2元！ 昨天一个相对复杂的模块重构，花了4.6元。今天这个明显更简单的任务，反而花了5.2元。 两天加起来已经9.8元了。 说实话，按我平时使用Astra的体验，处理这种任务都不至于让我这么肉疼。当然，订阅额度和API按量计费不能直接比较，但这消耗确实超出了我的预期。 这简直太 梁子 了！ 而且，DeepSeek这次发布1017的时候，还专门提到了降低使用成本。 我又去翻了一遍10月17日的官方更新日志。 官方说，新版本在提升性能的同时，还缩短了任务运行时间和输出长度，让用户能够以更低的成本、更快的速度完成任务。甚至特别提到针对DeepSeek Harness等框架进行了优化。 好家伙，看到这里我就更纳闷了。 官方说任务成本降低了，我怎么感觉账单反而越来越高了？ 不过仔细分析，这里有两个问题。 首先，1017并没有降低API的Token单价，而是通过减少输出和运行时间来降低完成任务的总成本。这是两个概念。 其次，不同任务的Agent执行过程差异很大。即使任务看起来更简单，也不代表Token消耗一定更少。尤其像界面调整这种任务，模型需要反复阅读代码、修改、检查，多轮下来，费用可能比一次规模更大的重构还高。 还有一个容易忽略的因素，就是DeepSeek的峰谷计费。 昨天是周日，全天享受空闲时段半价。而今天是周一，属于正常工作日。 根据DeepSeek的官方价格说明，北京时间工作日9:00—12:00和14:00—18:00属于高峰时段，价格是空闲时段的两倍，其他时间依然享受半价。 今天这个任务正好跨越了午休时间。 截图里虽然分成了几个时段，但其实就是一个任务。中午正好卡在一个需要我确认的地方，于是先去吃饭、午休，回来以后继续，直到基本完成。 之前我还在想，难道DSH跟出租车一样，还有等待费？ 现在看来，等待费倒是没有， 但工作时间的高峰价确实可能让我多花了钱。 当然，目前没有按照调用时间和Token明细逐项核算，所以也不能把今天比昨天贵的原因全部归结于峰谷计费。 只是这么一来，昨天4.6元、今天5.2元的差别，就没那么奇怪了。 不过，即使考虑峰谷价格，我还是觉得这个消耗偏高。毕竟1017宣传的是更高的任务效率，而在我这两天的实际使用中，省钱的感觉暂时还没找到。 到这里，任务其实还没有完全收尾。 不试了，直接把DSH切换到OpenCode Go套餐继续干吧。 否则照这个趋势，最后能不能突破10块钱，还真不好说。 好在DSH已经内置了OpenCode的接入支持，配置起来非常简单。只需要在模型提供商中选择OpenCode Go，然后填写自己的API Key即可。 配置完成后，在DSH的对话窗口中就可以选择OpenCode Go套餐里的DeepSeek V4.1 Flash模型了。 不过，这里还有一个让我比较纠结的问题。 直接使用DeepSeek官方API时，模型名称后面明确带有1017后缀。而OpenCode Go里面只显示DeepSeek V4.1 Flash，没有1017。 那么，OpenCode Go现在究竟路由到的是老版本，还是最新的1017？ 目前还没有找到OpenCode Go对此的明确确认。GitHub上也有人专门提出了这个问题，要求OpenCode公开实际使用的模型版本，但暂时还没有得到明确答案。 这就有点难受了。 毕竟我就是冲着1017的能力来的，如果切换到Go套餐后又用回旧版本，那就有点得不偿失。 所以接下来准备继续使用DSH+Ope