They put no limits on the API usage, as long as you pay.
Here, they put limits on the "under-cover" use of the subscription. If they can provide a relatively cheap subscription against the direct API use, this is because they can control the stuff end-to-end, the application running on your system (Claude Code, Claude Desktop) and their systems.
As you subscribe to these plans, this is the "contract", you can use only through their tools. If you want full freedom, use the API, with a per token pricing.
> If they can provide a relatively cheap subscription against the direct API use
Except they can't. Their costs are not magically lower when you use claude code vs when you use a third-party client.
> For me, this is fair.
This is, plain and simple, a tie-in sale of claude code. I am particularly amused by people accepting it as "fair" because in Brazil this is an illegal practice.
> This is, plain and simple, a tie-in sale of claude code. I am particularly amused by people accepting it as "fair" because in Brazil this is an illegal practice
I am very curious what is particularly illegal about this. On the sales page nowhere do they actually talk about the API https://claude.com/pricing
Now we all know obviously the API is being used because that is how things work, but you are not actually paying a subscription for the API. You are paying for access to Claude Code.
Is it also illegal that if you pay for Playstation Plus that you can't play those games on an Xbox?
Is it illegal that you can't use third party netflix apps?
I really don't want to defend and AI company here but this is perfectly normal. In no other situation would we expect access to the API, the only reason this is considered different is because they also have a different service that gives access to the API. But that is irrelevant.
It's basically the difference between pro-market capitalism and pro-business capitalism. The value to the society comes from competition in the market and from the businesses' ability to choose freely how they do business. When those two goals are in conflict, which one should be prioritized?
Anthropic provides an API third-party clients can use. The pro-market position is that the API must be available at every pricing tier, as the benefits from increased competition outweigh the imposed restrictions to business practices. The pro-business position is that Anthropic must be allowed to choose which tiers can use the API, as the benefits from increased freedom outweigh the reduced competition in the market.
So if Claude code didn’t communicate with Anthropic’s server using a well defined public api but some obscure undocumented binary format it would be fine?
Or should every app/service be required to expose documented APIs?
The immediate pro-market position is that if third-party clients are allowed / possible, Anthropic should be allowed to favor its own clients with lower prices.
But the position can go further if the service in question can be considered infrastructure. For example, a company that owns a mobile network may be required to let virtual operators use their infrastructure for a reasonable price. And a company owning a power grid may be required to become a neutral infrastructure provider that is not allowed to generate/sell power.
Anthropic is neither a monopoly nor has a dominant market position. Generally standards applied to companies like that are very different due to good reason.
Like I mentioned somewhere else I can see why some people think they are entitled to do this and I also fully understand wanting to do it from a cost standpoint.
While I do personally disagree with thinking that you should be able to do this when it was never sold in that way, at the end of the day as a customer you can choose if you want to use the product in the way that they are saying or use something else if you don’t want to support that model.
However the person I was responding too brought up legality which is a very different discussion.
Imagine if video service came with a free TV that watched you, and was really opinionated about what you watch, and you could only watch your videos on the creeper TV.
Then I would not use it because it does not work the way I want it to work...
But if that is the service they are making and they are clear about what it is when you sign up... That does not make it illegal.
I can see why people think they should be entitled to do this, but it does not align with how they are selling the service or how many other companies sell services. In most situations you don't get unlimited access to the individual components of how a service works (the API), you are expected to use the service (in this case Claude Code) directly.
"Both parties are okay with the terms" is far from being sufficient to make something "legal".
Tie-in sales between software and services is not different from price dumping. If any of the Big Tech corporations were from any country that is not the US, the FTC would be doing anything in their power to stop them.
> Tie-in sales between software and services is not different from price dumping.
I disagree, in many cases what you are specifically paying for is the combination of the software and the service that are designed to work together. And in many cases do not work independent of eachother.
There are countless cases of this, that what you are paying for is a thing that is made up of a piece of software and a serverside component. MMO's (and gaming in general) being a major example of this, but so are many of the apps I pay for subscriptions for on my phone.
The actual technical implementation of how it works is irrelevant when it is clear what it is you are paying for.
> "Both parties are okay with the terms" is far from being sufficient to make something "legal".
True but the opposite is also true, just because you don't like the terms it does not make it illegal.
> in many cases what you are specifically paying for is the combination of the software and the service that are designed to work together
And in many cases like Claude Code and the Anthropic models, they can and do work perfectly independently.
> True but the opposite is also true, just because you don't like the terms it does not make it illegal.
This is not me "not liking it". Like I said somewhere else in this thread: these types of tie-in are illegal in Brazil. This practice is clearly not done to favor the consumer. You can bet that if the US was anything closer to a functional democracy and the laws were not written by lobbyists, this would be illegal in the US as well.
Are MMO’s illegal in Brazil? Is PlayStation Plus illegal in Brazil? Is Spotify, Apple Music, etc etc etc also illegal in Brazil?
It would be ridiculous to argue that I could pay for a subscription to World of Warcraft and make my own third party client to play the game with. (Obviously you are free to argue it all you want but I would be very surprised if this was actually illegal).
> And in many cases like Claude Code and the Anthropic models, they can and do work perfectly independently.
Unless I am mistaken Claude Code does not have a local model built into it, so it requires a server side component to work?
As far as the Anthropic models, yes like many other services they ALSO have a public API that is separate from the subscription that you are paying for.
The critical difference here being that in the subscription it is very clear that you are paying for “Claude Code” which is a combination of an application and a server side component. It makes no claims about API usage as part of your subscription, again the technical implementation of the service you are actually paying for “Claude Code” is irrelevant.
When it comes to “Claude Code” for all that we should care about, again given that “Claude Code” is what you are paying for, they could be sending the information to Gemini or or a human looks at it. Because it’s irrelevant to the end user when it comes to the technical implementation since you are not being granted access to any other parts of the system directly.
"Tie-in sale": the business practice where a seller conditions the sale of one product (the tying good) on the buyer’s agreement to purchase a different product (the tied good).
The examples you are giving are not "tie-in" sales because the service from Playstation Plus, Spotify, Apple Music, etc is the distribution of digital goods.
> Unless I am mistaken Claude Code does not have a local model built into it, so it requires a server side component to work?
Which part are you not understanding?
I don't care about Claude Code. I do not want it and do not need it. All I care about is the access to the models through the client that I was already using!
> When it comes to “Claude Code” for all that we should care about, again given that “Claude Code” is what you are paying for.
No, it is not! I paid for Claude Pro. Claude != Claude Code.
> "Tie-in sale": the business practice where a seller conditions the sale of one product (the tying good) on the buyer’s agreement to purchase a different product (the tied good)
I will keep my response to this part in particular limited because I have limited understanding of this law. However based on doing a little bit of searching around the law is not as cut and dry as you are presenting it to be. It is possible that Claude code would fall under being fine under that law or no one has gone after them. I honestly don’t know and I don’t feel like having an argument that it is highly likely both of us don’t fully understand the law.
That being said I do question how exactly “Claude code” differs from those services as a digital good.
> I don't care about Claude Code. I do not want it and do not need it. All I care about is the access to the models through the client that I was already using!
OK! That is not what you’re paying for as part of Claude Pro, end of story. You are not paying for the API. It is no different that the people that have a free plan and can only chat through the web and the app also don’t get access to the API even though it is obviously using an API to access those endpoints as well.
Or are you also going to argue that free users should have access to the API because they are already using them in the browser.
> No, it is not! I paid for Claude Pro. Claude != Claude Code.
Claude Code is one of the features you are paying for as part of Claude Pro so yes in a way you are paying for it. And again not on that list is the API.
Claude Pro = claude.ai, and they made no changes to that arrangement. Both claude.ai and Claude Pro are products built on top of the Claude API. You are free to buy access to the Claude API itself, with or without the other two, but the pricing is different because the price of claude.ai and Claude Code includes the API charges they incur.
> but the pricing is different because the price of claude.ai and Claude Code includes the API charges they incur.
If that was true, then getting equivalent usage of the API without claude.ai and Claude Code should cost less, not more.
You can try to find all sorts of explanations for it, at the end of the day is quite simple: they are subsidizing one product in order to grow the market share, and they are doing it at a loss now, because they believe they will make up for it later. I understand the reasoning from a business point of view, but this doesn't mean they are entitled to their profits. I do not understand people that think we simply accept their premise and assume they can screw us over just because they asked and put it on a piece of paper.
We don't know if, on average, paying API prices for Claude Code is cheaper or not, so we don't know if they're operating it at a "loss". That math doesn't make sense in any case since it would be a "loss" based on their own external prices. The entire company is operating at a loss, regardless.
In any case, the point is it's not tying; you're free to choose any combination of products.
> n any case, the point is it's not tying; you're free to choose any combination of products.
These products can function independently, and the acquisition at a heavy discouont for one of them is conditional on the acquisition of the other. It definitely is a tie-in sale.
- It was possible to do it.
- OpenCode did not break any security protocol in order to integrate with them.
- OAuth is *precisely* a system to let third-party applications use their resources.
It's not what they wanted, but it's not my problem. The fact that I was a customer does not mean that I need to protective of their profits.
> (from their business perspective)
So what?!
Basically, they set up an strategy they thought it was going to work in their favor (offer a subsidized service to try to lock in customers), someone else found a way to turn things around and you believe that we should be okay with this?!
Honestly, I do not understand why so many people here think it is fine to let these huge corporations run the same exploitation playbook over and over again. Basically they set up a mouse trap full of cheese and now that the mice found a way to enjoy the cheese without getting their necks broken, they are crying about it?
You'd have to point me to an authoritative source on that (explicitly saying users are allowed to use their models via private APIs in apps of the user's choosing). If something isn't explicitly provided in the contract, then it can be changed at any point in any way without notice.
Honestly, I'm not big on capitalism in general, but I don't understand why people should expect companies to provide things exactly the way they want at exactly the prices they would like to be charged (if at all). That's just not how the world/system works, or should, especially given there are so many alternatives available. If one doesn't like what's happening with some service, then let the wallet do the talking and move to another. Emigration is a far more effective message than complaining.
> I don't understand why people should expect companies to provide things exactly the way they want at exactly the prices they would like to be charged
This is a gross misrepresentation of my argument.
I wouldn't be complaining at all if they went up and said "sorry, we are not going to subsidize anyone anymore, so the prices are going up", and I wouldn't be complaining if they came up and said "sorry, using a third party client incurs an extra cost of on our side, so if you want to use that you'd have to pay extra".
What I am against is the anti-competitive practice of price discrimination and the tie-in sale of a service. If they are going to play this game, then they better be ready for the case the strategy backfires. Otherwise it's just a game of "heads I win, tails you lose" where they always get to make up the rules.
> Emigration is a far more effective message than complaining.
Why not both? I cancelled my Pro subscription today. I will stick with just Ollama cloud.
It's not tie-in. They give users 2 choices: a) use their service via their public API, with the client(s) of their choice, at the regular price point; b) use the apps they provide, which use a private API, at a discounted price point. The apps are technically negative value for them from a purely upfront cost perspective as their use trigger these discounts and they're free by themselves.
Good on you re that cancel. May you find greener grass elsewhere.
> They give users 2 choices: a) use their service via their public API, with the client(s) of their choice, at the regular price point; b) use the apps they provide, which use a private API, at a discounted price point.
There was a third choice, which was better than both of the ones presented: use any other client that can talk with our API, at whatever usage rate they deemed acceptable. If the "private API" was accessible via OAuth, then it's hardly "private".
We can argue all day, when I signed up there was nothing saying that access was exclusive via the tools they provided. They changed the rules not because it was costing them more (or even if does, they are losing money on Pro customers anyway so arguing about that is silly) but because they opened themselves for some valid and fair competition.
There was no third choice if they didn't explicitly state that there was.
> If the "private API" was accessible via OAuth, then it's hardly "private".
If you invite people on your porch for a party, and someone finds that you left the house key under the mat and went off to restock, then it's hardly "private". It's perfectly fine for whomever feels like to take the party indoors without your permission. Pretty much what you're saying, reframed, but I seriously doubt you'd agree to random people entering parts of yours premises to which you didn't explicitly invite them.
Try not making it sound like the company is doing me a favor by letting me access the thing I was paying for. I wasn't "invited to a party", I was sold on an agreement that by paying a guaranteed monthly fee I could have access to the model at a rate that was lower than the pay-as-you-go rate from the API.
The primary offering is access to the models. That's what the subscription is about. They can try as hard as they want to market it as Claude being the product and access to the model being an ancillary service, but to me this is just marketing bs. No one is signing-up for Claude because their website is nicer, or because of Claude Code.
> I was sold on an agreement that by paying a guaranteed monthly fee I could have access to the model at a rate that was lower than the pay-as-you-go rate from the API
Yes, that agreement is there, with the condition that their app is used. That's option B. And I'd think it fairly obvious that if one has to go to extraordinary lengths to gain access, like finding a key under a mat, or needing to login with an official client to gain access to a token for an unofficial client, then - implicitly - it's highly unlikely that that method of access is part of the agreement. And Anthropic has now made it explicitly clear that no, that access method is not part of the agreement.
Nope, there's no tie-in sale[0] as you do not pay for the apps. And particularly, there's no real competition angle[1] as the market is loaded with LLM service providers, not to mention downloadable options.
There's a reason in this particular case why the particular APIs aren't documented: they aren't intended for public use. And they've made it crystal clear, so all you have to do now is take your wallet somewhere that offers the access you desire. You have no case here.
Could you clarify exactly what you think is an illegal tie-in? Because it seems like what you are upset about is literally the opposite -- Anthropic unbundling their offerings so you aren't required to buy the ability to offer third party access when you purchase the ability to use Claude code and their other models. Unless I really misunderstand you, your complaint is literally thaf
The laws prohibiting tie-ins don't make it illegal to sell two products that work well together. That's literally what the laws are designed to make you do -- seperate products into seperate pieces. The problem tie-in laws were designed to combat was situations like Microsoft making a popular OS then making a mediocre spreadsheet program and pushing the cost of that spreadsheet program into the cost of buying the OS. That way consumers would go "well it's expensive but I get excel with it so it's ok" and even if someone else made a slightly better spreadsheet they didn't have the chance to convince users because they had to buy it all as one package.
Anthropic would be doing something much closer to that if they did what you wanted. They'd be saying: hey we have this neat Claude code thing you all want to use but you can't buy that without also purchasing third party access. Now some company offering a cheaper/better third party usage product doesn't get the chance to convince you because anthropic forced you to buy that just to get claude code.
Ultimately this change unbundled products the opposite of a tie-in. What is upsetting about it is that it no longer feels to you like you are getting a good deal because you now have to fork over a bunch more cash to keep getting what you want. But that's not illegal, that's just not offering good value for money.
Look at it this way: the service that you're accessing is really a (primarily desired) side-effect of the software. So re subscriptions, what they're actually providing are the apps (web, desktop, etc), and the apps use their service to aid the fulfillment of their functionality. Those wanting direct access to the internal service can get an API key for that purpose. That's just how their product offering is structured.
I've heard they actually cache the full Claude Code system prompt on their servers and this saves them a lot of money. Maybe they cache the MCP tools you use and other things. If another harness like Opencode changes that prompt or adds significantly to it, that could increase costs for them.
What I don't understand is why start this game of cat and mouse? Just look at Youtube and YT-DLP. YT-DLP, and the dozens of apps that use it, basically use Youtube's unofficial web API and it still works even after Youtube constantly patches their end. Though now, YT-DLP has to use a makeshift JS interpreter and maybe even spawn Chromium down the line.
Some people drop out of the game as it gets harder. I've basically stopped looking at youtube videos unless I want it enough to download it (and wait if the current workarounds broke) with how much they've clamped down on no-account usage. Most I suspect just give in to the company's terms.
> Their costs are not magically lower when you use claude code vs when you use a third-party client.
If subsidizing that offering is a good hook to get higher paying API users on board, then some of that cost is a customer aquisition cost, whereas the cost to them of providing the API doesn't have the same proportion that they can justify as a customer acquisition cost.
I absolutely have zero concerns about their cost to acquire new customers. As a (former) customer, all I am concerned is the freedom to consume the service I am paying for however I see fit.
Unless it's illegal in more places, I think they won't care. In my experience, the percentage of free riders in Brazil is higher (due to circumstances, better said).
> Except they can't. Their costs are not magically lower when you use claude code vs when you use a third-party client.
I don't have a dog in this fight but is this actually true? If you're using Claude Code they can know that whatever client-side model selection they put into it is active. So if they can get away with routing 80% of the requests to Haiku and only route to Opus for the requests that really need it, that does give them a cost model where they can rely on lower costs than if a third-party client just routes to Opus for everything. Even if they aren't doing that sort of thing now, it would be understandable if they wanted to.
It (CC) does have a /models command, you can still decide to route everything to Opus if you just want to burn tokens
I guess it's not default so most wouldn't, but still, people willing to go to a third party client are more likely that kind of power user anyway
They still have the total consumption under their control (*bar prompt caching and other specific optimizations) where in the past they even had different quotas per model, it shouldn't cost them more money, just be a worse/different service I guess
As things are currently, better models mean bigger models that take more storage+RAM+CPU, or just spend more time processing a request. All this translates to higher costs, and may be mitigated by particular configs triggered by knowledge that a given client, providing particular guarantees, is on the other side.
That’s kind of the point. Even if users can choose which model to use (and apparently the default is the largest one), they could still say (For roughly the same cost): your Opus quota is X, your Haiku quota is Y, go ham. We’ll throttle you when you hit the limit.
But they don't want the subscription to be quota'd like that. The API automatically does that though, as different models use different amounts of tokens when generating responses, and the billing is per token. And quite literally is having the user account for the actual costs of usage, which is the thing said users are trying to avoid, on their own terms, and getting upset about when they aren't.
> It (CC) does have a /models command, you can still decide to route everything to Opus if you just want to burn tokens I guess it's not default so most wouldn't
Opus is claude code's default model as of sometime recently (around Opus 4.6?)
I think what most people don't realize is running an agent 24/7 fully automated is burning a huge hole in their profitability. Who even knows how big it is. It could be getting it on the 8/9 figures a day for all we know.
There's this pervasive idea left over from the pre-llm days that compute is free. You want to rent your own H200x8 to run your Claude model, that's literally going to cost $24/hour. People are just not thinking like that. I have my home PC, it does this stuff I can run it 24/7 for free.
I understand you mean for free in the sense that you don't pay a third party to use it, however let's no forget that you still use the power grid and that's not free. Also worth to note that energy prices have increased worldwide.
Depending on utilisation and good use of low-power or sleep (or full off) states when things aren't actively processing, it can still be a _lot_ cheaper to run things at home than on a rented service. Power costs have increased a lot in recent years, but so have compute-per-watt ratios and you are not paying the that indirect compute price when the processors are asleep or off whereas with subscription access to LLMs you are paying at least the base subscription each month even if you don't use it at all in that period. Much the same as the choice between self-hosting an open-source project or paying for a hosted instance - and in both cases people don't tend to consider the admin cost (for some of us the admin is “play time”!) so the self-hosted option it does practically feel free.
Sure it's $24/hour, but it'll crank through tens of thousands of tokens per second --- those beefy GPUs are meant for large amounts of parallel workflow. You'll never _get_ that many tokens for a single request. That's why the mathematics work when you get dozens or hundreds of people using it.
No. The sauce is in KV caching: when to evict, when to keep, how to pre-empt an active agent loop vs someone who are showing signs of inactivity at their pc, etc.
Coder doing the coding should use subscription, and now they ban the choice of your preferred ide for agentc coding. API is for automation not coding. I'm going to cancel their subscription today, I already use codex with opencode.
This is honestly the key difference here. I’m morally okay with using Claude Max Whatever with something like OpenCode because it’s literally the same thing from the usage pattern perspective. Plugging Nanoclaw into it is a whole another thing.
It probably doesn't help that the creator of OpenClaw just got hired by Anthropic's competitor.
This sounds like engineering, finance, and legal got together and decided they were in an untenable position if OpenAI started nudging OpenClaw to burn even more tokens on Anthropic (or just never optimize) + continually updated workarounds to using subscription auth. But I'm sure OpenAI would never do something like that...
At the end of the day, it's the same 'fixed price plan for variable use on a constrained resource' cellular problem: profitability becomes directly linked to actual average usage.
There probably wouldn’t be anything funny-looking – it might look like a genuine mistake in implementation that burns 2× or 3× tokens somehow (which, considering OpenClaw is vibe coded in the purest sense of this term, would blend right in).
Regardless, such things would eventually be found. Just as OpenClaw was tasked with finding and improving science repos (though unwelcome), it could - and very likely will - be tasked with improving its own codebase.
TLDR: the commit broke caching so the entire conversation history was being treated as new input on each call instead of most of the conversation being cached.
You aren't paying for usage, you are paying for the product that the subscription is offered to. If you are paying for usage, well, that's their billed by token-usage API plan, which they are quite happy for you to use with any client you want.
You are free to not use it. You are not free to use the API provided specifically for the product, which you are not explicitly paying for, for a different product.
You can of course use OpenCode or any other project with the API, which is also offered as a separate product. People just don't want to do that because it's not subsidized, ie. more expensive. But the entire reason it's subsidized is that Anthropic can use the data to improve their product.
> But the entire reason it's subsidized is that Anthropic can use the data to improve their product.
This is grade A, absolute crap. It's subsidized because everyone else is subsidizing it, and everyone is doing it because they are trying to lock their consumer share.
The solution is quite simple. Just get the FTC to forbid tie-in sales so that we don't get the huge corporations using their infinite resources to outlive the competition. Anthropic/Amazon/Google/OpenAI/Facebook can offer any type of service they want, but if the access to the API costs $X when offered standalone, then that is the baseline price for anything that depends on the API to work.
I'm fine with this as well. I just dislike everyone here presenting it like this is Anthropic being unreasonable. Given the product that is offered and why it's being offered, this is completely reasonable to do.
I’m not saying this is a bubble; I don’t know whether than it is or not. But if it is a bubble, I’ve only seen one bubble this big in tech. When that bubble popped, the only companies that survived kept their costs in check. Some raised a round right before the bubble popped but cost control was always part or their survival.
You are not paying for usage. You are paying for usage via their application.
If their business plan is based on how quickly a human can enter requests and react to the results, and Claude Code is optimized for that, why should you be allowed to use an alternative client that e.g. always tries to saturate the token limits?
They have rate limits, but they also want to control the nozzle, and not all their users use all their allocation all the time.
In reality, heavy subscription users are subsidized by light subscription users. The rate limits aren't everything.
If agent harnesses other than Claude Code consume more tokens than average, or rather, if users of agent harnesses other than CC consume more tokens than average, well, Anthropic wouldn't be unhappy if those consumers had to pay more for their tokens.
> If agent harnesses other than Claude Code consume more tokens than average, or rather, if users of agent harnesses other than CC consume more tokens than average
The speculative reasoning I've seen is that they have optimizations in their CC client that reduces their costs. If that's true, I think it's fair that they can limit subscription usage to their client. If you don't want those optimizations and prefer more freedom, use the API.
They rather have yolo permissions to run arbitrary code on your machine and phone home all the time, then opencode having it and phoning home all the time.
You're touching on the eternal App Store debate. "It's my phone, I should be able to install whatever I want on it!" Which is true, but also hasn't been true since the mid-90s (early 2000s at the latest).
Not quite though. You can install Claude's apps wherever they're supported, and maybe even fiddle with the source code (I'm unsure). And you can use any other coding apps that you want. The only real restriction is how those apps are allowed to connect to the providers' services, which are running on their servers, etc. There's a movement from "my local domain" to "their remote domain", and they're allowed to have full control of theirs as you - would prefer, I think - full control of yours.
Read the ToS, you are paying to use their products. If you want to use other products that integrate with the Anthropic LLMs they offer a product which is the API. You can use Opencode by connecting your API and being charged per token.
Doesn't that make sense? If you use it more you get charged more, if you use it less you get charged less.
But you understand that they changed the ToS today, and that's what I'm complaining about, right? "Read the ToS" isn't an answer to "I don't like this ToS change".
I didn't see today's ToS change. But this was always against ToS. OpenClaw specifically is built against tech that breaks ToS.
Probably the ToS change was to make it more clear.
To be fair, the developer is the one breaking the ToS in the most significant way, breaking boilerplate reverse engineering clauses.
But the user also is very aware that they are doing something funny, in order to authenticate, the user is asked to authorize Claude Code, n ot Opencode or OpenClaw, it's clearly a hack and there is no authorization from Anthropic to OpenClaw, and you are not giving Anthropic authorization to give access to OC, the user asks Anthropic to give access to Claude Code, the only reason this works is because OC is pretending to be Claude Code.
The bottom line issue is that as a user you are paying for a subscription to a package that includes an expected usage. That package is not metered, but it is given on the condition that you will use it as it is expected to be used, by chatting manually with the chatbot, which results in a reasonable expected token usage. By using a program that programatically calls the chat interface, the token consumption increases beyond what was part of the original deal, and so the price should be different.
A similar scenario would be if you go to an all you can eat buffet, you pay for a single person, but then you actually unload an army of little clones that start eating the whole buffet. Technically it was an all you can eat buffet and you paid the price right? Well no, come on, don't play dumb.
Their subscriptions aren't cheap, and it has nothing really to do with them controlling the system.
It's just price differentiation - they know consumers are price sensitive, and that companies wanting to use their APIs to build products so they can slap AI on their portfolio and get access to AI-related investor money can be milked. On the consumer-facing front, they live off branding and if you're not using claude code, you might not associate the tool with Anthropic, which means losing publicity that drives API sales.
It would be less of an issue if Claude-Code was actually the best coding client, and would actually somehow reduce the amount of tokens used. But it's not. I get more things done with less tokens via OpenCode. And in the end, I hit 100% usage at the end of the week anyway.
The problem is incentives. The organization selling the per-token model doesn't have the incentive, at scale to have you reduce token consumption. Other technologies do, hence adding value.
It doesn't really make sense to me because the subscriptions have limits too.
But I agree they can impose whatever user hostile restrictions they want. They are not a monopoly. They compete in a very competitive market. So if they decide to raise prices in whatever shape or form then that's fine.
Arbitrary restrictions do play a role for my own purchasing decisions though. Flexibility is worth something.
I'm with the parent comment. It was inevitable Netflix would end password-sharing. It was inevitable you'd have to pick between freeform usage-based billing and a constrained subscription experience. Using the chatbot subscription as an API was a weird loophole. I don't feel betrayed.
I don't and would never pay for an LLM, but presumably they also want for force ads down your throat eventually, yea? Hard to do if you're just selling API access.
But the idea of an API is more to encourage creativity and other people/companies building products and services on or around your systems. This used to be seen as a positive as it would mean you were an important cog in other peoples products and so more users, exposure, brand awareness etc.
This was my first thought, but by default, you have no automatic reload of your prepaid account. Which I think is for once user friendly. They could have applied a dark pattern here.
You know that if you ask the LLM correctly you get top notch answers, because you have the experience to judge if the answer is top notch or not.
I spend a couple of hours per week teaching software architecture to a junior in my team, because he has not the experience to not only ask correctly but also assess the quality of the answer from the LLM.
3 kids, same honest conversations, 2 where it worked and works very well, 1 where it is a constant battle.
So sorry but no, the platforms are addictive and not all the kids can resist against an armada of statisticians ensuring the systems stay addictive only through honest conversations.
By the way, this would mean you could solve all the addiction issues if it would be working...
My personal experience: Electric toothbrush and razor. I especially hate the razors, you can replace the head, they could last a lifetime, but the battery is practically dead after two years. Toothbrushes are improving, the last one has 3 years of service and still work ok.
I'm using an Oral-B electric toothbrush from 2009. The (non-replaceable) battery needs to be charged about every 3-5 days now, which is not a problem because it sits in its charging stand every night.
My wife bought some cheap electric toothbrush that runs on AA batteries, which can be rechargeable and have a lifespan independent of the gadget.
I think the OpenAI deal to lock wafers was a wonderful coup. OpenAI is more and more losing ground against the regularity[0] of the improvements coming from Anthropic, Google and even the open weights models. By creating a chock point at the hardware level, OpenAI can prevent the competition from increasing their reach because of the lack of hardware.
[0]: For me this is really an important part of working with Claude, the model improves with the time but stay consistent, its "personality" or whatever you want to call it, has been really stable over the past versions, this allows a very smooth transition from version N to N+1.
Is anyone else deeply perturbed by the realization that a single unprofitable corporation can basically buy out the entire world's supply of computing hardware so nobody else can have it?
I'm assuming you wouldn't see it as fine if the corporation was profitable.
> How did we get here?
We've always been there. Not that it makes it right, but that's an issue that is neither simple to fix nor something most law makers are guaranteed to want to fix in the first place.
Nothing in the rules stops you from cornering most markets, and an international companies with enough money can probably corner specific markets if they'd see a matching ROI.
> I'm assuming you wouldn't see it as fine if the corporation was profitable.
I feel like the implication of what they said was "think of how much worse it would be if they could truly spare no expense on these types of things". If an "unprofitable" company can do this, what could a profitable company of their size do on a whim?
They're simply making a bet that they can put the DRAM dies to more valuable use than any of the existing alternatives, including e.g. average folks playing the latest videogames on their gaming rig. At this kind of scale, they had better be right or they are toast: they have essentially gone all-in on their bet that this whole AI thing is not going to 'pop' anytime soon.
> They're simply making a bet that they can put the DRAM dies to more valuable use than any of the existing alternatives
They can't. They know they can't. We all know they can't. But they can just keep abusing the infinite money glitch to price everyone else out, so it doesn't matter.
When they find out that it is not, in fact, an infinite money glitch, they're going to have to eat that cost. It will work out great for everyone as long as they aren't bailed out.
It's more like a waste-infinite-money glitch, if that's what they're trying. There's no way that a simple speculative attack actually makes DRAM more valuable in the long term on its own, and that's the only win condition for that kind of play. People have tried to hoard all sorts of commodities as a mere speculative play on the market, and it never works.
I don't see this working for Google though, since they make their own custom hardware in the form of the TPUs. Unless those designs include components that are also susceptible?
That was why OpenAI went after the wafers, not the finished products. By buying up the supply of the raw materials they bottleneck everybody, even unrelated fields. It's the kind of move that requires a true asshole to pull off, knowing it will give your company an advantage but screw up life for literally billions of people at the same time.
Still susceptible, TPUs need DRAM dies just as much as anything else that needs to process data. I think they use some form of HBM, so they basically have to compete alongside the DDR supply chain.
There has always been pressure to do so, but there are fundamental bottlenecks in performance when it comes to model size.
What I can think of is that there may be a push toward training for exclusively search-based rewards so that the model isn't required to compress a large proportion of the internet into their weights. But this is likely to be much slower and come with initial performance costs that frontier model developers will not want to incur.
> so that the model isn't required to compress a large proportion of the internet into their weights.
The knowledge compressed into an LLM is a byproduct of training, not a goal. Training on internet data teaches the model to talk at all. The knowledge and ability to speak are intertwined.
I wonder if this maintains the natural language capabilities which are what LLM's magic to me. There is a probably some middle ground, but not having to know what expressions, or idiomatic speech an LLM will understand is really powerful from a user experience point of view.
What they need is not so much memory but memory bandwidth.
For training, their models have a certain number of memory needed to store the parameters, and this memory is touched for every example of every iteration. Big models have 10^12 (>1T )parameters, and with typical values of 10^3 examples per batch, and 10^6 number of iteration. They need ~10^21 memory accesses per run. And they want to do multiple runs.
DDR5 RAM bandwidth is 100G/s = 10^11, Graphics RAM (HBM) is 1T/s = 10^12. By buying the wafer they get to choose which types of memory they get.
10^21 / 10^12 = 10^9s = 30 years of memory access (just to update the model weights), you need to also add a factor 10^1-10^3 to account for the memory access needed for the model computation)
But the good news is that it parallelize extremely well. If you parallelize you 1T parameters, 10^3 times, your run time is brought down to 10^6 s = 12 days. But you need 10^3 *10^12 = 10^15 Bytes of RAM by run for weight update and 10^18 for computation (your 120 billions gigabytes is 10^20, so not so far off).
Are all these memory access technically required : No if you use other algorithms, but more compute and memory is better if money is not a problem.
Is it strategically good to deprive your concurrents from access to memory : Very short-sighted yes.
It's a textbook cornering of the computing market to prevent the emergence of local models, because customers won't be able to buy the minimal RAM necessary to run the models locally even just the inferencing part (not the training). Basically a war on people where little Timmy won't be able to get a RAM stick to play computer games at Xmas.
large language models are large and must be loaded into memory to train or to use for inference if we want to keep them fast. older models like gpt3 have around 175 billion parameters. at float32s that comes out to something like 700GB of memory. newer models are even larger. and openai wants to run them as consumer web services.
Suppose some some parallelized, distributed task requires 700GB of memory (I don't know if it does or does not) per node to accomplish, and that speed is a concern.
A singular pile of memory that is 700GB is insufficient not because it lacks capacity, but instead because it lacks scalability. That pile is only enough for 1 node.
If more nodes were added to increase speed but they all used that same single 700GB pile, then RAM bandwidth (and latency) gets in the way.
This "memory shortage" is not about AI companies needing main memory (which you plug into mainboards), but manufacturers are shifting their production capacities to other types of memory that will go onto GPUs. That brings supply for other memory products down, increasing their market price.
The conspiracy theory (which, to be clear, may be correct) is that they don't actually need so much RAM, but they know they and all their competitors do still need quite a bit of RAM. By buying up all the memory supply they can, for a while, keep everyone else from being able to add compute capacity/grow their business/compete.
I'm not too keyed into the economics of this supposed AI bubble, but is this not an unfathomably risky move on OpenAI's part? If this thing actually pops, or a competitor like Google actually pulls ahead and comes out victorious, then OpenAI will sit holding a very expensive bag of expensive but unusable raw materials that they'll have to sell of at a discount?
Sure, but if the price is being inflated by inflated demand, then the suppliers will just build more factories until they hit a new, higher optimal production level, and prices will come back down, and eventually process improvements will lead to price-per-GB resuming its overall downtrend.
Not just Micron, SK Hynix has made similar statements (unfortunately I can only find sources in Korean).
DRAM manufacturers got burned multiple times in the past scaling up production during a price bubble, and it appears they've learned their lesson (to the detriment of the rest of us).
Hedging is understandable. But what I don't understand is why they didn't hedge by keeping Crucial around but more dormant (higher prices, less SKUs, etc)
The theory I've heard is built on the fact that China (CXMT) is starting to properly get into DRAM manufacturing - Micron might expect that to swamp the low end of the market, leaving Crucial unprofitable regardless, so they might as well throw in the towel now and make as much money as possible from AI/datacenter (which has bigger margins) while they can.
But yeah even if that's true I don't know why they wouldn't hedge their bets a bit.
So position Crucial as a premium brand, raise prices 4x instead of 3x, and drastically cut down on the SKUs to reduce overhead. If they tried that and kept spiraling into fewer and fewer SKUs and sales, I could understand it. But the discontinuation felt pretty abrupt.
Chip factories need years of lead time, and manufacturers might be hesitant to take on new debt in a massive bubble that might pop before they ever see any returns.
Long life, high activity nuclear waste represents less than 3500m3 (one Olympic swimming pool), and this, since the start of civil nuclear electrical production in the 50's. World wide.
20 swimming pools of total waste isn't that impressive. I don't want to live near that, but I'm sure I'd we can find a place to put that in that will have minimal impact on people's lives.
Exactly. The waste isn't really a problem. But it doesn't have to be waste. That's the point. All that U235 in 'spent' silos? You can get 60x - 100x its OG power feeding it to nextgen reactors. So cool
I guess you mean the "super hot for centuries" minor actinides (Np-237, Am-241/243, Cm-242/244/245 etc..)? These are less than 1% global waste, but next gen reactors can still eat them. The majority of waste (95%+) is U-235, then Pu, which nextgen also eats.
Here, they put limits on the "under-cover" use of the subscription. If they can provide a relatively cheap subscription against the direct API use, this is because they can control the stuff end-to-end, the application running on your system (Claude Code, Claude Desktop) and their systems.
As you subscribe to these plans, this is the "contract", you can use only through their tools. If you want full freedom, use the API, with a per token pricing.
For me, this is fair.