Hacker Newsnew | past | comments | ask | show | jobs | submit | cortesoft's commentslogin

I was pretty sure that claude -p would always be fine, but I looked at the TOS and it is a bit unclear.

It says in the prohibited use section:

> Except when you are accessing our Services via an Anthropic API Key or where we otherwise explicitly permit it, to access the Services through automated or non-human means, whether through a bot, script, or otherwise.

So it seems like using a harness or your own tools to call claude -p is fine, AS LONG AS A HUMAN TRIGGERS IT. They don’t want you using the subscription to automate things calling claude -p… unless you do it through their automation tools I guess? But what if you use their automation tool to call your harness that calls claude -p? I don’t actually know. Does it matter if your tool loops to call claude -p? Or if your automation just makes repeated calls to a routine that uses your harness to make one claude -p call?

It is not nearly as clear as I thought 10 minutes ago.

Edit: Well, I was just checking my usage page and noticed the new 'Daily included routine runs' section, where it says you get 15 free routine runs with your subscription (at least with my max one), and then it switches to extra usage after that. So I guess that answers some of the questions... by using their routine functionality they are able to limit your automation potential (at least somewhat) in terms of maxing out your subscription usage.


This is quite a bit more expensive than Backblaze if you have more than 5 TBs or so

Thanks, I was quite confused for a second

That is a lot more expensive if you have more than a small amount of data.

I have always done this, although mostly so I don’t have to reload the page I am coming from when I hit the back button.

Any code that is certain that it doesn't have any vulnerabilities is going to be pretty trivial to verify.

I assume all the 'no' bets have to have an explicit end date, otherwise the 'no' bet could never win? The time horizon is never unknown on these bets.

The time horizon is unknown sometimes. One example event, "what will happen before GTA VI?" with markets like "China invades Taiwan" and "Jesus Christ returns." The NO for the second one is only 52c rn. Maybe that resolves if GTA VI is permanently canceled?

Yeah, those sorts of bets seem clearly bad unless there is an explicit time limit on them. Factoring in how long your capital is locked up in the bet and the opportunity cost of it being locked up has to be accounted for in determining your expected gains.

It doesn't matter if a vast majority of people are not rational economic actors. It only takes 1 rational actor with enough capital to take the other side of all the bad bets, and the market will be priced correctly even if the other 99 people are irrational.

'Enough' [capital] is doing a lot of work in that sentence. In the limit of a one-sided irrational market, the 'rational actor' would need to take the other side of every open transaction.

Yeah, but in the limit of a one-sided irrational market, the rational actor is going to be given as much capital as he can take.

In the long run. In the short run, our rational actor will be constrained by the Kelly criterion, well and whatever outside funding she can raise.

What makes you say it is a bad business decision? It seems to be a fine decision to make for things like AWS, since when it goes down, a ton of websites go down and no one blames the site.

There is no way to know whether it is a good or bad business decision just because they can go down when a third party goes down. For example, if you save $50 million a year by firing half your employees and replacing them with AI, but you lose $10 million a year because your site goes down when Claude goes down, then you made a great business decision.


Oddly, I do not think you are wrong. In a pure money calculus exercise, this seems like a no brainer. Naturally, the math gets iffy the moment we are trying to capture something less tangible like 'customer may get sufficiently annoyed to drop us altogether' or 'we are no longer a respected company' or what MBAs would call 'unexpected goodwill extraction'.

I honestly don't care nearly as much as I used to, because I used to be more upset over this. Now, I simply wait to see how much is enough to rile up average Joe and Jenna.


On the other hand a competitor site that is up (or bricks and mortar competitors) might get a lot of business when AWS goes down. If you depend on AWS for operations it might be a lot more expensive than that.

Mostly I think its that management does not blame the person who picks AWS. Its another iteration of "no one got fired for buying IBM/Microsoft".

It is also an issue at other levels: if all a county's businesses rely on AWS (let alone its government) then that gives the US huge leverage over you (sanctions would shut down your economy).


This is exactly my point, though. I was simply stating that you can't be sure it is a bad business decision just because it goes down sometimes. It isn't immediately obvious from that single fact whether the business decision is good or bad, it is simply one factor to consider. Occasional downtime isn't an immediate business killer for every business.

That would require AWS to actually be down a lot, and it’s not. Betting your business on AWS being flakier than whatever alternative provider you use is probably not a good idea.

No it would not require that. Suppose you are one of 10 competitors. The others all use AWS.

Your system is down as often as AWS. When you are down your lost sales are shared between 10 of them. When AWS is down you get all their lost sales.

Obviously very simplified, but you get the point. There might be a huge gain in being up when others are down.

> Betting your business on AWS being flakier than whatever alternative provider you use is probably not a good idea.

You are not betting your business on it. You are betting the consequences of downtime only.

AWS does not seem to be all that high reliability out of the box. You can use multiple availability zones etc. but you can do the equivalent elsewhere.


hundreds (thousands?) of companies who based their business on capabilities built around someone else's API. Companies that had important features stop working because a company's API terms and conditions changed. Were you not around for this?

It looks like it shouldn’t be an issue… it is just a wrapper around CLI calls to the official Claude code. It would be indistinguishable from the Anthropic side, and it isn’t even doing anything hacky or impersonating the official client.

This is my interpretation as well, Anthropic wants to be in full control of the connection between the client and their servers, and that's compatible with what I'm trying to do.

I love how aligned with traditional hacker culture this. Fantastic job, 10/10!

Nor is it flooding servers with open claw type use.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: