Deepseek never subsidized their plans. At some point they dropped pricing, then after a while they raised them, but that's because they had capacity issues, not because of dropping subsidies. They don't want your money, they'd rather have fewer users.
OpenCode is building their own inference and they've independently stated that DeepSeek's old (cheaper) pricing is achievable without subsidies.
Because models are only getting better at a rate of 10% per year, people always want the best quality possible. You can get SotA performance from a year ago for a fraction of the cost, but why would you use Opus 4.5 when you can use Opus 5.5?
Reddit is full of people complaining how they burn their 200$ sub in half an hour by starting ten Max sub agents. That’s to say, many people just don’t know what they’re doing.
To pay for the training of the models which are getting bigger and more expensive. So intelligence is getting cheaper overall but the need for ever-increasing intelligence can't be sated.'
I wish this is true but evidence is against you. Just try testing memory pressure on a no swap system. You will see that the system grinds to a half for a few minutes before you even get to an OOM event.
Could you clarify what exactly is "not true"? Also, could you explain what exactly your evidence proves? What do you think happens when the system becomes unresponsive under memory pressure, and why?
> The active code pages are specifically excluded from being discarded during the reclaim process.
This is not true, or the system wouldn't grind to a halt due to having to reload code pages (even those that are recently in use) from disk over and over.
For example, key presses and output streaming in SSH become unresponsive. The code pages for handling key presses and output streaming are obviously in use — I just used them!
I'll try again. Why do you think that unresponsiveness is caused by code pages being discarded? Do you have evidence for this? Have you considered that there are other mechanisms that cause programs to become unresponsive under memory pressure?
It's the explanation that I've read when scouring forums for reasons why it happens. I'd love to hear alternative explanations and how to measure/verify them. But the measurement tools also become unresponsive so I can't check anything.
But frankly, as a user I don't really care what the real technical reason is. I just don't think the system should become unresponsive for minutes on end during memory pressure. Just OOM-kill earlier, when it's supposed to.
The assumption that a system gets unresponsive due to code pages being reclaimed doesn't make any sense. It is a common myth, cargo-cult knowledge. The kernel doesn't discard any active referenced pages at all, and the active code pages are the last that are getting reclaimed.
The proper explanation is relatively straightforward. Normally, any memory request for a process is served by getting a page from the free memory pool. But when the system free memory goes below the low watermark (calculated from vm.min_free_kbytes and vm.watermark_scale_factor), the kernel stops giving the pages from the free memory pool and instead goes into direct reclaim, trying to find unused pages. While the kernel does reclaim, the allocating process remains stalled. The kernel can't return control to the process - there is no page mapped that the process tried to access. This applies to any types of pages - anon, file-backed, code pages. So, under the condition of free memory below the low watermark, any process trying to allocate memory gets stalled. This is measured as memory pressure stalls (PSI) in /proc/pressure/memory.
The problem with the system being stuck in an unresponsive state is that the design choice for the kernel OOM handling is to be optimistic and keep the workload running as long as the kernel is making any progress reclaiming pages. The direct reclaim process needs to fail to make any progress 16 times before the OOM killer is invoked.
The solution is to use cgroup memory limits to avoid getting into the situation of memory exhaustion and use user-space oomd to recover from this situation earlier.
So you're saying processes are stuck for minutes on end at trying to get memory from the kernel? I find this implausible because relatively simple processes such as ssh and bash shouldn't be getting memory from the kernel at a continuous basis. Unless they're suddenly processing a lot of new data (like me trying to cat /dev/urandom), they should be spending most of the time working with the memory they already have. Especially when all I'm doing is pressing keystrokes in ssh+bash, not even hitting enter. Note that malloc doesn't ask memory from the kernel at every call. Glibc malloc is (in)famously stubborn with caching memory it has gotten from the kernel, hesitant to release it back to the kernel.
Any repeatable way to prove your thesis or disprove the trashing-code-pages thesis?
You seem to confuse user-space memory allocations (malloc) with the kernel memory page allocation and mapping. The processes don't need to allocate any new memory with malloc. They get stuck when accessing memory that is not mapped to a physical memory page or when they enter a syscall that needs in-kernel memory allocation.
Ok fine. But again: any repeatable way to prove your thesis or disprove the trashing-code-pages thesis? And how to do this when the system is freezing up?
I have already pointed you to /proc/pressure/memory. Prometheus node_exporter tracks it as node_pressure_memory_waiting_seconds_total and node_pressure_memory_stalled_seconds_total. You'll see them spiking when you experience stalling.
You can also track variables from /proc/vmstat exported as node_vmstat_allocstall_(normal|dma32|movable), node_vmstat_pgscan_direct, node_vmstat_pgsteal_direct - you'll see them spike when the system enters direct reclaim.
Install and configure systemd-oomd and track its log - it will activate on memory pressure.
To track code page eviction/re-faults specifically, you'll need to write some eBPF code, there are no direct measurements for this available.
While I've seen systems grinding to a halt due to evicting code pages, the idea that disabling swap distributes load between code pages and data pages makes no sense to me. Data pages are also disk backed, so they could also be evicted at any time. Why would data pages be written to swap if they came fron the disk in the first place?
So that only leaves anonymous data pages, i.e., regular data in memory, that could be swapped. Ok but you're not easing the load on code pages, those still get evicted during memory pressure whether you have swap or not.
The assumption that data pages can always be easily discarded is incorrect. Dirty data pages can't be discarded until they are written back. Recently accessed data pages are also not discarded until all inactive data and code pages are discarded.
I heard that is mostly a myth due to misunderstanding what life expectancy means. It's an average over populations, pulled down mostly by enormous infant mortality. If you made it to 15 then there was a good chance you'll make it to 60.
I find Luna vs Terra more clear. I know what a haiku is only because it hss some sort of hype factor among certain crowds. But I have no idea what a sonnet is, I heard of the word but never seen or written one. Opus vaguely reminds me of something in Greek mythology but also no idea what that, let alone the apparent implication that it's supposed to be longer than a sonnet.
I find those (Italian?) names super confusing as a non-Italian. I automatically read "tall" in English and think "ok it's tall as in high so this gotta big" -> "wait, what is 'grande' then and how is that different from tall?" -> "venti? Genshin Impact character??"
Of course the point of their joke is that those are super confusing too.
But the origin is size inflation. The original Starbucks sizes were short and tall. Shorts are still available, in at least a few outlets, despite having not been on the menu for at least 20 years. (For a while a few years ago here in the UK, I even saw short as a column on the menu at one, but that's very rare.) Then they added grande, literally meaning large but maybe meaning more like "extra large". Then when they added an even bigger size, since large was already taken, they just stated the actual size "venti" = 20 (fluid ounces).
(The first time I ever went to a Starbucks had the same confusion as you. I didn't know what an espresso was but at least its sizes of "single" and "double" were easier to understand, so I got a double and was a bit surprised at how small my drink was!)
? Footguns as a synonym for "caveat" or "gotcha" were in use long before LLMs. I hate Claude speak too but there's no need to knee-jerk blame everything on LLMs.
While that is true (the LLMs surely had to learn it from pre-existing content), I think it's been so thoroughly overused and turned into a cliche that the term has been ruined for the foreseeable future.
Going faster... until now. It's screetching to a halt. And they want us to get off gas in a few years while also being unable to handle the electrical load. I'm gonna buy a gas boiler thank you very much.
China's plan to be self-sufficient in semiconductors was a failure before western sanctions, because all the Chinese chipmakers found it too easy to buy western chipmaking equipment or to fab through TSCM. No Chinese company wanted to buy from other Chinese companies. Nobody was incentivized to develop self-sufficiency. "Because the government wants it" was not enough incentive.
Western sanctions have succeeded in achieving China's self-sufficiency goals where their own government failed.
OpenCode is building their own inference and they've independently stated that DeepSeek's old (cheaper) pricing is achievable without subsidies.
reply