That said, I note that the court's opinion specifically calls out Anthropic's practice of *training models on user data* as a reason why the defendant could not have expected confidentiality. I do not use these cloud models for anything important precisely because they are operated by companies, like Anthropic, that are completely untrustworthy.

I don't really see how open-weights models need to borrow any legitimacy. They are valuable artifacts being given away that can be used, tested and repurposed forever. Fully open models like the OLMo series and Nvidia's Nemotron are much more valuable in some contexts, but they haven't quite cracked the level of performance that the best open-weights models are hitting. And I think that's why most startups are reaching for Chinese base LLMs when they want to tune custom models: the performance is better and they were never going to bother with pretraining anyway.

That doesn’t address the practical significance of privacy, though. The real risk isn’t that OpenAI employees will read your chats for personal amusement. The risk is that OpenAI will exploit the secrets you’ve entrusted to them, to manipulate you, or to enable others to manipulate you.

The more information an unscrupulous actor has about you, the more damage they can do.

Viewed another way, the preferential pricing they're giving to Claude Code (and only Claude Code) is anticompetitive behavior that may be illegal.

I'm wondering if some of the disconnect here is that you don't have personal experience with this type of development, so you might not see what pain points it solves.

The first thing I would mention is that components encapsulate function and styling. Buttons don't illustrate this well because they're trivial. But you can imagine a `` that takes a `variant` property ("range" or "single"), `month` and `year` properties, and perhaps a property called `annotations` which accepts an array of special dates and their categories (`[{date: "2026-07-04", code: "premium_rate"}, {date: "2027-07-07", code: "sold_out"} ...]`). The end result is an interactive picker that shows the desired span, with certain dates unselectable and others marked with special color codes or symbols. You're going to have a very unpleasant time implementing that with globally scoped CSS classes.

And this isn't a string sent over the wire. The "document" that the browser renders is changing continuously as you interact with it. If you were to open Chrome Devtools and look at the subtree of the DOM containing the date picker, you would see elements appearing and disappearing, gaining or losing classes and attributes, in real time as you select/deselect/skip forward/etc. That's what makes it work, rather than being a static drawing of a calendar.

I personally do not like the Javascript frontend ecosystem. It's hacks on top of hacks on top of hacks. But, do you know another way to deploy software that's cross-platform and basically free of gatekeepers? Sometimes we just have to do weird things because they're really useful.