OpenRouter doesn't even have hardware. What are they possibly subsidizing? The platform costs?
OpenRouter is guaranteed to be about the highest margin operator in the business right now. Everyone wishes they'd be them, skimming 5% off as the middleman without any OpEx.
> OpenRouter is guaranteed to be about the highest margin operator in the business right now. Everyone wishes they'd be them, skimming 5% off as the middleman without any OpEx.
The 5% fee probably has to factor in Stripe's fees, which would be around 3% to 4% depending on whether it's an international card.
Streaming, caching, and tool calling can get pretty expensive with scale, even when you don't touch inference. Maybe they're doing something clever and are quite profitable.. or maybe they've already taken $40mm from VCs and are currently trying to raise $120mm at a 1.3B evaluation.
They also show headline prices for the cheapest provider of whatever model, but then need to hit different backends some of which may be more expensive. For now they absorb those costs, but the VCs always come knocking.
Just my opinion though. Totally agreed that they have one of the best positions amongst all AI providers from a financial standpoint.
> They also show headline prices for the cheapest provider of whatever model, but then need to hit different backends some of which may be more expensive. For now they absorb those costs, [..]
They do?? I was under the impression I was just playing the price for whatever provider they deemed 'best' for each completion.
Checking now: The way they describe it in their FAQ is that if the price changes, then they will bill you the new price. But I read that as regarding if the primary model provider changes their headline token cost; not in the case of pricing differences for models that have many different backends that host them.
Regardless, I would be more concerned about the streaming costs if the service continues to blow up and they scale aggressively through VC investments. If their 5.5% skim accounted for what they needed, you'd think they could effectively grow organically..
If you need to self-host, self-host. Sourcehut is obviously not a replacement for that.
But, if not: It is different because Drew DeVault is scathingly anti-AI, and has a history of sticking to strong opinions (for better or worse). Seems like the best bet for off-premise source control if you are concerned about AI scraping and downtime.
Yeah, collaboration usually requires some sort of centralisation. Whether that is the LKML+git.kernel.org, gitlab.gnome.org, salsa.debian.org or Sourcehut, or GitHub. At least Sourcehut isn't completely proprietary and shoving AI down your throat at every possible chance. The same can be said for Codeberg and almost any GitLab CE, Gitea or Forgejo instance
This is hilarious. Seems like kind of a random image for a model to memorize, but it could be.
There is definitely enough empirical validation that shows image models retain lots of original copies in their weights, despite how much AI boosters think otherwise. That said, it is often images that end up in the training set many times, and I would think it strange for this image to do that.
Plus: So much of excellent user interface design is done through iterating on feedback from live humans testing it with their human sensory system.
Until we have embodied AI's with eyes and hands that provide good enough approximations, the aspect of design bottlenecked on human experience will stay bottlenecked.
Seems to me like Anthropic is desperately trying to find as many product-market fits as possible before they IPO. They're reaching a chaotic weekly release cadence--each new product chockful of unclear, overlapping capability with their previous.
Combine that with the obvious hackernews manipulation that somehow gets each and every haphazard release instantly to the top, and you can see they're starting to feel some real heat.
It’s interesting to claim that because everything they do goes to the top on hacker news that they must be in trouble. I haven’t heard that particular chain of effect before.
Feeling some heat != in trouble. Just that the pressure cooker is turning to a higher temp.
But, I'll gladly admit that I am bias: I'm tired of seeing blatant astroturfing by a company whose main marketing tactic is to play on societal fear, while simultaneously employing safety theatre to look like the "good guys".
It could also be that this is an exciting new, fast changing technology that happens to directly overlap and significantly impact the core audience of the site. I don’t think any form of maliciousness or secret astroturfing is required at all.
This stuff has changed a ton of what it means to exist in this whole “tech space”. The entire software development lifecycle got put into a stick blender and is in the process of getting mixed up in new and unusual ways.
It’s super cool. I haven’t been this excited about our industry since way back when the universe was just starting to get onto dialup and I grabbed my very first mp3 or wrote my first shitty program in VB or when AJAX was just entering the universe.
I think a lot of people forgot how fast shit changes in this industry and how learning new things is one of the most important skills to being successful. Everything changes all the time.
This is a tech site called hacker news. Where else would something like this be constantly discussed?
I agree — right now it's "all eyes on AI". They are moving fast, I don't think there's some evil plan behind the scenes. They're trying to build software super-weapons, and they're trying all sorts of different things because they can iterate quickly.
Of course the articles are going to get to the top. It's all anyone is thinking about, and has been for the last few years. I keep wondering if we're going to reach some sort of inflection point where the hype starts to die down, but then another "tool" is released and everyone is convinced that this is the one that will take the jobs. It's a bit tiring, but this is the brave new world.
I think it's probably both in the end. Anthropic has a lot of fans, and combine that with excited employees and investors, they probably don't need to do much explicit astroturfing to reach top of HN.
But they also desperately need users (and the data those users bring) to build their products, and the people who do have the power to manipulate this site are on their team. And it does get tiring to see a new Claude feature with like 1 comment and 25 points right at the top, multiple times in the last two week. Keeping their needs in mind, it has begun to look like manipulation, even if the above effect could explain it.
I'm glad the technology foments it excitement for you. The idea that we can share intellectual processes broadly and implement them without the previously requisite skills will obviously change the world. That it could change the world for the better, excites me too.
But many of us have our excitement tampered by the messaging, the questionable ethics behind how it has been done, and the fact that a real % of the space is basically driven by eschatological thinking. And it especially annoys me that Anthropic is the company whose messaging simultaneously encourages that eschatological thinking, and preys upon the emotional reactions it creates.
I think it is increasingly clear--if you look at recent public sentiment and feel what is in the air--that they are a villain in this aspect. I don't think we want the people who believe they are building the future to be doing so both out of fear--of China--and gaining power through others' fear of what they are doing.
But villains can ultimately do good in the world, despite their villainy. Let's hope that is how it plays out.
I mean you aren’t wrong. It’s just I don’t think it requires any kind of vote manipulation to see why ai company releases hit the front page. Back in browser war days it was the same thing.
Correct they're trying to bamboozle the stock market.
Im looking at this product and thinking - so...? Where's the vision?
Oh there is none. Its about spraying and praying that the hype continues and feeding off analysts who don't really understand most of the firms that they spend all day studying the valuation of.
For seasoned maintainers of open source repos, there is explicit evidence it does slow them down, even when they think it sped them up: https://arxiv.org/abs/2507.09089
Cue: "the tools are so much better now", "the people in the study didn't know how to use Cursor", etc. Regardless if one takes issue with this study, there are enough others of its kind to suggest skepticism regarding how much these tools really create speed benefits when employed at scale. The maintenance cliff is always nigh...
There are definitely ways in which LLMs, and agentic coding tools scaffolded in top, help with aspects of development. But to say anyone who claims otherwise is either being disingenuous or doesn't know what they are doing, is not an informed take.
I have seen this study cited enough to have a copy paste for it. And no, there are not a bunch of other studies that have any sort of conclusive evidence to support this claim either. I have looked and would welcome any with good analysis.
"""
1. The sample is extremely narrow (16 elite open-source maintainers doing ~2-hour issues on large repos they know intimately), so any measured slowdown applies only to that sliver of work, not “developers” or “software engineering” in general.
2. The treatment is really “Cursor + Claude, often in a different IDE than participants normally use, after light onboarding,” so the result could reflect tool/UX friction or unfamiliar workflows rather than an inherent slowdown from AI assistance itself.
3. The only primary outcome is self-reported time-to-completion; there is no direct measurement of code quality, scope of work, or long-term value, so a longer duration could just mean “more or better work done,” not lower productivity.
4. With 246 issues from 16 people and substantial modeling choices (e.g., regression adjustment using forecasted times, clustering decisions), the reported ~19% slowdown is statistically fragile and heavily model-dependent, making it weak evidence for a robust, general slowdown effect.
"""
Any developer (who was a developer before March 2023) that is actively using these tools and understands the nuances of how to search the vector space (prompt) is being sped up substantially.
I think we agree no the limitations of the study--I literally began my comment with "for seasoned maintainers of open source repos". I'm not sure if in your first statement ("there are no studies to back up this claim.. I welcome good analysis") you are referring to claims that support an AI-speedup. If so, we agree that good analysis is needed. But if you think there already is good data:
Can you link any? All I've seen is stuff like Anthropic claiming 90% of internal code is written by Claude--I think we'd agree that we need an unbiased source and better metrics than "code written". My concern is that whenever AI usage in professional developers is studied empirically, as far as I have seen, the results never corroborate your claim: "Any developer (who was a developer before March 2023) that is actively using these tools and understands the nuances of how to search the vector space (prompt) is being sped up substantially."
I'm open to it being possible, but as someone who was a developer before March 2023 and is surrounded by many professionals who were also so, our results are more lukewarm than what I see boosters claim. It speeds up certain types of work, but not everything in a manner that adds up to all work "sped up substantially".
I need to see data, and all the data I've seen goes the other way. Did you see the recent Substack looking at public Github data showing no increase in the trend of PRs all the way up to August 2025? All the hard data I've seen is much, much more middling than what people who have something to sell AI-wise are claiming.
"major architectural decisions don't get documented anywhere"
"commit messages give no "why""
This is so far outside of common industry practices that I don't think your sentiment generalizes. Or perhaps your expectation of what should go in a single commit message is different from the rest of us...
LLMs, especially those with reasoning chains, are notoriously bad at explaining their thought process. This isn't vibes, it is empiricism: https://arxiv.org/abs/2305.04388
If you are genuinely working somewhere where the people around you are worse than LLMs at explaining and documenting their thought process, I would looking elsewhere. Can't imagine that is good for one's own development (or sanity).
I've worked everywhere from small startups to megacorps. The megacorps certainly do better with things like initial design documents that startups often skip entirely, but even then they're often largely out-of-date because nobody updates them. I can guarantee you that I am talking about common industry practices in consumer-facing apps.
I'm not really interested in what some academic paper has to say -- I use LLM's daily and see first-hand the quality of the documentation and explanations they produce.
I don't think there's any question that, as a general rule, LLM's do a much better job documenting what they're doing, and making it easy for people to read their code, with copious comments explaining what the code is doing and why. Engineers, on the other hand, have lots of competing priorities -- even when they want to document more, the thing needs to be shipped yesterday.
Alright, I'm glad to hear you've had a successful and rich professional career. We definitely agree that engineers generally fail to document when they have competing priorities, and that LLMs can be of use to help offload some of that work successfully.
Your initial comment made it sound like you were commenting on a genuine apples-for-apples comparisons between humans and LLMs, in a controlled setting. That's the place for empiricism, and I think dismissing studies examining such situations is a mistake.
A good warning flag for why that is a mistake is the recent article that showed engineers estimated LLMs sped them up by like 24%, but when measured they were actually slower by 17%. One should always examine whether or not the specifics of the study really applies to them--there is no "end all be all" in empiricism--but when in doubt the scientific method is our primary tool for determining what is actually going on.
But we can just vibe it lol. Fwiw, the parent comment's claims line up more with my experience than yours. Leave an agent running for "hours" (as specified in the comment) coming up with architectural choices, ask it to document all of it, and then come back and see it is a massive mess. I have yet to have a colleague do that, without reaching out and saying "help I'm out of my depth".
The paper and example you talk about seem to be about agent or plan mode (in LLM IDEs like Cursor, as those modes are called) while I and the parent are talking about ask mode, which is where the confusion seems to lie. Asking the LLM about the overall structure of an existing codebase works very well.
OK yes, you are right that we might be talking about employing AI toolings in different modes, and that the paper I am referring to is absolutely about agentic tooling executing code changes on your behalf.
That said, the first comment of the person I replied to contained: "You can ask agents to identify and remove cruft", which is pretty explicitly speaking to agent mode. He was also responding to a comment that was talking about how humans spend "hours talking about architectural decisions", which as an action mapped to AI would be more plan mode than ask mode.
Overall I definitely agree that using LLM tools to just tell you things about the structure of a codebase are a great way to use them, and that they are generally better at those one-off tasks than things that involve substantial multi-step communications in the ways humans often do.
I appreciate being the weeds here haha--hopefully we all got a little better talking abou the nuances of these things :)
Idealized industry practices that people wish to follow, but when it comes to meeting deadlines, I too have seen people eschew these practices for getting things out the door. It's a human problem, not one specific to any company.
Yes I recognize that, for various reasons, people will fail to document even when it is a profesional expectation.
I guess in this case we are comparing an idealized human to an idealized AI, given AI has equally its own failings in non-idealized scenarios (like hallucination).
Who wants to bet they benchmaxxed ARC-AGI-2? Nothing in their release implies they found some sort of "secret sauce" that justifies the jump.
Maybe they are keeping that itself secret, but more likely they probably just have had humans generate an enormous number of examples, and then synthetically build on that.
No benchmark is safe, when this much money is on the line.
> When you think about divulging this information that has been helpful to your competitors, in retrospect is it like, "Yeah, we'd still do it," or would you be like, "Ah, we didn't realize how big a deal transformer was. We should have kept it indoors." How do you think about that?
> Some things we think are super critical we might not publish. Some things we think are really interesting but important for improving our products; We'll get them out into our products and then make a decision.
I'm sure each of the frontier labs have some secret methods, especially in training the models and the engineering of optimizing inference. That said, I don't think them saying they'd keep a big breakthrough secret would be evidence in this case of a "secret sauce" on ARC-AGI-2.
If they had found something fundamentally new, I doubt they would've snuck it into Gemini 3. Probably would cook on it longer and release something truly mindblowing. Or, you know, just take over the world with their new omniscient ASI :)
reply