Just received an email from Deepseek. They plan the full release of V4 for mid-July, so in two weeks or so, and have announced peak pricing increases as follows:
Peak hours (in UTC): 1:00–4:00 AM and 6:00–10:00 AM.
The prices will double for both the flash and pro models between those time spans:
The new pricing will be locked in 24 hours before it goes live; we have no date yet.
V4 is technically still in preview, so a 'final' V4 likely means it will improve on the benchmarks.
But if you're concerned about the new pricing, I made an opencode plugin to notify you when either you or your agent are entering peak pricing windows. It's on my codeberg here: https://codeberg.org/CritBase111/opencode-plugins-skills, in the plugin folder look for deepseek-peak-pricing.ts. Drop it into your own opencode plugin folder and it will automatically apply upon restarting opencode. Path differs depending on your OS.
Plugin should be able to work on all platforms, it's just that it's mostly integrated into Linux. But if you use it on Windows, it should do its job still at least in some 'routes'. Otherwise, hey, you're using opencode already - just ask your agent to edit the plugin for your machine haha.
At the top of the .ts plugin file, there is a ROUTE variable. You can change its values to select which behaviors you want. It's all explained in the file. One of the options is cold-turkey API quit, meaning no API calls will go through when you are in peak pricing.
NOTE: peak pricing has not entered into effect yet. If you have credit on the API platform, you will be notified when it does. The peak pricing plugin is therefore useless until that time, but will still work as if peak pricing was in effect. If deepseek changes its peak pricing windows, you will need to change the constant array at the top of the plugin file.
Btw, Not to toot my own horn but a 'lower' workflow (one without so-called 'vibecoding') would have likely just stopped at one behavior and not tested for cross-platform or edge cases.
Because you gain more time somewhere (typing out the code), you can apply it somewhere else (architecturing/designing the app).
Multiple 'routes' as I call them and making this cross-platform was not something the AI suggested, I had to tell it to do it this way.
It's still a huge time saver. From the moment I saw the email to the moment I finished writing the code you see on my repo, it took maybe 30 minutes if I'm being generous. I also took a detour to write down for my next agents how opencode plugins work, what they allow you to do and not do, etc. That way it doesn't have to explore the source code and documentation every time I want to edit a plugin any more.
And now I have a peak price catcher, which didn't exist before.
I tried deepseek vibecoding for the first yesterday in mimo code because mimo's free tier wasn't working for me. I want to work on a dead Android app. First think I did (for no good reason) was to upgrade the gradle and AGP versions. Safe to say that there is no way I could do it on my own. gradlew's error messages are 90% useless noise which exacerbated my ignorance of Android development.
I tried the flash model first thinking that a routine upgrade like this would be easy for an LLM which knows way more Android than I do but it kinda failed horrifically. The pro model though did a great job. But the problem is I can't tell if the approach is correct because I lack the knowledge to review it.
It may be possible that deepseek flash doesn't play well with mimocode. Mimocode is a fork of opencode on top of which they added their own particular features, I definitely noticed extra token waste on mimocode even just using mimo itself.
I tried opencode yesterday. It definitely uses a lot fewer tokens than mimo but I felt mimo was performing better? Idk it's hard to tell. Anyway I'll stick with opencode for now.
Give Reasonix or Pi a try too, I had better results with the latter at least. Cache hit rates with opencode + D4 ain't that great either, which the DeepSeek API pricing is especially sensitive to.
mimo has some nice things going to make the model more performant in code, personally I had mimo (the model) in mimocode adapt its Compose agent and its compose-skills for my opencode. That way I can get the test-driven development, brainstorm etc skills with deepseek in opencode, because I agree mimocode wastes tokens for marginal gains. They're just files mimo has to adapt and copy over to your opencode btw, it's very extensible.
