> This is the caching API we've always wanted Workers to have. Here's why it took us this long
I was looking forward to the "why it took us this long" explanation but it wasn't explicitly spelled out. Any Cloudflare staff here able to expand on that?
(The article does a good job of showing how many different smart design decisions went into this, but given caching is core to what a Cloudflare does I'm still a little surprised it took 9 years to get here!)
We implemented the "standard" Cache API back in the early days because it was a standard, one which was intended to be used together with the Service Workers API, which we were also building around back then.
But it was never a good fit. The get/put API was designed for a local browser cache, not a distributed cache like Cloudflare's. We probably should have realized this before implementing it, but it really became obvious over the years of actual use.
But given we had something that mostly worked for most use cases, it was hard to prioritize redoing it against all the other things on our plate. So we deferred.
More recently, architectural changes we've been making in Workers for other reasons happened to make it significantly easier to finally implement this the way we wanted, and we were able to find some engineering time to get it over the line.
Gory details for the curious: We've been improving the infrastructure around the notion of workers having multiple "entrypoints", with the ability to parameterize those entrypoints. ctx.props[0] and ctx.exports[1] are part of this. A lot of this was motivated by Dynamic Workers sandboxing, but the concept also presents a clean way to inject a cache between two parts of the same worker, by applying it to the entrypoint and having the worker call itself using ctx.exports.
Moreover, the introduction of "channel tokens" made a big difference[2][3]. Essentially I created a way to encode a token (bytes) representing an arbitrary entrypoint to a Worker, complete with its serialized parameters. I did this to enable these entrypoint stubs to be passed over RPC, which is again useful for sandboxing use cases, but it also created a convenient, encapsulated way to pass information through our cache infrastructure about what worker should run at the other end.
It's not a huge breakthrough or anything, but I think it made the architecture clearer in everyone's mind to the point that we got excited about using it to implement caching properly, finally.
That is, workers run "in front of" cache. That's usually what you want. Workers run on the edge, so putting them in front of cache doesn't cost anything in terms of latency, and there's a lot of useful stuff you can do only if they run in front, e.g. serving pages from cache but customizing them for specific users.
Putting workers behind cache is an architectural change. All of the logic around routing to them lives in front of the cache. And it makes Workers a lot less useful.
We weren't that excited about it until we had a clearer story for how to run custom logic on both sides of the cache, but it was pretty unclear how to do that in a nice way until the recent developments around ctx.props, ctx.exports, channel tokens, etc.
Does that new architecture make it more expensive to serve worker’s static assets and do worker-to-worker invocations? Or just harder to measure?
This change in billing makes enabling caching not such a straightforward decision, and encourages separating cached and non-cached parts of your workers into two separate workers, which is a bit annoying.
I wasn't personally involved in pricing here so I can't really say exactly why it is the way it is.
However, I'd note that, in terms of our costs, it's often cheaper for us to run your Worker than to serve from cache. Consider that Workers run locally in whatever edge location the request landed in. We are not saving any bandwidth costs by putting the cache in front of Workers rather than behind, and we've built an architecture such that running a Worker is extremely cheap, almost free.
In that light, making cache hits free would basically be giving away money. To be honest, that is another reason why implementing cache in front of Workers has been held back so long. I think the team finally decided that the only way we can deliver it without giving away too much money is to charge full price for the requests. Workers pricing is already incredibly generous, and we do need to run a business at the end of the day.
(Of course, a cache hit still saves you the CPU pricing. CPU time pricing more directly translates to costs for us, so that makes sense.)
I admit the side effect on static assets is a little weird. But no other provider offers unlimited free static asset serving to start with -- so it's only weird relative to our own unreasonable standards. :) I think the thought here is that if you need caching in front of Workers, that implies you are doing complex work in Workers and getting a lot of value out of them. So a bit of "price segmentation" kicks in here. That said, you can work around it by serving static assets from another hostname, etc.
No objection towards charging for cache hits, when the worker would have ran. That (except in worker-to-worker invocations) is always a strict upgrade, when it comes to pricing.
Worker-to-worker invocations also now participate in the cache, so despite the pricing increase, at least we’re getting some added value.
But for static assets in particular, I don’t see what value the cache is adding, so it feels like pure price segmentation.
Or, to put it another way, it makes no sense to use the Workers Static Assets feature now instead of just having the worker read the file from disk and respond with appropriate cache headers to cache indefinitely, since it cost approximately the same to us (per request pricing), but is likely more expensive to you.
Huge props to just sticking with the HTTP spec on this one with `Cache-Control` headers with `stale-while-revalidate` support. It's amazing how many other providers mess that up.
On top of that the cache tags are a slick way to do invalidation. This looks like a great product.
People that don't like writing now get to write by offloading it to an LLM, and this is the result. I miss the world where articles were mostly written by people who had the interest and patience to do it.
I was a bit confused what this adds other than just standard CDN-Cache-Control page caching that we do now. Some quirks I've found;
- You still get billed per request, whether the request hits cache or not (but don't get billed for CPU time)
- You now get billed for static asset requests! This makes no sense to me. "One thing to watch: when caching is enabled, requests that are normally free — static asset requests and worker-to-worker invocations through service bindings or ctx.exports — are billed at the standard request rate, because each one now consults the cache in front of your Worker." Yeah that sounds like a bug that just happens to generate them more money.
- The cache key automatically has the worker deployment version, so even gradual deployments populate their own cache which is nice
- It seems like you can set a totally custom cache key? But that was previously Enterprise only, can't see if that's still the case here.
> I was a bit confused what this adds other than just standard CDN-Cache-Control page caching that we do now.
Until now these cache headers didn't work if you set them in a Worker, because Workers were always run in front of the cache. You could use them if you're running Cloudflare cache in front of another origin, but not if you were e.g. rendering a site in Workers. This changes that.
> Yeah that sounds like a bug that just happens to generate them more money.
Yeah. It sounds like they moved the component that counts requests earlier in the pipeline so that it can count cache hits, and now it also counts these.
Time to migrate rarely-updating websites that still need a CMS to Cloudflare.
> One thing to watch: when caching is enabled, requests that are normally free — static asset requests and worker-to-worker invocations through service bindings or ctx.exports — are billed at the standard request rate, because each one now consults the cache in front of your Worker.
That’s a very weird limitation from a product standpoint. You might end up spending more money by enabling caching.
I wonder if static assets and worker-to-worker invocations are really more expensive to them with caching enabled, or if this is just a metering problem.
I would have made this free in the interest of making billing simpler and of making the decision to enable caching more straightforward.
If you’re min-maxing costs, this encourages awkward setups where you split workers into two, one with caching enabled and one with caching disabled.
The previous Worker in-front of the cache never made sense to my old school proxy in-front of the appserver mindset. Already using this to speed up a tool. Nice work.
It makes sense in a world where Cloudflare is something that runs in front of your app. You need to run some arbitrary code before their logic, including their cache. If you wanted something that ran after the cache, you could put it in your app, you didn’t need the worker. That was Cloudflare when Workers launched.
But now the platform has evolved to where you’re running the entire app from Workers.
Amazing, exactly what Workers lacked, I was quite annoyed that a worker would spin up when 99% of my requests then return a cache. Waste of 3ms, times millions.
Reinventing the web, one service at a time. Is it really that hard to build things like this on a per-case base, small scale, all on a bare bones VPS? Do we need a global gateway to help us not screw up the basics? Service looks nice but makes me sad somehow.
As a DevOps engineer, if you learn to implement CF Workers with Claude Code's Cloudflare skill, you will no longer be burdened by this question. I'm running a Docker swarm on my homelab, a Docker swarm on a EC2 instance, but there's no longer a single web service in either of them. Workers is insanely good.
When Workers Cache is enabled, every cacheable request to your Worker hits Cloudflare's cache first. If there's a fresh cached response, Cloudflare returns it directly — your Worker doesn't run, and you don't pay CPU time for it. On a miss, your Worker runs, and if your response is cacheable, Cloudflare stores it for the next request. The next request from anywhere on Earth can be served straight from cache.
Incredible! This is why I shoehorn all my server side usecases on to the Workers Platform. Cloudflare, since 2020 when I first went all-in, has consistently shipped features that reduce bills significantly (except for 2023 Workers usage model changes). In one case, when they shipped free Snippets (Workers but 32kb code size & 5s CPU time) for Pro accounts ($200/yr), our bills went from £15k+ to £0.
I know about the infamous "Enterprise plan" (especially, when your bandwidth is as high as ours in 100s of TBs) and know of at least one other tech shop that was required to pay for it ... but we haven't got that sales call, yet.
Our bandwidth is very high, we constantly get invited onto the call with their team, but after talking with them a few times it makes absolutely zero sense for us to have a committed spend, all the stuff I needed an account manager for in GCP/AWS just doesn't exist in CF. Support wise I imagine if it's broken for us it's also broken for 2 million other people so... yeah... Thanks CF!
One of the recent AI tells other than em dash is the excessive usage of hyphenated words:
> multi-tenant-safe cache keys
> on a server-rendered app
> byte-for-byte identical (classic)
> gets a cache-speed response
> cached-file-extensions list
Honestly, this is terrible. I had to add a "use simple words only, don't hyphenate unnecessarily" warning to my Claude config. After a full day of work, having to read these Claudisms all the time make a noticeable difference on how tired you get. It gets even worse when Claude starts to make up its own vocabulary.
Fuck, I spent all these years developing a thoughtful writing style that leaned toward clarity for the reader, even if it meant extra work to achieve precision, or adding affordances like “excessive” hyphenation, and now I guess have to learn to write worse.
I think it’s exceedingly unlikely for a good-faith reader to mistake good-faith human writing for AI writing.
Even if you use em dashes and a few phrases that have become associated with AI writing, there’s still an unmistakeable sense of how much effort was put into the writing.
But I suppose there might be naive readers who don’t know how to spot this effort and would false positive on em dashes or supposed AI phrases.
There is a world of difference between well-written human text and sloppy walls of AI-generated text. There's nothing wrong in using hyphenations or emdashes -- I use them myself! That's not the point of my comment.
Whether we like it or not, em dashes are effectively verboten in online discussions and blog posts if you want people to take you seriously. If the idea that excessive hyphenation is an AI tell gains traction, it too will become impossible to use without ruining your credibility.
What does it mean when prompting SoTA LLMs prone to slop to be concise and precise, with respect to context at hand, not work at all? Anyone benchmarking that?
Don't change. The homogenous way LLMs write is just tiresome and boring, like if every movie stared Ryan Reynolds - an actor famous for having no range. Ryan Reynolds is enjoyable to watch on occasion, but I don't want everything I watch to be Ryan Reynolds.
Yeah, I mean, slop is easily recognisable by structure and content. But the obvious "markers" everyone claims (emdashes, hyphenation, etc), are just the writing style taught in the predominantly ex-British-colonial schools where the labellers were educated
I have used em dashes extensively — for at least a decade — and I also generously apply hyphens when it makes sense to do so as well. You people are about as annoying as the grammar nazis on IRC in the '90s, except you're saying that prose is less readable because a large language model has been trained on nearly the sum total of human knowledge and found that em dashes are used extensively in the highest rated prose and therefore must be the correct choice to make.
Also, most engineers will likely just be skimming this article before feeding it into their harness to implement the changes anyway, so it makes sense for it to be more heavy on context than it would be if meant for only humans to consume.
They could just feed an llm a small corpus of past human authored posts from their site, and have the LLM rewrite it in a style matching style, and it would likely turn out pretty great.
"slop" doesn't mean "AI generated content", it means bad content, a waste of the reader's time. Grantparent's implication is that your comment was bad content, not that it was AI generated bad content.
Not the original commenter; but, at least for me, the idea is that when it’s written by humans we know that effort and care were put into communicating the news. Otherwise they could post a link to the docs and we could ask my flavor of LLM to summerize. No need for extra filler content. That why it’s slop and it’s different.
I don’t have access to my flavor of LLM on the train nor the time or budget to have it do the research and summary for me
Why are we all of a sudden pretending like pre-LLM era blogs were these pristinely well written pieces of art or even that effort and care was put into them? In most cases they were significantly less coherent and incomplete. Don’t get me started on the mess that was the communication of this particular company or one of their competitors like AWS.
Because we add humans enjoy variety. I read for entertainment, even technical posts like this one that I have no use for. I often trying to think about what the author may have been thinking when writing, why they introduced concepts in a specific order, what ideas might they have omitted, etc. It's personal and enjoyable. But now, when I detect the familiar writing style of what seems to be a gpt 5 model, that "parasocial" connection dies.
The LLM explained the core concept and features very well. But it was dull and boring to me, as I already have to read this writing style at work pretty much all day every day.
I hear you, and agree with your points, but do have to ask - what’s the point in complaining? See LLM slop as you called it, ignore it and move on. There’s plenty of more intimately authored content out there.
>I don’t have access to my flavor of LLM on the train nor the time or budget to have it do the research and summary for me
Aren't you gonna let the LLM develop for you anyway? Why bother writing and reading a post at all?
> pretending like pre-LLM era blogs were these pristinely well written pieces of art
The point is the effort and care that the writer puts which differentiates it from automatically generated text. That matters because a human can sympathize and that leads to better understanding and greater connection. That's why a post is written.
> Don’t get me started on the mess that was the communication of this particular company or one of their competitors like AWS.
And we criticize those as well. Nothing's changed. Yesterday's bad content is today's slop (plus a mind boggling amount of investment, corruption and environmental side effects).
Honestly sounds to me like you have a bone to pick with AI in general. Negative sentiment on a particular LLM authored blog post muddies the waters and misrepresents your valid points. Not the way to do this IMO. Happy to be corrected.
Machine readable: the text, font, media, formatting, is all machine readable.
I think you are looking is the signal separated from the noise. I read technical documents very quickly while having very high retention and comprehension. The AI slop and AI content generation is pushing my limits.
'AI summarization' is what I naturally or learned to do growing up. I read your request as 'human readable format' being something more conversational or perhaps with known intent: inform the human.
It is not possible. Socratic method is the better path to learning. AI can make it easier.
Suggestion: AI, summarize and then ask me questions about this topic in increasingly more difficult questions, and after passing the depth of this document push further into the deeper fundamentals and first principals of the topic.
> This is the caching API we've always wanted Workers to have. Here's why it took us this long
I was looking forward to the "why it took us this long" explanation but it wasn't explicitly spelled out. Any Cloudflare staff here able to expand on that?
(The article does a good job of showing how many different smart design decisions went into this, but given caching is core to what a Cloudflare does I'm still a little surprised it took 9 years to get here!)
The honest answer is:
We implemented the "standard" Cache API back in the early days because it was a standard, one which was intended to be used together with the Service Workers API, which we were also building around back then.
But it was never a good fit. The get/put API was designed for a local browser cache, not a distributed cache like Cloudflare's. We probably should have realized this before implementing it, but it really became obvious over the years of actual use.
But given we had something that mostly worked for most use cases, it was hard to prioritize redoing it against all the other things on our plate. So we deferred.
More recently, architectural changes we've been making in Workers for other reasons happened to make it significantly easier to finally implement this the way we wanted, and we were able to find some engineering time to get it over the line.
Gory details for the curious: We've been improving the infrastructure around the notion of workers having multiple "entrypoints", with the ability to parameterize those entrypoints. ctx.props[0] and ctx.exports[1] are part of this. A lot of this was motivated by Dynamic Workers sandboxing, but the concept also presents a clean way to inject a cache between two parts of the same worker, by applying it to the entrypoint and having the worker call itself using ctx.exports.
Moreover, the introduction of "channel tokens" made a big difference[2][3]. Essentially I created a way to encode a token (bytes) representing an arbitrary entrypoint to a Worker, complete with its serialized parameters. I did this to enable these entrypoint stubs to be passed over RPC, which is again useful for sandboxing use cases, but it also created a convenient, encapsulated way to pass information through our cache infrastructure about what worker should run at the other end.
It's not a huge breakthrough or anything, but I think it made the architecture clearer in everyone's mind to the point that we got excited about using it to implement caching properly, finally.
[0] https://developers.cloudflare.com/workers/runtime-apis/conte...
[1] https://developers.cloudflare.com/workers/runtime-apis/conte...
[2] https://github.com/cloudflare/workerd/blob/main/src/workerd/...
[3] https://github.com/cloudflare/workerd/blob/main/src/workerd/...
Realizing there's a more fundamental piece I'm not explaining well here.
Our architecture is something like:
ingress -> routing -> security -> workers -> cache -> origin
That is, workers run "in front of" cache. That's usually what you want. Workers run on the edge, so putting them in front of cache doesn't cost anything in terms of latency, and there's a lot of useful stuff you can do only if they run in front, e.g. serving pages from cache but customizing them for specific users.
Putting workers behind cache is an architectural change. All of the logic around routing to them lives in front of the cache. And it makes Workers a lot less useful.
We weren't that excited about it until we had a clearer story for how to run custom logic on both sides of the cache, but it was pretty unclear how to do that in a nice way until the recent developments around ctx.props, ctx.exports, channel tokens, etc.
Does that new architecture make it more expensive to serve worker’s static assets and do worker-to-worker invocations? Or just harder to measure?
This change in billing makes enabling caching not such a straightforward decision, and encourages separating cached and non-cached parts of your workers into two separate workers, which is a bit annoying.
I wasn't personally involved in pricing here so I can't really say exactly why it is the way it is.
However, I'd note that, in terms of our costs, it's often cheaper for us to run your Worker than to serve from cache. Consider that Workers run locally in whatever edge location the request landed in. We are not saving any bandwidth costs by putting the cache in front of Workers rather than behind, and we've built an architecture such that running a Worker is extremely cheap, almost free.
In that light, making cache hits free would basically be giving away money. To be honest, that is another reason why implementing cache in front of Workers has been held back so long. I think the team finally decided that the only way we can deliver it without giving away too much money is to charge full price for the requests. Workers pricing is already incredibly generous, and we do need to run a business at the end of the day.
(Of course, a cache hit still saves you the CPU pricing. CPU time pricing more directly translates to costs for us, so that makes sense.)
I admit the side effect on static assets is a little weird. But no other provider offers unlimited free static asset serving to start with -- so it's only weird relative to our own unreasonable standards. :) I think the thought here is that if you need caching in front of Workers, that implies you are doing complex work in Workers and getting a lot of value out of them. So a bit of "price segmentation" kicks in here. That said, you can work around it by serving static assets from another hostname, etc.
No objection towards charging for cache hits, when the worker would have ran. That (except in worker-to-worker invocations) is always a strict upgrade, when it comes to pricing.
Worker-to-worker invocations also now participate in the cache, so despite the pricing increase, at least we’re getting some added value.
But for static assets in particular, I don’t see what value the cache is adding, so it feels like pure price segmentation.
Or, to put it another way, it makes no sense to use the Workers Static Assets feature now instead of just having the worker read the file from disk and respond with appropriate cache headers to cache indefinitely, since it cost approximately the same to us (per request pricing), but is likely more expensive to you.
The article was very clearly written or heavily edited by AI, which I suspect explains some of the peculiarities in structure and wording.
Huge props to just sticking with the HTTP spec on this one with `Cache-Control` headers with `stale-while-revalidate` support. It's amazing how many other providers mess that up.
On top of that the cache tags are a slick way to do invalidation. This looks like a great product.
Great feature. Although I’m starting to get annoyed by obvious signs of LLM writing like no X, no Y etc.
People that don't like writing now get to write by offloading it to an LLM, and this is the result. I miss the world where articles were mostly written by people who had the interest and patience to do it.
At least for me I don't really read these posts/docs, I just give the link to claude and it'll implement it regardless of wording
Is this a bot or LLM reply? Because you've given this exact comment word for word at least twice in this thread...
I was a bit confused what this adds other than just standard CDN-Cache-Control page caching that we do now. Some quirks I've found;
- You still get billed per request, whether the request hits cache or not (but don't get billed for CPU time)
- You now get billed for static asset requests! This makes no sense to me. "One thing to watch: when caching is enabled, requests that are normally free — static asset requests and worker-to-worker invocations through service bindings or ctx.exports — are billed at the standard request rate, because each one now consults the cache in front of your Worker." Yeah that sounds like a bug that just happens to generate them more money.
- The cache key automatically has the worker deployment version, so even gradual deployments populate their own cache which is nice
- It seems like you can set a totally custom cache key? But that was previously Enterprise only, can't see if that's still the case here.
> I was a bit confused what this adds other than just standard CDN-Cache-Control page caching that we do now.
Until now these cache headers didn't work if you set them in a Worker, because Workers were always run in front of the cache. You could use them if you're running Cloudflare cache in front of another origin, but not if you were e.g. rendering a site in Workers. This changes that.
> Yeah that sounds like a bug that just happens to generate them more money.
Yeah. It sounds like they moved the component that counts requests earlier in the pipeline so that it can count cache hits, and now it also counts these.
CPU time is not billed
Finally :)
Time to migrate rarely-updating websites that still need a CMS to Cloudflare.
> One thing to watch: when caching is enabled, requests that are normally free — static asset requests and worker-to-worker invocations through service bindings or ctx.exports — are billed at the standard request rate, because each one now consults the cache in front of your Worker.
That’s a very weird limitation from a product standpoint. You might end up spending more money by enabling caching.
I wonder if static assets and worker-to-worker invocations are really more expensive to them with caching enabled, or if this is just a metering problem.
I would have made this free in the interest of making billing simpler and of making the decision to enable caching more straightforward.
If you’re min-maxing costs, this encourages awkward setups where you split workers into two, one with caching enabled and one with caching disabled.
finally, this was needed.
A big worry was always "why does workers sit in front of my cache? that's a waste of an invocation if i'm returning a cached result"
The previous Worker in-front of the cache never made sense to my old school proxy in-front of the appserver mindset. Already using this to speed up a tool. Nice work.
It makes sense in a world where Cloudflare is something that runs in front of your app. You need to run some arbitrary code before their logic, including their cache. If you wanted something that ran after the cache, you could put it in your app, you didn’t need the worker. That was Cloudflare when Workers launched.
But now the platform has evolved to where you’re running the entire app from Workers.
Cloudflare Snippets were actually better if you wanted to run logic before the cache (they are entirely free)
Amazing, exactly what Workers lacked, I was quite annoyed that a worker would spin up when 99% of my requests then return a cache. Waste of 3ms, times millions.
i just love the sweet $0 invoice at the end of each month for all these services.
Thanks CF.
Finally proper stale-while-revalidate support!
That landed a few months ago
Reinventing the web, one service at a time. Is it really that hard to build things like this on a per-case base, small scale, all on a bare bones VPS? Do we need a global gateway to help us not screw up the basics? Service looks nice but makes me sad somehow.
As a DevOps engineer, if you learn to implement CF Workers with Claude Code's Cloudflare skill, you will no longer be burdened by this question. I'm running a Docker swarm on my homelab, a Docker swarm on a EC2 instance, but there's no longer a single web service in either of them. Workers is insanely good.
I know about the infamous "Enterprise plan" (especially, when your bandwidth is as high as ours in 100s of TBs) and know of at least one other tech shop that was required to pay for it ... but we haven't got that sales call, yet.
Our bandwidth is very high, we constantly get invited onto the call with their team, but after talking with them a few times it makes absolutely zero sense for us to have a committed spend, all the stuff I needed an account manager for in GCP/AWS just doesn't exist in CF. Support wise I imagine if it's broken for us it's also broken for 2 million other people so... yeah... Thanks CF!
curious, how does one configure something like this for AWS Lambda? Appreciate it.
I am assuming it is a bunch of manual work.
Equivalent is probably putting AWS CloudFront in front of your lambda. Has edge caching with customizable config.
You use Cloudfront. Which you’re already doing anyway but yes, you do need to configure it.
Technically, probably CloudFront.
The feature is great. The post itself is a slop grenade.
One of the recent AI tells other than em dash is the excessive usage of hyphenated words:
> multi-tenant-safe cache keys
> on a server-rendered app
> byte-for-byte identical (classic)
> gets a cache-speed response
> cached-file-extensions list
Honestly, this is terrible. I had to add a "use simple words only, don't hyphenate unnecessarily" warning to my Claude config. After a full day of work, having to read these Claudisms all the time make a noticeable difference on how tired you get. It gets even worse when Claude starts to make up its own vocabulary.
Fuck, I spent all these years developing a thoughtful writing style that leaned toward clarity for the reader, even if it meant extra work to achieve precision, or adding affordances like “excessive” hyphenation, and now I guess have to learn to write worse.
I think it’s exceedingly unlikely for a good-faith reader to mistake good-faith human writing for AI writing.
Even if you use em dashes and a few phrases that have become associated with AI writing, there’s still an unmistakeable sense of how much effort was put into the writing.
But I suppose there might be naive readers who don’t know how to spot this effort and would false positive on em dashes or supposed AI phrases.
There is a world of difference between well-written human text and sloppy walls of AI-generated text. There's nothing wrong in using hyphenations or emdashes -- I use them myself! That's not the point of my comment.
Whether we like it or not, em dashes are effectively verboten in online discussions and blog posts if you want people to take you seriously. If the idea that excessive hyphenation is an AI tell gains traction, it too will become impossible to use without ruining your credibility.
What does it mean when prompting SoTA LLMs prone to slop to be concise and precise, with respect to context at hand, not work at all? Anyone benchmarking that?
Oh no, how will you write clearly without hyphens?
Don't change. The homogenous way LLMs write is just tiresome and boring, like if every movie stared Ryan Reynolds - an actor famous for having no range. Ryan Reynolds is enjoyable to watch on occasion, but I don't want everything I watch to be Ryan Reynolds.
It does feel a bit like the LLMs have commoditised correct writing form, and all the plebs are all up in arms about it...
I read the slop and each has a smell. Each model and company does because the humans behind it have their own taste, smell, and perspective.
The human element cannot be recreated because the human element that created the beast becomes further removed and only the beast remains.
I say beast to provide a tell that what I write is 'human'.
Yeah, I mean, slop is easily recognisable by structure and content. But the obvious "markers" everyone claims (emdashes, hyphenation, etc), are just the writing style taught in the predominantly ex-British-colonial schools where the labellers were educated
I have used em dashes extensively — for at least a decade — and I also generously apply hyphens when it makes sense to do so as well. You people are about as annoying as the grammar nazis on IRC in the '90s, except you're saying that prose is less readable because a large language model has been trained on nearly the sum total of human knowledge and found that em dashes are used extensively in the highest rated prose and therefore must be the correct choice to make.
Also, most engineers will likely just be skimming this article before feeding it into their harness to implement the changes anyway, so it makes sense for it to be more heavy on context than it would be if meant for only humans to consume.
I have an over-hyphenated writing-style as well. Probably my Germanness.
There is not reason whatsoever to hyphenate "writing style".
In this example I used the hyphen for comedic effect. But this is a actual sentence I wrote in an older post:
> What's the competition in the gaming-capable pre-built mini-PC category
I think that's probably-satire.
I opine that over-hyphenation adds clarity.
One of the earliest tells was the use of emdashes.
Billion dollar company can't afford one human copywriter. The future is great! (edit: copyrighter -> copywriter)
They could just feed an llm a small corpus of past human authored posts from their site, and have the LLM rewrite it in a style matching style, and it would likely turn out pretty great.
I've tried this with my own blog posts from blog.jgc.org and the result was... not good. It basically wrote something that read like a parody.
Ah, bummer. Not totally surprising though.
Neither can you afford a copywriter, evidently?
Modern cloudflare in a nutshell.
Can you elaborate? I read it, found the concepts well explained, walked away better informed.
Responding to alleged slop with more slop doesn’t decrease the total amount of slop on the internet.
You think I'm using AI to leave comments like this on HN?
"slop" doesn't mean "AI generated content", it means bad content, a waste of the reader's time. Grantparent's implication is that your comment was bad content, not that it was AI generated bad content.
I was riffing off of the meaning from https://noslopgrenade.com/ which made its way around the comments here on HN a few weeks ago.
Not the original commenter; but, at least for me, the idea is that when it’s written by humans we know that effort and care were put into communicating the news. Otherwise they could post a link to the docs and we could ask my flavor of LLM to summerize. No need for extra filler content. That why it’s slop and it’s different.
I don’t have access to my flavor of LLM on the train nor the time or budget to have it do the research and summary for me
Why are we all of a sudden pretending like pre-LLM era blogs were these pristinely well written pieces of art or even that effort and care was put into them? In most cases they were significantly less coherent and incomplete. Don’t get me started on the mess that was the communication of this particular company or one of their competitors like AWS.
Because we add humans enjoy variety. I read for entertainment, even technical posts like this one that I have no use for. I often trying to think about what the author may have been thinking when writing, why they introduced concepts in a specific order, what ideas might they have omitted, etc. It's personal and enjoyable. But now, when I detect the familiar writing style of what seems to be a gpt 5 model, that "parasocial" connection dies.
The LLM explained the core concept and features very well. But it was dull and boring to me, as I already have to read this writing style at work pretty much all day every day.
I hear you, and agree with your points, but do have to ask - what’s the point in complaining? See LLM slop as you called it, ignore it and move on. There’s plenty of more intimately authored content out there.
Why not complain?
>I don’t have access to my flavor of LLM on the train nor the time or budget to have it do the research and summary for me
Aren't you gonna let the LLM develop for you anyway? Why bother writing and reading a post at all?
> pretending like pre-LLM era blogs were these pristinely well written pieces of art
The point is the effort and care that the writer puts which differentiates it from automatically generated text. That matters because a human can sympathize and that leads to better understanding and greater connection. That's why a post is written.
> Don’t get me started on the mess that was the communication of this particular company or one of their competitors like AWS.
And we criticize those as well. Nothing's changed. Yesterday's bad content is today's slop (plus a mind boggling amount of investment, corruption and environmental side effects).
Honestly sounds to me like you have a bone to pick with AI in general. Negative sentiment on a particular LLM authored blog post muddies the waters and misrepresents your valid points. Not the way to do this IMO. Happy to be corrected.
Does anything beat a free static site hosted with Cloudflare workers at this point, performance wise?
Very difficult to beat if you don't process or store private information that should not be given to the US company.
now, waiting for opennext adapter maintainers to catchup with it
use vinext! (now 1.0 beta) https://vinext.dev/ https://x.com/James_Elicx/status/2073457440461303836
it already uses Workers Cache for the route-level ISR cache
Please please please write your own blogposts. I already read “but here’s the biggest unlock, and it’s the part that’s hardest to see” all day.
I just don’t understand why undermine your own announcements by delegating comms to the machine. It’s disrespectful to the reader.
There has to be some sort of "/humanize-text" skill they can pass the output to before publishing.
There is this one! Though I have not tested it. https://github.com/stephenturner/skill-deslop
I found it funny to just read through.
At least for me I don't really read these posts/docs, I just give the link to claude and it'll implement it regardless of wording
This is also 100% what I just did. In fact, I think companies should be releasing a human readable format as well as a machine readable format.
Machine readable: the text, font, media, formatting, is all machine readable.
I think you are looking is the signal separated from the noise. I read technical documents very quickly while having very high retention and comprehension. The AI slop and AI content generation is pushing my limits.
'AI summarization' is what I naturally or learned to do growing up. I read your request as 'human readable format' being something more conversational or perhaps with known intent: inform the human.
It is not possible. Socratic method is the better path to learning. AI can make it easier.
Suggestion: AI, summarize and then ask me questions about this topic in increasingly more difficult questions, and after passing the depth of this document push further into the deeper fundamentals and first principals of the topic.