Astral joined OpenAI, LiteLLM got popped, OpenCode topped HN, and httpx just got forked.

Changelog NewsDeveloper news worth your attention

Adam here! 🌴

Friends I’m hot off of an epic Spring Break. You know, I’ve never taken a true Spring Break vacation. Sure, I’ve done some things, but never an epic trip to South Florida like we did this time. It was much needed time with family, friends, and…good sleep.

Sadly, while away, Chuck Norris passed away. He was a high-achieving person in life and someone worth emulating. He has 10 principles to live by. Here are two of my favorites.

  1. I will forget the mistakes of the past and press on to greater achievements.
  2. I will always remain loyal to my God, my family and friends, and my country.

Ok, let’s get into the news.


😳 Astral has been acquired by OpenAI

This is a big one. Astral, the company behind uv, Ruff, and ty, says it has entered an agreement to join OpenAI as part of the Codex team. And I think the reason this hit so hard is that Astral is not some random AI startup getting acqui-hired. These are already some of the most important tools in modern Python development.

So the obvious first question is: what happens to the tools? Astral says the open source work continues after the deal closes, and that matters a lot, because uv and Ruff in particular are not side projects anymore. They are foundational pieces of a lot of Python workflows now.

If we zoom out, the bigger revelation is the center of gravity for developer tools keeps moving toward the coding-agent stack. Astral started out making Python development dramatically faster and cleaner. Now that same team is heading into Codex. That tells you where they think the highest leverage work is next.

And if you are a Python developer, or honestly any developer paying attention to tools, this is one of those moments worth clocking. Because it suggests the future is not just better linters, better package managers, better type checkers as separate things. The future is those tools getting pulled closer and closer into the agent itself.

⛓️‍💥 LiteLLM compromised by supply-chain attack

LiteLLM 1.82.8 was reported to include a malicious .pth file that could execute on Python startup and potentially steal secrets from machines that installed it. Attackers published a fake LiteLLM 1.82.8 release directly to PyPI, outside LiteLLM’s normal GitHub release flow.

The current public explanation for how it got there is the real story. LiteLLM says a publishing token was exposed through an unpinned Trivy security scan in CI. This was not just one bad package upload. It was a supply-chain chain reaction: compromised security tooling, stolen publish credentials, then poisoned releases pushed straight to PyPI.

LiteLLM is not some random edge dependency. For a lot of teams it sits in the middle of their AI stack, routing model calls and living right next to API keys, cloud credentials, and internal config. And .pth is a nasty delivery mechanism because it can execute when Python starts, before anybody even imports the library.

If you installed the affected versions, treat this as an incident, not an upgrade bug. Check where it ran, rotate anything exposed, and look at CI and developer machines first. The takeaway is the AI middleware layer now belongs inside your real supply-chain threat model.

🧯 OpenCode tops Hacker News

OpenCode blew up this week as the highest traction new coding agent launch on Hacker News. OpenCode is an open source attempt to build the full coding agent surface area: terminal, IDE, desktop, multi-session workflows, LSP support, with bring-your-own-model flexibility.

The uncomfortable signal is in the timing. Right before OpenCode hit number one on HN, the project had to strip Anthropic OAuth and Anthropic references after legal pressure. If you’ve been on X lately, you’ve likely heard about this Claude OpenCode drama. This should tell us the open agent race is real, but it is still happening inside ecosystems controlled by model vendors.

So my read is that OpenCode matters less because it is definitively the best agent today, and more because it shows where this market is going next. The next fight is not just over model quality. It is over who owns the interface, the workflow, and the default home for coding with agents.

🦀 Rust has challenges, but we can address them

Good state-of-the-language piece: compile times, borrow checking, async, ecosystem maturity.

The Rust project published a reality check. This is not a “Rust is doomed” post, and it’s not a victory lap either. More like: we talked to a bunch of people, and yes, the problems you already think Rust has are in fact the problems people keep running into.

The interesting part is the shape of those problems. Compile times are still a thing, but they’re not really hard blockers for most people. The borrow checker is still brutal for beginners, but it bothers experts a lot less, which tells you some of that pain is onboarding pain, not necessarily evidence the language is broken. Async is still messy in the way Rust async has been messy for a while, except here they are pretty explicit that there are actual next steps they think can help.

Then you get to the ecosystem story, which is maybe the most important one. A healthy crate ecosystem is one of Rust’s strengths, but people still do not always know which crates to trust, which ones are effectively standard, or whether the thing they need exists yet in their domain. In worlds like embedded, GUI, and safety-critical work, that maturity gap gets a lot more obvious.

I applaud this post and the intent behind. I use Rust daily. I’ve felt this pain. Sure Rust can be improved. But this shows the project is listening and it shows they have clear plans to smooth out areas where there’s friction.

💰 AuthKit brings modern auth to the CLIThanks to WorkOS for sponsoring Changelog News

AuthKit from WorkOS is already a pretty compelling pitch on the web: hosted auth with the enterprise stuff developers actually end up needing, like SSO, MFA, passkeys, social login, and all the usual user-management plumbing. I’ve been using WorkOS for auth for my CLIs. Your CLI kicks off auth, shows the user a short code and a URL, and the user finishes sign-in in the browser through the same trusted AuthKit experience they already know from the web app.

That matters because CLI auth is usually where developer experience and security fall short. Too many tools still fall back to long-lived API keys, awkward copy-paste flows, or weird credential storage stories. AuthKit’s CLI flow is a much cleaner model: the app requests device authorization, the user confirms the code in the browser, and the CLI polls for tokens without ever asking the user to jam secrets into a config file. And because this rides on AuthKit, you also inherit the good stuff like MFA, SSO, and standard session controls. If you’re building developer tools, internal CLIs, or terminal-first products, this is exactly the kind of boring-but-important auth infrastructure you want somebody else to get right.

⚠️ Learning to code by building TurboTax

Ryan Lizza got annoyed enough with TurboTax and the larger tax-filing mess that he used AI coding tools to build a free open source alternative and then put it in public so tax professionals and actual programmers can inspect it.

The question is not whether AI can spit out code anymore. We are past that. The better question is whether these tools are good enough to help somebody take a real run at expensive, boring, incumbent software that normal people actually depend on. Tax software is a great test case because it is high stakes, full of edge cases, and usually not something you can fake your way through with a polished demo.

Ryan is not asking for trust. He is doing the opposite. He is saying, here’s the app, it’s open source, go vet it.

This isn’t about a journalist suddenly becoming a 10x tax software engineer. It’s whether or not AI lowers the cost enough for we the people to build credible public interest software in markets that used to belong entirely to incumbents.

💥 Why I forked httpx

This is one of those open source stories that sounds niche until you realize how much code quietly depends on it. httpx is a very popular Python HTTP client, and Michiel Beijen has now forked it into httpxyz because there has not been a release since November 2024, fixes were sitting around unreleased, and upstream trust has been eroding.

The real story is not just that somebody got frustrated and made a fork, the issue is project maintenance risk eventually turns into dependency risk. In this case, the fork author points to hidden issues, discussions being turned off, years of talk about a future 1.0, and a growing sense that a widely used package did not have a stable maintenance path anymore.

httpx is not some obscure utility. It sits underneath a lot of Python software, and even high-profile packages like OpenAI’s and Anthropic’s Python SDKs have already been guarding against a future 1.0 release.

The fork’s pitch is the interesting part. Not a rewrite, not a revolution, just a stable fork with the motto “move a little faster and not break things.” That is a pretty good summary of what a lot of developers actually want from infrastructure dependencies. Not novelty. Just a maintainer story they can trust.


✅ BONUS (un)ordered list

Laters!

-Adam