Temporary Cloudflare accounts for AI agents(blog.cloudflare.com) |
Temporary Cloudflare accounts for AI agents(blog.cloudflare.com) |
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://developers.cloudflare.com/workers/platform/pricing/#...
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.
Let’s make a thought experiment.
CEO of Cloudflare introduces hard billing caps at a _business_ (not technical) level. Your organization will never be billed more than the level you set. Your app may stop, or may continue running, but above the monthly cap it’s free for you, it becomes Cloudflare’s expense if they didn’t pause the services.
I guarantee you that in this case, all technical issues you’re talking about would be solved in three weeks, and your service would go down within 3 seconds after hitting the cap.
If CEO decision were that any over-usage above the cap is deducted from employee bonuses from the specific product division that didn’t stop spending in time — all technical challenges would be solved in 48 hours.
Currently, there are literally zero organizational incentives for CloudFlare to develop any usage caps
(I get that they're not happy to do that.)
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 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.
> If Customer exceeds any of the Total Quantity for the Services below, Cloudflare will invoice Customer in arrears at a rate that corresponds to the rate set forth in the table after this one labeled “Excess Usage Pricing.” If no such Excess Usage Pricing table has been added by the Parties to this order form or if such table does not include the Service(s) for which Customer has exceeded the Total Quantity, then the Parties will negotiate in good faith an increase in the Fees for such Service(s). Should the Parties fail to reach an agreement on an increase within thirty (30) days of Customer’s receipt of notice from Cloudflare that Customer has exceeded its usage cap for the Service(s), Cloudflare will have the right to immediately terminate such Service for its convenience, and without liability to Customer or any third party.
You don't see how the spend cap is linked to the bandwidth cap?
There's your next feature to port, Cloudflare: PEACE OF MIND!
They prefer waiving the occasional DDoS / misconfiguration over giving their customers to cause outages with something so trivially forgotten about and so disconnected from the tech and actual platform.
also its funny that i have a backup to cloudflare in case it goes down—that seems to be a regular event now as of lately with CF
Also, if it's really a problem or you are estimating it'll certainly be a problem, do email alerts or a strict shutdown if xx requests are hitting your account. You can have a simple counter in a KV.
"Oh that thing that was an experiment and had billing caps turned on but we rushed in to production and now the whole business relies on that thing is in an outage and destroying customer trust we've barely earned yet"
I get the flip side but... 2nd order effects oof.
> Any agent can now run wrangler deploy --temporary and deploy a Worker to Cloudflare. This temporary deployment stays live for 60 minutes, during which time you can claim the temporary account, making it permanently your own. If you don't, it expires on its own.
Forget about agents, Cloudflare just provided free scratch deployments - ephemeral for 60 minutes - for anyone.
This is going to be amazing for things like PR previews and code review. Being able to deploy a preview to a working URL for free is a huge reduction in friction.
I hope it doesn't get abused so much that they turn it off again.
[1] https://developers.cloudflare.com/workers/platform/claim-dep...
If it helps laugh DDoS attacks they would be incentivized to do the exact opposite. They can charge more for “protection” then.
- 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 up CF. (Fly or firebase won out)
https://snail-game.solstice-barometer.workers.dev/
pretty cool.
A “create account” button accessible to me would be so much better. Then, I create the account and invite the client to join as owner.
The system I follow is creating a new account for the client using a plus-code on my email address (like john+client10@example.com), then I invite my main account (john@example.com), then I can invite clients into that account. Its a PITA.
[1] https://blog.cloudflare.com/enterprise-grade-features-for-al...
The right model for agentic API usage is having LLMs write scripts that use APIs. Connecting agents to MCPs and telling them to go and do stuff over and over not only wastes money but invites catastrophe.
This could lead to people having a large amount of separate accounts.
It says to claim you can either sign up or sign in.
The article worded it perfectly; friction-less "efforts"
This would only work if they would provision docker image deployment, similar to google cloud run, but the still, everything serveless has its own caveats…
The latest models appear to know CF Workers inside out and are very capable of doing that if you ask them to.
Here's my GPT-5.5 xhigh + Codex Desktop transcript building one just now: https://gist.github.com/simonw/264bd6b8a39fc34c91c9c867454c6... - code here: https://github.com/simonw/cloudflare-redirect-resolver
What makes you say that?
Also Cloudflare: let's send normal humans who are trying to go about their daily lives into endless Turnstile spinner loops with absolutely zero recourse, grievance, or support infrastructure.
% npx wrangler deploy --temporary
wrangler 4.103.0
────────────────────
You must accept Cloudflare's Terms of Service (https://www.cloudflare.com/terms/) and Privacy Policy (https://www.cloudflare.com/privacypolicy/) in order to continue. By typing "yes", you agree to these terms. Type "yes" to continue. … yes
Solving proof-of-work challenge…
Temporary account ready:
Account: Educated Celery (created)
Claim within: 60 minutes
Claim URL: https://dash.cloudflare.com/claim-preview?claimToken=CAVe7LzWiGad-redacted
Total Upload: 13.79 KiB / gzip: 4.12 KiB
Uploaded cloudflare-redirect-resolver (2.27 sec)
Deployed cloudflare-redirect-resolver triggers (0.50 sec)
https://cloudflare-redirect-resolver.educated-celery.workers.dev
Current Version ID: 5c12da7f-2749-4ccc-a8f6-79b85da98d10
as far as i’m aware, that’s fully binding and often an accepted practise - take Minecraft’s server software, where you must accept the EULA with a text flag before running
The limits are 100 workers on free and 500 on paid.
And if need more then you can always go their platform which supports tenancy.
As long as you have a cronjob or similar to clean up the cost of having per PR preview is pretty much zero.
On the other hand, we already use regular CF builds for frontend previews, but that doesnt solve a fullstack PR preview much
Uh that's already true?
[1] https://blog.cloudflare.com/three-chapters-at-cloudflare-pro...
I run workers and containers and am curious what you mean. Do you have specific use cases in mind outside of the worker invocation model? If so, I'm curious what you'd want to run on Cloudflare. Otherwise, workers don't have to be much of a "lockin" if treated as a thin layer, more like configuration.
> You have other amazing parts of the stack anyway (D1, durable objects, a great object store).
Instead, if you mean accessing these resources from containers, it's a bit clunky [0] but it's there - you should be able to access worker bindings from containers through those outbound handlers.
[0] https://developers.cloudflare.com/containers/platform-detail...
Agreed. I wish CF had something like Azure's new fast-starting Express containers.
Turnstiles per minute.
Turnstile isn't something Cloudflare put up to annoy you. It's what the website owners decided to put up, for many different reasons.
In the same vein, Anubis has a default configuration that lets honest scrapers and crawlers through, because those can easily be rejected by basic web server configurations. Only scrapers pretending to be browsers need to solve the proof-of-work puzzle. You can disable that feature, of course.
Cloudflare may play this smart: force bots to pay for access, then take 30% of the cut and give the rest to the website owners. That way, websites get paid when the AI slop machine digests their content. Normal visitors get in for free, turn the scraper hellscape into a sustainable model. Bonus points for letting websites set their own rates (pre-declared to scrapers, of course) to dissuade all but the most interested scrapers.
Except for the unfortunate minority of normal visitors who always get misclassified as bots and get denied access regularly.
I wouldn’t be complaining if Cloudflare’s misclassifier bit any user with the same small probability. But it keeps biting the same users over and over again.
It is a very solvable problem, I just don't think pre- vs postpaid changes it.
Website owners that use Turnstile and other such services choose to exclude these users. A tiny margin of false positives isn't going to dissuade most website owners, I imagine only the ones that themselves have issues with Cloudflare will bother to add the necessary rules to permit uncommon users (and the bots that copy them).
Any process that doesn't take down phishing sites within a few hours at most is inadequate for protecting potential victims. Especially when I compare it to all the other providers I report abuses to, Cloudflare doesn't strike me as a company that takes abuse reports particularly seriously.
CF does have small anti-abuse teams, but it’s just not a business priority for the company to do better. We’ve tried many times to engage at a corporate level and the bottom line is they don’t care - they don’t want to police content as often stated by the executives.
It's almost always better to use Durable Objects storage, rather than D1. Even if you only want a single global database, it's better to implement that as a singleton Durable Object, than by using D1. Because that's all D1 itself actually is: a singleton Durable Object that exposes an API to its SQLite database. It's just a wrapper.
With raw Durable Objects, you get to bring your code to run on the same machine as the database itself. Your queries run on a local file, synchronously, rather than going over a network. There is essentially zero latency when using sqlite storage in a Durable Object.
If your app does no more than one DB query per request, then D1 is fine: the Worker runs near the end user, and talks over the long-haul network to D1 just once. Whereas with Durable Objects, your Worker would talk over the long-haul network to the Durable Object. No difference.
But if your app ever does two or more queries in series for a single request, then Durable Objects becomes vastly better, because you get to move that query-chaining code to happen directly where the database lives, rather than have multiple round trips.
Really, though, the only reason D1 exists is for comfort. Once you know how to use Durable Objects, there's no reason to use D1. We offer D1 because a lot of people don't want to learn a new model. (Which is fair. People are busy and may have better things to do.)
One caveat: D1's read replica support still isn't exposed in a way that you can use it in raw Durable Objects, so if you are using that, it's a legitimate advantage to D1. But we do plan to bring this functionality to raw Durable Objects at some point.
There is a feature called "smart placement" which, when enabled, tells us to detect if a Worker commonly makes multiple round trips to a particular backend and, if so, try to run the Worker close to that back-end, instead of close to the user. This helps with D1. But even if you have the Worker running in the same colo or even same machine as the D1 database, you're still speaking a network protocol to talk to it, serializing and deserializing data, switch contexts, etc. Directly invoking SQLite locally will still be orders of magnitude faster.
Also with Durable Objects you can have many objects, e.g. one object per user or one object per document, spread around the world. It's a distributed systems building block. Many of the things you can build on it can't really be "smart" auto-detected.
All technical problems are like that. You throw labor hours and hardware at them and progress is made. The question is, how much does it take, and is it worth that much? Which in turn depends on how willing you are to patronize someone else if they don't.
Suppose it would cost them X million dollars a year to provide the feature and providing it would cost them nothing in terms of sales, and indeed get them a few more because people like the feature. Well, it still costs them that amount to provide it, so then the question is whether X is less than Y. But you don't control how much it costs them to implement it, only how much of your business you're going to take somewhere else without it, and if nobody is willing to do that then why would you expect them to spend the money?
It doesn't have to be that they're purposely screwing you. It's just that if you don't care enough to choose differently then why would they?
Exactly. There's little "win" here for the business, especially when the simpler "just cap at n requests" solution exists. Pursuing this solution:
- introduces more technical complexity (increased cost of developing, testing and maintentance)
- forces overage costs onto the vendor, who will then... increase prices to cover these costs, which upsets customers and makes the company less competitive.
- doesn't improve cost prediction (since n requests can be costed out a $/request quite easily and reliably)
(The cynical will say something about "the business has an incentive to _not_ fix this issue because they get paid for overages", but this assumes that Cloudflare has the, "monopolistic" market power to make customers unhappy and still charge whatever they want. In this case implementing billing caps wouldn't do anything because Cloudflare could just... charge whatever they want.)
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
Here the agent is not a person. It's unclear this principle holds legally
I went for a personal newsfeed, agent pulls news form ~100 feeds related to my interests. Then reads all articles for me and orders them by how interesting they might be for me. I specifically asked for vector embeddings, up/down votes (-2..+2), visited status, LLM content evaluation. Probably there are some other mechanisms I didn't even bother to check. It's a work in progress but I can see myself replacing most of my news reading with it. For many news the AI summary, which contains main idea behind the item is enough for me. As a bonus it resolves clickbait and is quite good at it. Also no ads, ever. For sure I need to implement some grouping because when the popular story breaks I have many stories about the same thing with mostly overlapping details. AI merging them would be quite cool.
I also asked AI to extract my interests from my browsing/watching histories of my all accounts. V2 of my newsfeed might utilize that somehow for better results.
Silly thing is I made it in one afternoon with my only motivation of being slightly more annoyed with the web on that day.
When I move it to the server I might consider waking it up periodically to pull and analyze new stories and perhaps notify me if something absolutely great shows up.
There are so many possibilities for tuning it. And I don't need to think how to make it secure (beyond the basics), ultra performant, fitting other people's tastes and so on because this program has audience of one.
When I touched it the last time I was a fan of gemma4 https://ollama.com/library/gemma4
Since then I grew really fond of Qwen3.6 (it's super capable in coding against the DOM) so I'll probably try to move to it with the next iteration. https://ollama.com/library/qwen3.6
How do the vector embeddings fit into the picture?
> Suppose it would cost them X million dollars a year to provide the feature and providing it would cost them nothing in terms of sales, and indeed get them a few more because people like the feature. Well, it still costs them that amount to provide it, so then the question is whether X is less than Y.
lol, that is the cynical option!
It's just "we profit more by charging people for overages than we would if we put in a price cap", with more words!
It's the same as making a subscription people can enroll in online, but cancelling it requires going to the HQ in person, or writing a registered mail demand letter, etc.
After all, why build a way to cancel online subscriptions online if X is more than Y? Maybe it's more profitable to keep charging people for something they don't want.
"The cynical option" is any option which consistently puts pure profitability ahead of doing the right thing by customers, society, or human decency in general, and that is precisely the Cloudflare decision criteria we're discussing.
1) They don't build it because they purposely want to screw customers with overage charges.
2) They don't build it because building it costs money and the customer demand (i.e. willingness to switch) over that feature isn't sufficient to justify the expense.
The first one is way more cynical than the second one.
The second one is what everyone here is talking about, and it is the cynical option. The non-cynical option would be doing the right thing every once in a while, even if it doesn't earn profits.