Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Temporary Cloudflare accounts for AI agents

blog.cloudflare.com

Post reply on HN
Print view View original

111–120 of 173 posts

Re: Temporary Cloudflare accounts for AI agents

#111

Post by david_shi »

jgrahamc wrote: post #20
anilgulecha wrote: post #2

If eastdakota/jgc are here. - simply expose containers to the world directly - without having to go via workers. - You have other amazing parts of the stack anyway (D1, durable objects, a great object store). These aren't considered "lockin". - workers is "lockin" - not similar enough to lambda/cloud functions and so becomes CF specific. Not having a simple container based compute piece has made me hesitate in taking…

I am here but I retired from being CTO of Cloudflare in March 2025 [1] and the current CTO is Dane Knecht (dknecht here). What advantage does decoupling Cloudflare Containers from Cloudflare Workers have? [1] https://blog.cloudflare.com/three-chapters-at-cloudflare-pro...

Speaking from personal experience, I already know exactly what I’m getting with containers. Same with Postgres.

Re: Temporary Cloudflare accounts for AI agents

#112

Post by nextaccountic »

halJordan wrote: post #86
nextaccountic wrote: post #80

Earlier quoted context omitted.

but if an agent automatically accepts an EULA for you, is it binding?

It would have to be. And it's not new in the law at all. The principal-agent problem was one of the main enablers of the golden age of piracy. But that doesn't mean it isnt a solved problem now (in the law and practically)

> principal-agent problem

Here the agent is not a person. It's unclear this principle holds legally

Re: Temporary Cloudflare accounts for AI agents

#114

Post by sandeepkd »

halJordan wrote: post #86
nextaccountic wrote: post #80

Earlier quoted context omitted.

but if an agent automatically accepts an EULA for you, is it binding?

It would have to be. And it's not new in the law at all. The principal-agent problem was one of the main enablers of the golden age of piracy. But that doesn't mean it isnt a solved problem now (in the law and practically)

This is a binding from service perspective. The agent use case is being highlighted in this example, however in practice the server does not knows what/who the client is. In fact with API's (user not present in loop) just notifying is good enough based on what I have been told by company legal teams in the past.

Ideally the agent is supposed to be responsible to surface its own TOS and the downstream TOS to the user. In other words most likely the agent is on the hook if this goes to court

Re: Temporary Cloudflare accounts for AI agents

#115

Post by anilgulecha »

jgrahamc wrote: post #20
anilgulecha wrote: post #2

If eastdakota/jgc are here. - simply expose containers to the world directly - without having to go via workers. - You have other amazing parts of the stack anyway (D1, durable objects, a great object store). These aren't considered "lockin". - workers is "lockin" - not similar enough to lambda/cloud functions and so becomes CF specific. Not having a simple container based compute piece has made me hesitate in taking…

I am here but I retired from being CTO of Cloudflare in March 2025 [1] and the current CTO is Dane Knecht (dknecht here). What advantage does decoupling Cloudflare Containers from Cloudflare Workers have? [1] https://blog.cloudflare.com/three-chapters-at-cloudflare-pro...

No per-request billing, portable devops - easier multicloud, known semantics (env variables, entrypoint, websocket lifecycle).

Re: Temporary Cloudflare accounts for AI agents

#117

Post by jedberg »

simonw wrote: post #47

Looks like Cloudflare still haven't shipped the most valuable possible feature for Cloudflare Workers though: hard billing caps. I want to set a cap of $100/month and know, for sure, that if something untoward happens my apps will all stop serving traffic rather than me getting hit with a bill for $1000s. The safest way to use Workers is on the free tier, which will shut off after 100,000 requests/day: https://develo…

I've dealt with this before. The problem with doing a billing cap is that now you are bringing an out-of-band batch system (billing) in-band. The only way to do a dollar cap is to constantly calculate your bill.

Capping it at 100K requests is a lot easier, because it's a single number that can be incremented easily in a distributed way.

It's the same reason it took AWS forever to offer billing caps, and even today, they label it as best effort. They don't guarantee you won't pay more than your set limit.

Re: Temporary Cloudflare accounts for AI agents

#118

Post by lmz »

cj wrote: post #64
simonw wrote: post #47

Looks like Cloudflare still haven't shipped the most valuable possible feature for Cloudflare Workers though: hard billing caps. I want to set a cap of $100/month and know, for sure, that if something untoward happens my apps will all stop serving traffic rather than me getting hit with a bill for $1000s. The safest way to use Workers is on the free tier, which will shut off after 100,000 requests/day: https://develo…

Not that it helps, but I think this is only a problem if you’re paying by credit card. If your company is on an enterprise plan, at least for us all of the limits are pre-negotiated and prepaid, and you aren’t billed for overages (although if you consistently overage, sales will start badgering you to negotiate a limit increase, but my experience is you can simply ignore their demands and they eventually go away) It…

> It does drive me crazy that their enterprise tier “caps” bandwidth. Our company overaged on one of our domains, so we moved the domain out of our enterprise license onto a self-serve plan, and like magic, back to unlimited bandwidth.

You don't see how the spend cap is linked to the bandwidth cap?

Re: Temporary Cloudflare accounts for AI agents

#119

Post by MikeNotThePope »

jedberg wrote: post #117
simonw wrote: post #47

Looks like Cloudflare still haven't shipped the most valuable possible feature for Cloudflare Workers though: hard billing caps. I want to set a cap of $100/month and know, for sure, that if something untoward happens my apps will all stop serving traffic rather than me getting hit with a bill for $1000s. The safest way to use Workers is on the free tier, which will shut off after 100,000 requests/day: https://develo…

I've dealt with this before. The problem with doing a billing cap is that now you are bringing an out-of-band batch system (billing) in-band. The only way to do a dollar cap is to constantly calculate your bill. Capping it at 100K requests is a lot easier, because it's a single number that can be incremented easily in a distributed way. It's the same reason it took AWS forever to offer billing caps, and even today, t…

How about implementing a prepaid system where you set your budget, and if you exceed it, everything just pauses until you pay more?

Re: Temporary Cloudflare accounts for AI agents

#120

Post by londons_explore »

jedberg wrote: post #117
simonw wrote: post #47

Looks like Cloudflare still haven't shipped the most valuable possible feature for Cloudflare Workers though: hard billing caps. I want to set a cap of $100/month and know, for sure, that if something untoward happens my apps will all stop serving traffic rather than me getting hit with a bill for $1000s. The safest way to use Workers is on the free tier, which will shut off after 100,000 requests/day: https://develo…

I've dealt with this before. The problem with doing a billing cap is that now you are bringing an out-of-band batch system (billing) in-band. The only way to do a dollar cap is to constantly calculate your bill. Capping it at 100K requests is a lot easier, because it's a single number that can be incremented easily in a distributed way. It's the same reason it took AWS forever to offer billing caps, and even today, t…

Seems like a weak excuse... If you build a billing system which can calculate bills with low latency 99.9% of the time, but perhaps fails when there is a net split for example, then you can simply let the company write off the loss for that 0.1% of the time the billing system is down.
Post reply on HN