Cf: The Agentic CLI for the Cloudflare API
blog.cloudflare.com
blog.cloudflare.com
IMO -- it makes total sense within the existing Cloudflare tooling ecosystem.
Are there any languages doing something unique or are especially resilient in this respect?
Oh you mean like the attacks that occur in Rust's cargo?
https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on...
Javascript is plenty fast, but only if it has enough time to JIT the code and can keep it JITed in memory. For long-running backed services, it's plenty fast, for browser things, it's the only option, but for the command line, it adds needless startup time.
Agents make this even worse because they don't have a "sense of time", so if they accidentally do something which causes startup time to increase dramatically, they won't feel it like a human dev would, and won't immediately start optimizing. Unless you have some specific benchmarks in CI that fail any PR which makes the code too slow, agents will just make things slower and slower.
What would even be a good alternative? The language should have no ambient authority, be fully safe, run newly loaded code quickly, and be popular enough that current LLMs are good at it. I think the languages that fit the bill are JS/TypeScript and Lua.
JS as a tech stack breaks your "fully safe" constraint (unless you are talking about running a CLI JS application without using npm...)
codex-rs's code-mode-runtime uses plain V8 and gives it limited capabilities. (It gives it a very strange set of capabilities, but the point is that a program can grant specified capabilities to a JS script that it hosts, and the JS script can use those capabilities and nothing else.)
I suppose I should have added Lisp-like langauges to my list, although those don't have the kind of static type checking that TypeScript can offer.
Yes, and the user wants to use a command line app, regardless of what's running underneath.
1) If it runs on my dime and my infrastructure I will optimize the hell out using most cleverly written Rust and what not and gloat about engineering prowess.
2) If it runs on users computers well then, we have carefully evaluated our strategic direction and come to conclusion that JS/TS/Electron option is the best way to go.
For example are workloads for which Java performs very, very well. CLI tools that do one operation and return are not examples of these workloads. v8 is plausibly less bad because v8 is also optimized for short-running scripts, but that just means less outrageously slow, not that it will be remotely competitive with native code.
This is precisely why this blend of comments is insane.
All the CLI does is take command line arguments, put together requests based on them, send them to an API, get the responses, do mild transformation on the responses,and output it to stdout/stderr.
Pretty much any choice of tech stack will work well. This is not rocket science. It's pointless to talk about optimized solutions. It's a complete waste of time.
Choice of tech stack is not merely a question of performance, but also portability and packaging. Self-contained, compiled static binaries are much, much more portable than shipping full script runtimes (JS/Python), dealing with the inevitable spread of runtime versions installed on everyone's machines, and dealing with the version spread of the dependencies installed separately.
> All the CLI does is take command line arguments, put together requests based on them, send them to an API, get the responses, do mild transformation on the responses,and output it to stdout/stderr.
This is an argument in favor of a language like Go, arguing that the garbage collector in the runtime is inconsequential, over a language like Rust. It is not an argument for shipping a script runtime.
Yes, and clearly typescript is an established tech.
Just look at Cloudflare's wrangler cli.
Everything else is nonsense.
> This is an argument in favor of a language like Go (...)
Not really, in the sense that a myriad of alternatives would also meet the same bar,thus its stupid to frame it as "language X can do this, so language X should do it".
The bar is higher than that.
Typescript works well. Cloudflare already has a lot of experience using typescript to develop cli apps that hit their APIs.
Everyone just call down with the bike shedding. You're wasting everyone's time.
Is actually a really good example of why TS was a bad choice for Cloudflare. It made sense for their initial version, because the only programs that you could run on Cloudflare Workers were themselves JavaScript scripts, so it was a reasonable expectation that developers were already using npm/yarn/pnpm to install tools and manage dependencies.
But now, Cloudflare Workers supports containerized workloads and Python workloads. So even if your project doesn't use TS, you are still expected to set up some kind of JS toolchain for your project, just for wrangler.
No, it won't.
I just tested gcloud (brand new install, modern "cli" version, not the old "sdk" version, although the "sdk" version was every bit as bad).
With a warm cache:
$ time gcloud &>/dev/null
real 0m1.215s
user 0m0.954s
sys 0m0.243s
A CLI should be snappy. A CLI targeted at agents should be even snappier. We're note talking about massive throughput here -- we're talking about the latency added to a tool call for the mere fact that the tool call invokes the CLI. Google should be targeting two orders of magnitude of improvement here
That's fine if all you want to do is put together a nonsensical apples to oranges comparison.
If you actually want to take a look at what kind of cli app Cloudflare can put together, you'd look at the likes of wrangler.
I mean, I'm sure it takes a couple of minutes to find a notable cli app written in your language of choice with is riddled with problems. Don't you agree? Would that serve as proof your language of choice is bad?
Having said that, you should take a look at what kinds of tests you are doing and what kind of values you're seeing. Any http request is expected to take ~200ms to execute, and any app that does any kind of auth verification will do a pair of those at app start. This is before the app does anything useful. Therefore this means you are trying to nitpick over milliseconds in domains where latency alone will be an order of magnitude or two greater than the values you are holding onto as meaningful.
Why do you think the likes of nodejs dominates backend development? It's surely not because of isomorphic JavaScript, it's something else.
i'd probably write it in rust and expose ts bindings tho.
IMO these tools should strive to start quickly.
2. They may intend the parts of it to be reused on workers?
This is a testament of how toxic the fanboys behind some of these language bandwagons became: people avoid mentioning their precious little tool wasn't the top choice to develop a project, because a mundane technical decision can gather so much vitriol from these types that a flame war is bound to happen.
I suppose you're not very familiar with typescript then.
Listen, all this CLI app does is serve as an interface to send requests to the Cloudflare API. This means it only does things like sending HTTP requests, and outputting JSON. The cli app also needs to run on multiple platforms. Performance is not an issue or a concern.
I'd frame this the opposite way: what better tool do you think there is for this purpose other than TypeScript?
On top of that, there's the fact that Cloudflare's core services run on V8. If there is anything this company has, it's people familiar with JavaScript and TypeScript.
Well, anything less susceptible to supply-chain attacks, obviously.
Supply chain attacks are a factor only as far as a programming language supports modularization and has a large ecosystem. I mean, wasn't rust in the news recently due to cargo being used to execute supply chain attacks?
At least Codex CLI in rust uses 80-100MB which is still not great but a big improvement.
These AI companies screw you over from both sides. They make the cost of RAM skyrocket and then they build terrible software that uses all the RAM you have.
Please do not put cloudflare between your site and humans, they are not a trusted gatekeeper.
I frequently hit strange UI bugs with Cloudflare workers, where I need to do a hard refresh to make things right.
> Introducing cf: the agentic CLI for the entire Cloudflare API
emphasis my own to highlight the key word missing in the HN title
It’s now so good that I cd into this folder and say things like “add this and that to this configuration” and the agent immediately knows how to do it
I’m guessing cf just wraps the API into a CLI that’s easier to traverse and explore
I have been using the pre-releases with success, but this post could have waited a few days!
Wrangler still didn't feel great to use.
Great when you're a solo dev deploying a worker, but would be incredible for production deployments if this could also just natively output terraform code.
Of course, it's impossible to know for sure what was LLM processed or not, but your posts have been getting classified that way.
Related, Matt Pocock's skill for having agents generate an interactive bash script for things only humans can do (or should do), presented in the context of devops like activities
https://github.com/mattpocock/skills/blob/main/skills/produc...
I have found that having the agents write scripts to use tools like this is better (less tokens, more reliability, fewer side quests) than giving it to them directly with markdown they may or may not follow on any given day.
The other benefit to this is that you can put scripts on either side of the agent and remove all credentials from their process, removing whole classes of issues you don't want to have to tell your boss about. CLIs like this are great for read-only debug sessions, but if you are going to make modifications to your cloud infra, keep doing IaC.
Did you mean to link to /skills/engineering/wizard/SKILL.md ?
thanks for surfacing this for everyone
link: https://github.com/mattpocock/skills/blob/main/skills/engine...