They almost certainly already make a fuckload more money off API pricing than they do subscriptions, even if there might be more total subscription users. So offering subscriptions even at some loss is probably going to continue. Honestly, I'd be surprised if they even lost money on most subs; there are definitely Token Whales out there who mess up all the accounting up, though.
Realistically I think Anthropic just has insane demand but finite capacity to run models, and Fable will just make them more money if they dedicate it to API pricing. I suspect the goal here is something like: get individual engineers/PMs on their personal plans to taste Fable and then go to their meetings and say "Yes doubling the price of every single input/output token is a good idea, boss".
But how is this sustainable? It's not like paying $5000 per feature means you'll be refunded if prompting "make no mistakes" didn't work.
The only reason why I pay $200 is because LLM's errors costs me that much, at worst. If "make no error" starts working - sure. But surely, unless you have millions of dollars of cash to burn, a coin flip that costs $5000 is an insane idea?
I suspect it's a long tail sort of thing; it mostly doesn't matter except when it really matters. It's interesting that the stated motivation for the patch is in the context of agentic tools spawning subcommands. There's some related prior art in this area where the payoffs could be much greater, like fuzzing: https://gts3.org/assets/papers/2017/xu:os-fuzz.pdf is an example. It would be very interesting to see this patch applied to e.g. AFL++
This paper is great and I also really like one of its references [29] as it goes into some more subtle parts of scalable interfaces, including fork. It's a gem IMO: The Scalable Commutativity Rule: Designing Scalable Software for Multicore Processors https://people.csail.mit.edu/nickolai/papers/clements-sc.pdf
> That's my impression from that sentence, at least. Don't you agree?
No. Given a choice between doing laundry and driving Lamborghinis, I would probably choose the latter. But I still have to do my laundry. I might use a washing machine to do so. It's just a responsibility among many responsibilities. It isn't that deep, really.
The reality few people want to admit is that maintaining open-source software is often closer for many people to "doing laundry" than like, being the software equivalent of Atticus Finch.
> Or did Claude just gave some basically retired programmer, who doesn't even want to work on his project anymore,
The only thing Claude has "done" apparently is give a bunch of annoying people online a license to engage in armchair psychoanalysis of someone they don't know at all, from what I can tell.
The GB10 itself is pretty good and I love using mine for broad Linux development. But it's too expensive for consumer level pricing, and even for the "prosumer" the price is pretty stiff. Even if they dropped the CX-7 and halfed the RAM and shipped a smaller hard drive, would it be below, say, $2500 USD? I guess we'll see, but this variant is coming out pretty late so maybe it's just best to wait for the 2nd generation.
This feels like getting a foot in the door to ensure Apple doesn't entirely eat Nvidia's lunch if AI inference workloads start to shift from cloud to local.
With MLX, Apple is building an answer to CUDA, and if people start switching from ChatGPT & Claude to some app that runs on their M5, suddenly Apple starts to look like Nvidia's biggest competitor.
If Nvidia doesn't have a pathway towards getting hardware into the hands of consumers, it could be a really difficult road ahead for them.
Apple seems to still own the creative space. If those tools are able to run local models for any AI workflows suddenly anthropic/etc could lose a massive segment. Or at least demonstrate to others wanting a slice of the cloud AI profits it can be done.
I'm here for it. Local models can do a lot of what I need at almost no cost, plus the fun of making them work better or building a new system to handle that aspect of my home lab. A Strix Halo system may not be amazingly fast but at 128gb of RAM it can keep up with most open models worth exploring.
Based on June 1 Copilot Pro plan premium token burn and cost, unless you REALLY know how to use cloud AI efficiently and are tooled up to do so a local LLM on hardware you may already own is very appetizing.
I converted a lot of work today to a 6.5gb local LLM on a 12gb GPU and no, it's not as good. But it is 'free' or at least feels that way, especially when I need to redo something and my copilot premium request % doesn't change.
Imagine something like writing a server with an /metrics HTTP endpoint that Prometheus can then scrape -- but you bind it on separate port only inside a tailnet, with an ephemeral tailnet key and name it "metrics-service-blahblah".
Now you can simply write a script that uses the tailscale API to find all "metrics-service-*" nodes in your tailnet, and then adds their IP/DNS to your prometheus scraping list. Run it every 60 seconds. Done, now you can just deploy your app anywhere on any cloud and it will get scraped and that route will never be exposed to the outer internet.
This will basically just let you attach bespoke applications and not just "computers" to your network. I suspect I will get a lot of use from it.
Tailscale and Wireguard are great. I'm an OpenZiti maintainer and I've written/spoken about application embedded zero trust for many, many years. Still it seems most devs don't think it's important for whatever reason... It'll make me happy if Tailscale is successful here and can spread the word out to get more devs interested in embedding the secure connectivity directly into the apps instead of relying on the classic underlay network and bolting on security. If that sort of thing interests you, you could check out OpenZiti. It's not Wireguard-based for better or for worse you can decide (if you do end up checking it out)
Yes, almost all JJ users do this constantly. Just "track" the particular branch. JJ has an idea that only some commits are immutable, the set of "immutable heads", and the default logic is something like "The main branch is always immutable, remote branches are immutable, 'tracked' remote branches are mutable." In other words, tracking a remote branch removes it from the set of immutable heads.
Jujutsu is not "VC funded". But some of the developers, including me, work at East River Source Control (I worked on Jujutsu before that, too). The majority of the code in the project doesn't come from us -- or Google, for that matter. We don't allow people to approve patches when the author is from the same company, anyway.
jj is not "one guy who works at Google" and the vast majority of submitted code comes from non-Google developers. Even if Google were to stop developing jj (they won't) the project would be healthy and strong.
There's some legal annoyances around e.g. CLA which was a result of being a side project of Google originally. Hopefully we'll move through that in due time. But realistically it's a much larger project at this point and has grown up a lot, it's not Martin's side project anymore.
Part of the reason Astral as a team is so well liked is precisely because they are not part of the main fold or related to "Core Python"; they are an independent vendor, one that delivered high quality code and listened directly to users and their own (extensive) experience to do so, and they succeeded at that repeatedly. Python packaging has {been seen as, actually been} miserable for years, and so by the same token the capacity to believe in/buy into solutions from the "core project" has dwindled. "If it took Astral to fix it, why would it be any different going forward?"
So that's all it really comes down to; uv isn't loved just because it's great but because it is in good hands. This real/perceived change of hands pretty much explains all the downstream responses to the news that you see in this thread. Regardless of who bought them, any fork is going to have very, very big shoes to fill, and filling those shoes appropriately is the big worry.
Does that not also suggest (cautious, make sure we back it up with our actions) optimism about this acquisition? We're not breaking up the band. These tools will be in the same hands as before. And it would be extremely value-destructive to bring in a team like ours and then undermine what made us valued and successful.
Just to be clear: I think uv and the other Astral projects will probably be just fine! I don't really think this the end at all.
I was just trying to explain why people are so upset by the perceived change of hands; that perception isn't perfect of course, it's a mixture of fear, honesty, skepticism, truth etc. I think some people here are just being absurd (e.g. the idea that community projects are magically more sustainable by the fact they are community projects is literally just wishcasting with a mix of Red-Dots-On-Plane syndrome). But I can definitely understand the source of it.
Fair enough. But that does seem like something that'd depend more on the people than the organization. Whoever forks it will need to be trusted to continue to be "good hands", whatever organization they operate under the auspices of.
Realistically I think Anthropic just has insane demand but finite capacity to run models, and Fable will just make them more money if they dedicate it to API pricing. I suspect the goal here is something like: get individual engineers/PMs on their personal plans to taste Fable and then go to their meetings and say "Yes doubling the price of every single input/output token is a good idea, boss".
reply