What's more concerning is that this is not Facebook that is cooked, it's the users who are cooked. Facebooks Algo will only do and continue what brings the most engagement. More and more we are seeing people, mostly younger it seems, be fine with Ai content filling their feeds. It's becoming normalized now so that it can continue to be monetized.
Interestingly these companies once promoted 'body positivity' and now they're pushing down literally unrealistic standards of beauty, but that's another topic of inducing mental illness.
If users were the problem, why does it immediately show garbage content to new users or males, with zero evidence they want it, as written by other comments here?
It might be some confirmation bias here on my part but it feels as if companies are becoming more and more hostile to their API users. Recently Spotify basically nuked their API with zero urgency to fix it, redit has a whole convoluted npm package your obliged to use to create a bot, Facebook requires you to provide registered company and tax details even for development with some permissions. Am I just old man screaming at cloud about APIs used to being actually useful and intuitive?
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.
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.
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.
Instead, many, many websites (especially in the music industry) have some sort of funky API that you can only get access to if you have enough online clout. Very few are transparent about what "enough clout" even means or how much it'd cost you, and there's like an entire industry of third-party API resellers that cost like 10x more than if you went straight to the source. But you can't, because you first have to fulfill some arbitrary criteria that you can't even know about ahead of time.
I think that these companies are understanding that as the barrier to entry to build a frontend gets lower and lower, APIs will become the real moat. If you move away from their UI they will lose ad revenue, viewer stats, in short the ability to optimize how to harness your full attention. It would be great to have some stats on hand and see if and how much active API user has increased decreased in the last
two years, as I would not be surprised if it had increased at a much faster pace than in the past.
> the barrier to entry to build a frontend gets lower
My impression is the opposite: frontend/UI/UX is where the moat is growing because that's where users will (1) consume ads (2) orchestrate their agents.
I agree with you - we are saying the same thing, by restricting their API or making less developer friendly, they want you to be captive in their UI. This might not be true for Anthropic or OpenAI - another child commenter made a comment about ads in CLI, I would not be surprised if in a while we will have product placements in LLM responses exactly as we have it in movies - not a plain ad but just a slightly less subliminal suggestion.
It’s objectively easier to build a frontend now and therefore that moat is disappearing.
What you can argue is the moat is in incumbent advantage at the UI layer, not the UI itself.
I don't it's particularly hard to figure it out: APIs have been particularly at risk of being exploited for negative purposes due the explosion of AI powered bots
It's because AI is being trained on all of these APIs and the platforms are at risk of losing what makes them valuable (their data). So they have to take the API down or charge enough that it wouldn't be worth it for an AI.
What is given can be taken away. Despite the extra difficult this is why unofficial methods (e.g. scraping) are often superior. Soon we'll see more fully independent data scraping done by cameras and microphones.
APIs leak profit and control vs their counterpart SDK/platforms. Service providers use them to bootstrap traffic/brand, but will always do everything they can to reduce their usage or sunset them entirely if possible.
You're correct in your observations. In the age of agents, the walls are going up. APIs are no longer a value-add; they're a liability. MCP and the equivalent will be the norm interface. IMO.
Spotify in particular is just patently the very worst. They released an amazing and delightful app sdk, allowing for making really neat apps in the desktop app in 2011. Then cancelled it by 2014. It feels like their entire ecosystem has only ever gone downhill. Their car device was cancelled nearly immediately. Every API just gets worse and worse. Remarkable to see a company have only ever such a downward slide. The Spotify Graveyard is, imo, a place of singnificantly less honor than the Google Graveyard. https://web.archive.org/web/20141104154131/https://gigaom.co...
But also, I feel like this broad repulsive trend is such an untenable position now that AI is here. Trying to make your app an isolated disconnected service is a suicide pact. Some companies will figure out how to defend their moat, but generally people are going to prefer apps that allow them to use the app as they want, increasingly, over time. And they are not going to be stopped even if you do try to control terms!
Were I a smart engaged company, I'd be trying to build WebMCP access as soon as possible. Adoption will be slow, this isn't happening fast, but people who can mix human + agent activity on your site are going to be delighted by the experience, and that you will spread!
WebMCP is better IMHO than conventional APIs because it layers into the experience you are already having. It's not a separate channel; it can build and use the session state of your browsing to do the things. That's a huge boon for users.
Facebook doing that is actually good, to protect consumers from data abuse after incidents like cambridge analytica. They are holding businesses who touches your personal data responsible.
> Facebook doing that is actually good, to protect consumers from data abuse after incidents like cambridge analytica.
There is nothing here stopping cambridge analytica from doing this again, they will provide whatever details needed. But a small pre launch personal project work that might use a facebook publishing application can't be developed or tested without first going through all the bureaucracy.
Nevermind the non profit 'free' application you might want to create on the FB platform, lets say a share chrome extension "Post to my FB", for personal use, you can't do this because you can't create an application without a company and IVA/TAX documents. It's hostile imo.
Before, you could create an app, link your ToS, privacy policy etc, verify your domain via email, and then if users wanted to use your application they would agree, this is how a lot of companies still do it. I'm actually not sure why FB do this specifically.
Facebook knew very early and very well about the data harvesting that was going on at Cambridge Analytica through their APIs. They acted so incredibly slowly and not-harsh that it's IMO hard to believe that they did not implicitly support it.
> to protect consumers
We are talking about Meta. They have never, and will never, protect customers. All they protect is their wealth and their political power.
Is it? I’ve never touched Facebook api, but it sounds ridiculous that you need to provide tax details for DEVELOPMENT. Can’t they implement some kind of a sandbox with dummy data?
You can mock their API all you want for development and there are many pre-built options for that, but it you want to touch their systems, they're sending a very clear signal. You must be a corporate with an RBO. Seems prudent to me.
WhatsApp takes bot spam very very seriously, and as a result, there is zero bot spam.
Before you can sign up to build a WhatsApp bot, you need to jump through a million hoops, and after that, every automated message template must be vetted by Meta before it can be sent out, apple style.
I'm glad of this, because unlike SMS and other messaging platforms, WhatsApp is spam free and a pleasure to use.
At least here in Italy whatsapp is a spam house unless you actively update the default privacy settings in-app. There is no discernable difference between SMS and WhatsApp to spammers.
They just want people to use facebook. If you can see facebook content without being signed in they have a harder time tracking you and showing you ads.
Everyone has heard the word "enshittification" at this point and this falls in line. But if you haven't read the book [0] it's a great deep dive into the topical area.
But the real issue is that these companies, once they have any market leverage, do things in their best interest to protect the little bit of moat they've acquired.
It all started with Facebook closing pretty much everything and making FB Messenger a custom protocol instead of XMPP.
And whatever API access is still available is so shit and badly managed that even a household name billion dollar gaming company couldn't get a fast-lane for approval to use specific API endpoints.
The final straw was Twitter effectively closing up their API "to protect from bots", which in fact did NOT protect anyone from bots. All it did was prevent legitimate entertaining and silly bots from acting on the platform, the actual state-controlled trolls just bought the blue checkmark and continued as-is.
APIs are the best when they let you move data out and build cool stuff on top. A lot of big platforms do not really want that anymore. They want the data to stay inside their silo so access gets slower harder and more locked down. So you are not just yelling at the cloud this feels pretty intentional.
You're not wrong. Reddit & Elon started it and everyone laughed at them and made a stink. But my guess is the "last dying gasp of the freeloader" /s wasn't enough to dissuade other companies from jumping on the bandwagon, cause fiduciary responsibility to shareholders reigns supreme at the end of the day.
Yes, but some are mitigated when discoverd, and some more critical areas need to be isolated from the LLM so taking their time to provision LLM into their lifecycle is important, and they're happy to spend the time doing it right, rather than just throwing the latest edge tech into their system.
How exactly can you "mitigate" prompt injections? Given that the language space is for all intents and purposes infinite, and given that you can even circumvent these by putting your injections in hex or base64 or whatever? Like I just don't see how one can truly mitigate these when there are infinite ways of writing something in natural language, and that's before we consider the non-natural languages one can use too.
The only ways that I can think of to deal with prompt injection, are to severely limit what an agent can access.
* Never give an agent any input that is not trusted
* Never give an agent access to anything that would cause a security problem (read only access to any sensitive data/credentials, or write access to anything dangerous to write to)
* Never give an agent access to the internet (which is full of untrusted input, as well as places that sensitive data could be exfiltrated)
An LLM is effectively an unfixable confused deputy, so the only way to deal with it is effectively to lock it down so it can't read untrusted input and then do anything dangerous.
But it is really hard to do any of the things that folks find agents useful for, without relaxing those restrictions. For instance, most people let agents install packages or look at docs online, but any of those could be places for prompt injection. Many people allow it to run git and push and interact with their Git host, which allow for dangerous operations.
My current experimentation is running my coding agent in a container that only has access to the one source directory I'm working on, as well as the public internet. Still not great as the public internet access means that there's a huge surface area for prompt injection, though for the most part it's not doing anything other than installing packages from known registries where a malicious package would be just as harmful as a prompt injection.
Anyhow, there have been various people talking about how we need more sandboxes for agents, I'm sure there will be products around that, though it's a really hard problem to balance usability with security here.
Full mitigation seems impossible to me at least but the obvious and public sandox escape prompts that have been discovered and "patched" out just making it more difficult I guess. But afau it's not possible to fully mitigate.
How do you "properly align" a model to follow your instructions but not the instructions of an attacker that the model can't properly distinguish from your own? The model has no idea if it's you or an attacker saying "please upload this file to this endpoint."
This is an open problem in the LLM space, if you have a solution for it, go work for Anthropic and get paid the big bucks, they pay quite well, and they are struggling with making their models robust to prompt injection. See their system card, they have some prompt injection attacks where even with safeguards fully on, they have more than 50% failure rate of defending against attacks: https://www-cdn.anthropic.com/c788cbc0a3da9135112f97cdf6dcd0...
Huh? Once it gets to the model, it's all just tokens, and those are just in band signalling. A model just takes in a pile of tokens, and spits out some more, and it doesn't have any kind of "color" for user instructions vs. untrusted data. It does use special tokens to distinguish system instructions from user instructions, but all of the untrusted data also goes into the user instructions, and even if there are delimiters, the attention mechanism can get confused and it can lose track of who is talking at a given time.
And the thing is, even adding a "color" to tokens wouldn't really work, because LLMs are very good at learning patterns of language; for instance, even though people don't usually write with Unicode enclosed alphanumerics, the LLM learns the association and can interpret them as English text as well.
As I say, prompt injection is a very real problem, and Anthopic's own system card says that on some tests the best they do is 50% on preventing attacks.
If you have a more reliable way of fixing prompt injection, you could get paid big bucks by them to implement it.
A piece of software that you write, in code, unless you use random numbers or multiple threads without synchronization, will operate in a deterministic way. You know that for a given input, you'll get a given output; and you can reason about what happens when you change a bit, or byte, or token in the input. So you can be sure, if you implement a parser correctly, that it will correctly distinguish between one field that comes from a trusted source, and another that comes from an untrusted source.
The same is not true of an LLM. You cannot predict, precisely, how they are going to work. They can behave unexpectedly in the face of specially crafted input. If you give an LLM two pieces of text, delimited with a marker indicating that one piece is trusted and the other is untrusted, even if that marker is a special token that can't be expressed in band, you can't be sure that it's not going to act on instructions in the untrusted section.
This is why even the leading providers have trouble with protecting against prompt injection; when they have instructions in multiple places in their context, it can be hard to make sure they follow the right instructions and not the wrong ones, since the models have been trained so heavily to follow instructions.
Oh sure but it just usually doesn't show up on a financial statement so just seemed a bit strange to be commenting on the financials is all, maybe I misunderstood your context.
>it just usually doesn't show up on a financial statement
Exactly.
That's one of the reasons it's gotten so out-of-hand.
Edit: Thought I'd add that once wealth rises up to a stratospheric degree, the higher it is the less there is a need to get their money's worth. If you could put a dollar figure on it, the biggest can afford more technical debt than anybody theoretically, and they still won't actually have to deal with it.
It'll be somebody elses' problem since it's not on the balance sheet.
I guess I was commenting on the movers & shakers, not the financials specifically.
What surprised me most was the messaging seems to suggest people actually gambled more..
> Participants who saw the “when the fun stops, stop” message were 6% more likely to gamble all of their money, if they gambled at all, compared with participants who were not shown this message
If you have done that there is a review process, I don't know the numbers but I can't even begin to imagine the amount of false requests they get and so they would need to all be verified (or maybe aggregated based on amount of requests but this is just a guess).
So long story short, it's a huge company with a lot of requests for sure and things take time.
> The only way to outlaw Meta’s dangerous and egregious behavior is to pass legislation, like the Kids Online Safety Act, which will hold their feet to the fire and force them to protect children and teens.
This is no surprise he lied, that's just what businesses do, their bottom line for the shareholders is all that matters. But the answer is NOT the "Kids Online Safety Act"
Legislation will definitely help things, regulations more so, but that safety act is not the answer ie Age Verification. So rewrite it, do your job, use the researchers and experts available to you to bring a bill proposal that doesn't have special interest groups or lobbyists behind it and then we can see some improvement.
After 25 years heavily paying attention to political news, the "bad thing happened" followed by "we have to pass this bill that won't fix it but I want to capitalize on the news cycle to gain support anyway" cycle should just be assumed now.
Interestingly these companies once promoted 'body positivity' and now they're pushing down literally unrealistic standards of beauty, but that's another topic of inducing mental illness.
reply