3 ms·

Ah, but the ToS I agreed to didn't state it.. they even admitted it wasn't clear and then unilaterally revised it. And yes, I agree businesses must abide by th

by Daviey 7mo ago

Ah, but the ToS I agreed to didn't state it.. they even admitted it wasn't clear and then unilaterally revised it. And yes, I agree businesses must abide by the ToS, it would be too much of a business risk not to.. but individual users, using for their own purpose can make their own choice. An individual choosing to not abide by their unfair ToS is perfectly reasonable and doesn't make them unserious or immature people, and it's pretty weak to make it an ad hominem attack. But if you think their reasoning is solely that opencode has poor caching, then the solution is to make it chew through the quota quicker (which i think it already does), or provide guidance on how to do it better. The arms race of trying to block it will be a war they will eventually lose.

solenoid0937 7mo ago
> then the solution is to make it chew through the quota quicker This is terrible from a product perspective. Right now they can subsidize workflows with poor caching performance. If OSS hacked clients become a big thing, they can't do this anymore.
- Daviey 7mo ago
  How does that make sense? If Claude code can have great performance by optimised caching and Opencode doesn't.. I'll run out of quota using a third party client and have a terrible experience, and the choose to use Claude code instead because wit is superior. So why not simple quota counting?
  - solenoid0937 7mo ago
    > So why not simple quota counting? Consider this: you are Anthropic. There are some Claude Code used cases that will have poor caching performance. Let's say these are 10% of your use cases. You explicitly don't count cache misses right now because it would make the UX poor for these use cases. It's no big deal since the remaining 90% of use cases can subsidize the 10%. Now open source clients become a thing. Instead of 10% of usage having poor caching, it grows to 50%. You can no longer subsidize those users because the economics don't work. You have to start counting cache misses and the UX goes to shit for everyone.

by Daviey 7mo ago

solenoid0937 7mo ago

> then the solution is to make it chew through the quota quicker This is terrible from a product perspective. Right now they can subsidize workflows with poor caching performance. If OSS hacked clients become a big thing, they can't do this anymore.

Daviey 7mo ago
How does that make sense? If Claude code can have great performance by optimised caching and Opencode doesn't.. I'll run out of quota using a third party client and have a terrible experience, and the choose to use Claude code instead because wit is superior. So why not simple quota counting?
- solenoid0937 7mo ago
  > So why not simple quota counting? Consider this: you are Anthropic. There are some Claude Code used cases that will have poor caching performance. Let's say these are 10% of your use cases. You explicitly don't count cache misses right now because it would make the UX poor for these use cases. It's no big deal since the remaining 90% of use cases can subsidize the 10%. Now open source clients become a thing. Instead of 10% of usage having poor caching, it grows to 50%. You can no longer subsidize those users because the economics don't work. You have to start counting cache misses and the UX goes to shit for everyone.