这次彻底死心了，DeepSeek 1017的价格比想象中还狠！

不死心又试了一次，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+OpenCode Go的组合，看看在实际项目中的表现是否有明显差别。

这两天测试下来，我对1017的能力是比较认可的。虽然还不能说它在所有方面都达到了Sol的水平，但至少在我的实际开发任务中，已经相当能打。

现在的问题已经不是它能不能干活，而是怎么才能用得起。

官方说的性能与成本优化，我相信在一些任务中确实能够体现出来。只是对于我这种需要多轮交互、反复修改代码的开发方式，实际费用依然有点高。

看来，Codex+10美元的OpenCode Go还得继续当主力。

毕竟代码是要天天写的，总不能每完成一个功能，都顺手把钱包重构一遍。