If you ask who would pay for Apple local models, I would. A Mac Studio high end 512GB costs ~$1000/month for 3 years versus my current run rate of ~$1000/month for five devs for Claude Ultra (or ~$10k/week for Claude Sonnet if I paid API rates rather than Ultra).
If/when Anthropic changes to pure API pricing, or for API-heavy projects, that's when I'd switch to more local models. Of course there are tradeoffs for speed, quality, upgradeability, etc.
I currently run a Mac with 128GB and qwen3.8:27b-mlx. It hits the heat limit of the Mac when working on a 200k LOC codebase for security auditing and hardening for many hours at a time. This isn't as strong/fast as Sonnet, to be sure, yet the cost is only $6K one-time plus the usual electricity, maintenance time, etc.
$10k for Sonnet per week? How did you arrive at that number? It’s quite a huge inference volume. No consumer hardware will give you that level of latency at comparable cost.
$6k is not the only cost - electricity adds up over time. And hardware can fail, redundancy is priced into the token prices and subscription plans. Maintenance is mostly negligible, but some updates/upgrades might regress. There’s a lot to SRE to keep it running at that scale.
I run "npx ccusage@latest weekly" and also spot-check Claude Code sessions via "/usage".
> No consumer hardware will give you that level of latency at comparable cost.
You're right. My belief is the frontier AI companies are currently subsidizing real costs for the purpose of rapid growth customer sign ups, and that in a couple years or so local costs will become reasonable, at least for full-throttle work that's queueable.
Even if one believes the price of models will only go up from frontier AI companies AND believe the local AI frontier will be fast enough at a good enough profile, it still doesn't explain how you're going to beat the price of a place hosting open weight models at scale on shared hardware always maxed out 100% in a place with cheap electricity by buying a single platform up front for 3 years.
Data sovereignty always makes sense in this case because it's explicitly not about cost, but I've not seen a convincing "it's actually cheaper to do it yourself" analysis that came to that conclusion by answering all of these things up front instead of just hoping it'll somehow get better by then.
I did the math once, to run Kimi K3 on a Mac, you'd need to daisy chain 5 Mac Studio M3 Ultras. So $125K. And the latency would be bad.
For good latency, you would need a multi GPU server around $3-600K.
I agree the hardware will catch up and local is the future. For the average person who is sharing there privacy data out willy nilly all the time without much regard, i.e. most people, it makes no sense right now to go local vs. API / subscription given the price differential.
Break even is likely for API pricing versus local, at least within a couple of years or so IMHO.
For example one of the projects is a web app that's processing user input, making AI suggestions, generating reports, doing ongoing observability, and running batch processing overnight.
Claude currently does these via API pricing, not Claude Ultra personal.
Why is it that you don’t include costs for the engineer catering to 512gigs system, potentially well saturated in usage? Anyone who understands inference at this level is at least 5k a month.
I can easily see everyone on my team having a Claude subscription, and then we can orchestrate and federate to spend the unused limits. I don’t see how this breaks toc, given we don’t resell. And 1000€ (or dollars) in Anthropic subscription buys billions if not trillions of tokens, if used right.
yes, but you pay the Ultra plan, that's the whole point, isn't it? Let's be honest also - qwen3.8:27b-mlx is nowhere near Sonnet, both in size and cap, and if you do $10k a week of usage, you should know that.
The 512GB server he specified would be running something more like qwen3.8-flash-next, which is probably competitive with sonnet 5 (but still loses to 5.5).
I've tried it out on a 512GB dram server with 2*3090s and it works really quite well. Draws enough power to cost something similar to Luna, though.
Not really. My setup is just a hair cheaper than paying API prices for Luna (and it will do security audits for me). The mac would be even better on power.
I don't think any of these self hosted setups are a good deal when you look at the NPV of the capex plus the power costs, but if you already own the hardware it can be okay or even a slight cost savings.
This is very generous and very welcoming of you! Thank you, I would really appreciative and honored.
I do want to clarify that my "ADRs4AI" ADRs are different, they are "Architectural Deliberation Records" and are directly inspired by Architectural Decision Records, but they are different in that they are seeking to capture not just the outcome but the process. (Another poster was confused and did not realize the distinction, arguing that what I'm suggesting "non-ADRs labeled as ADRs", which is literally true, see https://news.ycombinator.com/item?id=50240908). My records are intentionally more verbose, they are intentionally trying to capture the process not the outcome(/state).
I would love to include ADRs4AI in your repo, but do you think the distinction is okay and can we draw it clearly? And if so, what's the next step? I could not find contributing guidelines.
Oh, separately, the marketplace extension also supports a strict superset of functionality of an Architectural Decision Record:
I use Loco extensively on many projects and it's great. The creators are very responsive to ideas and questions. Loco feels like it's a perfect halfway point between Axum and Rails.
On my wishlist is batteries-included command-line setup support for database access using Diesel instead of SeaORM because I like formal types, and security tokens using PASETO instead of JWT because I like specific algorithms.
I'm doing this attack surface tactic with Vix IDE, a terminal text editor that helps novices get comfortable with vi, emacs, git, jj, sql, commands, and more.
The prompt I used was "Goal: rework to reduce the attack surface. Process: move features into feature-flag Rust crates. Output: build a minimal version. Questions: Ask me anything."
This past weekend, Claude Fable/Opus/Sonnet together successfully refactored the whole Vix IDE codebase into many separate Rust crates and Cargo features.
This refactor enables a security-oriented user to pick and choose, and also makes it easier for a security auditor to look at one capability at a time.
If you're curious you can see the commit messages by Claude Sonnet. IMHO they're reasonably good.
Is there not a great irony in over a weekend throwing Fable/Opus/Sonnet at your project, refactoring your whole codebase, and the purpose of that project is to teach people to use vi, git, sql and so on. Why would anyone want to learn that in the current day and age, when as you state it can refactor a project over a weekend fairly autonomously?
Good article on Rust's strengths with types. If you like this, you may be curious how you might build your own parse capabilities. I like the Rust crates Winnow and Nom, and also the Rust traits From and Into.
Jujutsu is built on top of Git, so it can benefit tools in the same ecosystem (forges, CIs, code quality tools, IDEs, plugins, etc).
I have only played a little with jj and hg, but I felt that jj has a more modern UX, learning from years of Git existence (and even influencing Git, like the new `git history` command [1]). On the other hand, hg was created in the same month as Git, both trying to improve the experience of the VCSs available at the time (april 2005).
Git already won through Github, the Linux kernel, and other important projects. Even if you like Mercurial's syntax better (I do) and wish it won (I do), that battle was over many years ago.
jj's data store is git. You can use jj while other people on your project just use git. There's no migration of data or history. You can use Github and all of the various git tooling that exists today.
As such, the initial cost of switching to jj is zero for individuals, teams, or projects. That's huge.
jj's ergonomics are significantly nicer. Fewer ways to shoot yourself in the foot, much better merge resolution, etc.
It is possible to move one step further: use own store, speak git protocol. In the end, it is about the commit-tree-blob model. I think, the main headwind is the broad decay of interest in computer science topics.
Where can I read on jj merge resolution strategies? LLM links to Arch Linux man page and other random stuff.
You can speak the git protocol over the network only, but one advantage of using the same storage on disk as Git and exposing it in the same way (in a manner that keeps jj/git in sync) is that git-based tools still work. So, people still get diff markers in the gutter of their editor buffers, random scripts that do `git rev-parse` or whatnot still work out of the box, etc. This makes the experience more seamless and imposes less friction on non JJ users, eg you do not have to write a patch and add a special case for JJ because `git rev-parse` failed to run and then ask pretty please to merge it (and then keep doing that forever as you are the only user).
It doesn't sound like much, but before I started contributing to Jujutsu I was a user of https://sapling-scm.com/ -- Sapling is fantastic. It stores data on disk in git format, but back then it was not exposed to the user by default -- the .git directory is hidden away. It actually ended up causing a lot of friction that random `git` commands would not work, or tools had other various git-based behaviors. These days, sapling has a "dotgit" mode (partially inspired by jj I assume) that puts the .git directory in the root dir, so `git` commands still work.
Beyond that though, speaking Git over the network only has other complications on the client side. In particular Git clients and servers negotiate what objects each side has (given what the client requests), and from that negotiation derives a list of needed objects to give the client, and then sends a packfile for it. This is all relatively expensive to do on demand, actually, so it would make the interactivity for network operations much worse if you need to wholly translate your storage into packed objects, etc. And doing it efficiently would require you keeping a cache around that is basically a git database anyway, so you might as well just go ahead and use it. Not the end of the world in terms of downsides, but a trade-off that adds some baggage.
Using a different data store breaks compatibility and dramatically increases the friction to switching to it. jj's superpower is that my usage of it is invisible. Right now I'm working on Github projects in jj where none of the other contributors are. Nothing about my usage of jj requires them to change anything they do.
Mercurial is too slow. Even with chg common commands like `hg status` may take hundreds of milliseconds. JJ is fast. Internally `jj log` taking more than 500ms is tracked as bugs.
Well I did not answer your second part of the question, only the first part of comparing Mercurial vs Git.
Now to the second part: I think speed still plays a role back when Bitbucket and Google Code provides Mercurial hosting and people were comparing Mercurial with Git. Eventually GitHub won the competition, so then we kinda stuck with Git.
Several jj developers (especially Martin and Yuya) are former mercurial developers.
jj borrowed quite a few things from mercurial.
So, jj can be thought at least partially as a spiritual successor. Meta's Sapling is in a similar position. From this perspective, the key feature of both is transparent git repo and git remote support (hg can speak git as a foreign language, but it's limited)
Others have answered about traction. As a one-time Mercurial user, I think the single most significant addition is first-class conflicts, so that dealing with them doesn't stop the world but can be deferred until I'm working on a particular conflicted change. (That also eliminates the need to ‘evolve’.) Easy undo is also nice.
My relatively ignorant take is that it's pretty similar to Mercurial, except that it's compatible with git repos, which is also the answer to why it might get more traction. At least from my standpoint, it also doesn't need to get traction, because I freely use it with git repos without any of my coworkers needing to use it as well (although they might! I have no idea, just like they probably don't know I use it)
The oldest known legends that obviously relate to the Arthurian mythology are Welsh.
But the further back you go, the less historical they become. And I don't mean in the sense of historical records being less reliable farther back in time; I mean that the characters in the oldest legends are clearly supernatural figures. There is no reason to postulate supernatural figures as having historical enemies. Why would they?
Yeah. There is a difference between something like Geoffrey's "De gestis Britonum" which was thought by the author to be sort of true, and Malory who knew he was writing literature.
Most of what people think about as part of the Arthur myth are from literary sources, like Lancelot, the Knights of the Round Table, or the Grail quest.
Peredur from the Mabinogion and Chrétien De Troyes Perceval are pretty strongly related, implying that there is a common Celtic source tale, but I don't think anyone has ever found one.
That's wrong. All scholars know he was a Briton, or sometimes called "Romano-Briton". The "English" (Angles, Saxons etc.) were usually the antagonists of the Britons.
I only recently started to understand that the post-Roman "dark age" was not quite as dark as I thought it was. Scholars and other interested parties can tease out a fair amount of knowledge of these times. Even though it gets quite obscure.
I have a recent book by Caleb Howells about "King Arthur" and he goes into some interesting detail about some of this stuff. He also has a YouTube channel. There is real history to be discovered here still (but much can only ever remain speculative unfortunately).
perhaps I am somewhat better informed than others, but I've gone under the assumption that familiarity with the Welsh background of Arthur was the norm since I was in my early teens, so many decades back.
Help encourage alternatives by trying Gitlab.com or Codeberg.org or Tangled.org or others, and please star some projects there to help motivate more options.
Self-promo links below if you would like to star a few of mine good for developers.
Codeberg isn't a viable infrastructure alternative. Its an opinionated community not a neutral host as they will delete repos based off subjective opinions on LLM usage and resource consumption. If continued hosting is dependent on moderators deciding if a project fits whatever the current philosophy is, and the whims of the moderation team, then I cannot consider it a serious choice for infrastructure.
Infrastructure should be neutral. Codeberg is a social club
Can you suggest a viable infrastructure alternative?
My wishlist: free for open source and paid for closed source, able to do simple projects that are handwritten and also complex projects including AI LLM code that needs CI/CD/auditing, and hosting in the UK or EU.
Aside, I donate money to Codeberg because I think Codeberg is a wonderful service with strong commitment to free open source, and because I host some larger projects and AI projects that are for public welfare social good.
https://tangled.org would love to have you :) We're hosted in the EU, and are free for open source, forever. Tangled is also designed to be federated from ground up, so you get to own your infra & data while still participating in an open network.
Tangled is a VC-funded Oy (Finnish limited liability corporation, €3.8M seed a few months ago). I searched and couldn't find a published donation route, which makes sense given it's VC-funded.
To Tangled -- it's great that the core code is MIT licensed and anyone could stand up a competing appview (the credible-exit property of atproto).
Do Tangled Labs Oy's articles include a purpose clause instead of the default profit-only purpose[0]? Or is something similar on the roadmap?
[0] OYL 1:5 reads The purpose of a company is to generate profits for the shareholders, unless otherwise provided in the Articles of Association.
You're deliberately avoiding a network effect lock-in by being federated, you make competition trivial by giving away not only the protocol but also making your code available, and you don't even restrict commercial competition by using the MIT license rather than, say, BSL.
To me that sounds like you are deliberately starting a race-to-the-bottom competition on price with, well, everyone capable of hosting a SaaS? Heck, if you don't end up with some solid competition the whole "federated code" USP doesn't play out. To me that doesn't exactly scream "good return on my €3,8M seed round". Am I missing a brilliant plan here, or should we expect a rug pull a few years down the line?
I feel like any service that is free for open source is going to struggle if it gets significant adoption and becomes a default target for hosting LLM generated code. If even MS/GitHub cannot scale to the current demand, what hope do smaller and less well-funded alternatives have?
Infrastructure can never be neutral, because infrastructure is owned and costs resources to run. All infrastructure comes with rules, be they the voting consensus of some e.V. or state-run entity, the whims of an individual on their private server, or the corporate interests of something owned by a, well, corporation.
The problem isn't "neutral infrastructure". The problem is an overreliance on centralized services even though most such services are relatively easy to host yourself.
I run my own DevOps server based entirely on OSS. Is it github? No. Does it what I need it to do? Absolutely. Do I get 99.999% uptime? No, but when it's down or slow, I can fix it. When the corporate platform is down, I can only wait.
And "network effects" are not a good argument. Open Source was wildly successful long before centraliced DevOps platforms.
And in hindsight, the added friction of getting in touch with projects before being able to send them any code, was a benefit not a disadvantage. Because it acted as a barrier of entry that disincentivized alot of subpar code from hitting these projects in the first place.
The value these centralized services provide is the centralization itself - that makes things easy to find. Remember the web before Altavista? Finding anything was detective work, guessing domains, following links through multiple pages, digging in newsgroups, asking around, and so on.
Open source was successful, but not nearly at the same level it is now thanks to precisely platforms such as GitHub (and Launchpad, and Bitbucket, and Gitlab, etc) that added useful functionality such as bug trackers and project management on top of a version control system.
Now, if we could do something like GitHub on top of a network such as Mastodon, then we would have something that's centralized enough to be useful and distributed enough to be indestructible.
> Open source was successful, but not nearly at the same level it is now thanks to precisely platforms such as GitHub (and Launchpad, and Bitbucket, and Gitlab, etc) that added useful functionality such as bug trackers and project management on top of a version control system.
None of that depends on a centralized provider. I have all the features you listed on my self-hosted platform as well.
Codeberg is one public flagship instance. They are not neutral and don't claim to be. Decisions on what to host are made via elections by e.V. members. Other platforms (GitHub, GitLab, Tangled etc.) will eventually run into this same thing as well, e.g. how GitHub responds to DMCA requests, the difference with Codeberg is that there are elections which decide on what gets hosted on the main instance. For hosting slop or running a ton of actions, the recommendation is to self-host Forgejo directly instead, meaning that you, not the e.V. pays for the consequences, and you'd use the future AP federation support for cross-instance support. Forgejo is particularly simple to self-host as well, and lots of people do it (ffmpeg, Fedora and more). That way, you get to set your own rules and e.V. election results have no effect on you.
I'm often surprised to find very questionable repos hosted on GitHub. Such as plug 'n play malware that has been public for years. Not against it, but surprised as most parts of the internet has gone in the kindergarten direction.
Infra should be immutable piece that is certainly not influenced by someone power tripping or being butt-hurt by conflicting alignment on worldview issues. These things should be completely detached from each other, and infra should be neutral with technical guarantees it cannot be cut off aside of warfare acts.
This gives the impression that there's a collective group of differing views that come together and make decisions. It's quite the opposite from my experience and they seem to actively chase out anyone who dissents from the collective hive mind's view.
while I don't know if your allegations are true, democracy means there is a group which decides on rules based on a majority vote. It doesn't mean that they have the same or different views at all, although some overlap is probably certain, because otherwise you probably wouldn't decide to join the same association.
Anyone who joins the association (small fee) can vote.
I know what the technical definition of democracy is. However, a lot of people throw it around as if it insinuates a free and open system where every idea can be voiced. That's certainly not the case at Codeberg, and they make that fairly clear. They heavily moderate content and view points that challenge the hive mind are generally moderated out of existence (or the topic/thread is simply closed).
So, yes, it's technically a democracy, but it deserves extra nuance in my mind because it might not be what everyone immediately thinks a democracy should feel like.
That's a fairly good starting place. Might seem innocuous, but don't forget that "far right" has no agreed upon boundary. You might as well replace it with "wrong think" at this point.
Which, again, good for them. I could care less. I left a little over a month ago once I figured out what was going on. They are perfectly allowed their fiefdom on the internet, but I would never recommend the platform to anyone as a useful Git forge unless they happen to sit in that little thought bubble.
Judging by your response, you wouldn't be persuaded by anything. But, I suppose to provide an opportunity for education, people do not like to be thrown into an ever growing identity group with an ever growing list of negative associations tied to it. It's not shocking to me that the people running Codeberg are oblivious to the hypocrisy and double standard they seem to be blatantly putting out. It doesn't foster "inclusivity" and tends to drive out reasonable people.
But that's the game, I suppose. Everyone knows what's going on and they just don't care. And so I don't care about Codeberg :)
Rather use BitBucket or GitLab really, both GitLab and BitBucket have been around nearly as long as GitHub? Apparently BitBucket and GitHub are both 2008, and GitLab is 2011. The others you mentioned could go on a whim.
I started my career in programming with Subversion was the most popular tool. I also had to work a little with VSS, Perforce, Mercurial and, obviously, Git. I was one of the first users of Google Code...
So, relatively, not so long ago it was pretty common to host all this stuff yourself. I don't think (or maybe don't remember) Subversion having any Web interface of its own, but, since forever Git came with GitWeb. I remember configuring it for the first time: any extra bit of configuration, especially those that resulted in some added interactive functionality seemed exciting. For a week, I'd push something to my branch and immediately refresh the browser page to see my changes reflected in the remote repository :D
The infatuation wore off very quickly: after a month I have almost forgotten the Web interface even existed.
The cycle repeated with hosted services, the addition of PR interface, the addition of "pages", the bug reports, the built-in Wiki. After discovering the new gadget and associated hype, invariably, came the realization that the predating existing functionality was... better. The PR discussion in the Web page detached from the code is a lot worse than the PR discussion in the PR itself. The built-in issue tracker doesn't come close to the stand-alone product functionality. The built-in Wiki is ridiculously underwhelming when compared to an actual Wiki.
And so was the CI. For me, it started with Gitlab. There are oh so many reasons to hate Jenkins, so, whenever anyone announced an alternative platform, I'd absolutely check it out, and so did a lot of others, I presume. I was super hyped up about the possibility of running CI from the command line, completely locally on my laptop. And then it turned out to be a bait-and-switch kind of thing. I've created monumental dozen-steps and branching pipelines connecting multiple projects only to realize that the best CI is the one that uses as little as possible of the platform tools.
In the end of the day, I came to realization, that beside the social aspect of the platform like GitHub, everything that it offers on top of the essential Git repository storage is too low quality. And so do competitors. If I was ever again tasked with setting up a company code repository storage, I'd go with a physical server attached to the local office network, unless there's no office, in which case, probably, some EC2 VM would do the job...
Places like GitHub or Gitlab lure you in with their free tier offering, where you get the storage space and some other goodies for free, but once you need to upgrade to the paid tier, you inevitably realize that it's not worth the money they charge for it.
GitHub being ruined after the AI hype is a shallow take imo.
The root problem isn't AI, Microsoft, or Azure; It's why people keep _trusting_ centralized infra.
GitLab and Codeberg can absolutely become trash, each in their own way.
The solution isn't just "migrating off of GitHub"; it's "migrating to a platform that is unownable by design, not only hope".
And there are no good enough decentralized alternatives to GitHub yet.
Tangled.org's decentralization has serious holes.
Radicle made an alien universe; a niche within a niche. Also, it's already having problems with ISPs:
https://radicle.dev/2026/04/23/domain-move
Azure was arguably as garbage four years ago as it is today, the only thing that's changed in the past few years is MS mandated vibe coding, and suddenly Github has an outage every week? A ridiculous coincidence if it's not causal.
The main hole is that ATProto's data model is a bit awkward for a code forge.
Issues/PRs/comments are records owned by their authors, not by the repo. So an issue can span N users' PDSes. That's a neat model for social media, but a forge wants the repo to be the durable owner/context of its issues and history because that's where the comment/issue/etc. logically belongs.
The solution? tangled.org acts as a super advanced cache/aggregator for that. What can possibly go wrong?
There's a good chance this will change in the future and the repo on the knot will also contain the social aspects of repos (issues, PRs, etc.)
> As time goes on we are re-assessing the idea of users owning what is "collaborative data" (issues, PRs, etc.) on their PDSes - soon may come the day that an issue also lives on the knot as a source of truth, with an accompanying pointer record on user PDS to attest that it's theirs.
If/when Anthropic changes to pure API pricing, or for API-heavy projects, that's when I'd switch to more local models. Of course there are tradeoffs for speed, quality, upgradeability, etc.
I currently run a Mac with 128GB and qwen3.8:27b-mlx. It hits the heat limit of the Mac when working on a 200k LOC codebase for security auditing and hardening for many hours at a time. This isn't as strong/fast as Sonnet, to be sure, yet the cost is only $6K one-time plus the usual electricity, maintenance time, etc.
reply