Joined 19 years ago
The leak was for something called 'OpenCode Console', which is distinct and separate from the OpenCode coding agent. If you're just using the coding agent, you're not affected. 'OpenCode Console' is a service that is similar to OpenRouter, but is much less widely used.
The name 'OpenCode Console' is super confusing, because one might think it means the CLI coding agent. It does not. 'OpenCode Console' has nothing to do with the CLI/TUI coding agent, nor the desktop app version.
The situation is made worse by the fact that 'OpenCode Console' barely has any documentation online, and the official leak announcement does not make the distinction clear at all. The OpenCode team did a terrible job of communicating this, and that's on them.
Today is a bad day for people using 'OpenCode Console'. But most people, probably the vast majority of OpenCode users who are reading this, are not using 'OpenCode Console'.
But someday, that demand will stop rising.
At some point, most people will have enough RAM. And they just won't need to buy more.
The inventories of RAM will become overfull, in warehouses and stores. And suddenly the manufacturers, middlemen, and even retailers will all find the price they can sell at keeps dropping.
But you can't shut down a huge manufacturing facility overnight. You can't shut down a years-in-the-making retail distribution system overnight, either. You can't even shut down a facility that is halfway finished with construction. They'll keep producing and selling RAM at lower and lower profit margins, until the day comes they finally accept they're losing money with each sale.
And when that happens, we'll all have more RAM than we know what to do with. It'll be cheaper than we have all ever experienced in our lifetimes.
I don't expect this to happen soon. But demand cannot keep exponentially rising forever. There will come a point, probably in the next 5 years, when demand at least levels off, even as production capacity is still rising.
And it will be interesting to see what's possible at that point. We'll be able to create software that is not doable right now, because it will no longer be constrained by memory. And even cheap laptops will massive amounts.
WTF.
My favorite so far is the "Iff Specs Disk", with technical documentation on an ancient container and data format called IFF (Interchange File Format).
Like in the file ea.iff.85 [0], and this section explaining why common data file formats are useful the first place:
"The problem with expedient file formats - typically memory dumps - is that they're too provincial.
By designing data for one particular use (e.g. a screen snapshot), they preclude future expansion (would you like a full page picture? a multi-page document?).
In neglecting the possibility that other programs might read their data, they fail to save contextual information (how many bit planes? what resolution?). Ignoring that other programs might create such files, they're intolerant of extra data (texture palette for a picture editor), missing data (no color map), or minor variations (smaller image).
In practice, a filed representation should rarely mirror an in-memory representation. The former should be designed for longevity; the latter to optimize the manipulations of a particular program. The same filed data will be read into different memory formats by different programs."
Imagine having to explain to a professional developer today why having something like JSON is valuable. Most of us find it obvious.
But there was a time when this kind of thing was not obvious at all; the need for it had to be discovered the hard way, and then solutions invented from first principles.
We really are standing on the shoulders of those who came before us, in more ways than we realize.
[0] https://amigafreeware.downer.tech/17bit/17bit/61/contents/if...
