Jury Rejects Musk's Claims Against Altman as Anthropic Seizes OpenAI's SDK Tool

01The jury needed two hours to reject every Musk claim against Altman

After roughly two hours of deliberation, the jury in Musk v. Altman returned a unanimous verdict against the plaintiff. Elon Musk lost on every count.

Two of Musk's claims against Sam Altman and OpenAI were barred by the statute of limitations, according to The Verge's coverage of the proceedings. A third claim collapsed because it depended on one of the dismissed ones. The jury was only advisory. The judge can still chart a different course, but a unanimous two-hour verdict gives the bench little reason to.

The trial had been billed as the tech case of the year. Musk, who helped found OpenAI in 2015 before exiting the board, argued that Altman should not direct the future of artificial intelligence. Altman's lawyers spent their time attacking Musk's own credibility. The deliberation length suggests the jury found the contest unevenly matched.

Stripped of the legal scaffolding, the case was a fight for control. Musk wanted a court to declare that the CEO of OpenAI had no right to lead it. The jury declined to oblige him.

The Verge used the moment to argue something more uncomfortable: that the lawsuit "proved that AI is led by the wrong people." The publication's framing rests on a simple fact. Two of the most influential figures in commercial AI spent weeks in a San Francisco courtroom litigating personal grievances dating back nearly a decade. Neither emerged looking like a steward of a technology they both claim will reshape society.

Altman keeps his job and his company. OpenAI continues to operate under the restructured nonprofit-and-capped-profit arrangement Musk spent two years trying to unwind. Musk's own AI venture, xAI, will continue competing in the market rather than the courtroom.

The advisory finding now goes to the judge for formal entry. Musk's legal team has not indicated whether it will pursue further claims in state court, where some of the dismissed allegations could theoretically be refiled. The federal chapter closed Monday. OpenAI's governance structure stands as Altman built it, and Musk's path to a different outcome now runs through state court or appeal.

02Anthropic now owns the tool OpenAI uses to ship its SDKs

Anthropic has acquired Stainless, the four-year-old New York startup that automates SDK production for OpenAI, Google, and Cloudflare. Terms were not disclosed.

Stainless, founded in 2022, sells infrastructure that generates client libraries directly from a vendor's API schema. Hand-written SDKs lag behind API changes and accumulate bugs across languages; generated ones stay in lockstep with the spec. The startup rose to prominence in the AI industry on that pitch, according to TechCrunch, picking up the largest, fastest-moving APIs as clients.

The customer list is what makes the deal unusual. OpenAI, Google, and Cloudflare all use Stainless to maintain their developer SDKs, according to TechCrunch. A company whose job is keeping three frontier-model APIs in sync with their developer surfaces is now a wholly owned unit of a fourth.

Anthropic said Stainless will continue to operate as a product and existing customers are expected to remain on it. Neither announcement addresses how roadmap decisions will be made now. Stainless will be choosing whose new API features ship first, whose get full language coverage, whose bug reports get prioritized. Those calls previously belonged to a neutral vendor selling identical service to all three frontier labs. They now sit with a competitor of its three largest customers.

The deal extends a recent string of Anthropic moves aimed at the layer between model and developer. That layer includes the SDKs developers import, the IDEs they code in, and the agents they run on top. SDKs sit closest to API revenue, since every paid call begins with one. Whoever maintains them shapes how easy a given model is to call and how quickly new features reach production code.

Whether OpenAI or Google will keep paying a direct competitor for SDK infrastructure, or rebuild it in-house, neither announcement says. The Hacker News thread on the announcement drew 308 points and 221 comments.

03Two HN front-page essays this week gutted the "buy AI, ship faster" pitch from opposite sides

Two essays attacking the same enterprise AI sales pitch from opposite sides hit Hacker News's front page within days this week. "I don't think AI will make your processes go faster" pulled 653 upvotes. "AI is a technology not a product" pulled 456. The pitch under fire: that paying for AI tooling translates directly into productivity gains.

The first essay attacks the throughput math. In most software organizations, writing code is not the slow step. Review queues, design decisions, QA cycles, deployment gates, stakeholder approvals — those eat the calendar. Compressing the coding step from two days to two hours leaves end-to-end shipping time roughly unchanged, because the coding step was never on the critical path. A 10x speedup on a non-bottleneck rounds to zero in delivery timelines.

The second essay reframes the category. AI is a technology layer in the same sense SQL databases and TCP/IP are technology layers. Companies don't sell databases to consumers; they sell applications built on top of one. Pitching "an AI product" to end users mistakes infrastructure for a product category, and the buyer ends up paying for capability without a problem attached.

The arguments converge on a procurement question most enterprise AI evaluations skip. One frames it as: where is the actual bottleneck in this workflow, and does the AI tool touch it. The other frames it as: what application sits between this AI capability and the outcome we want. Neither author is an AI skeptic. Van Brabant ships software for a living and writes from inside that workflow. Gruber has covered Apple for two decades and writes closer to product strategy than to engineering process.

The two essays don't reference each other. They share a procurement target: the equation that a license fee plus a vendor demo plus a rollout plan equals productivity gain. Van Brabant denies the equation by moving the rate-limiting step elsewhere in the workflow. Gruber denies it from a different direction: what's labeled "the product" is in fact infrastructure, with no application built on it.