The Marginal Cost of Correctness in the AI Era
Plus the price wars won't save the token usage and a potential replacement for WordPress
DeepSeek cut prices 75%. The 100x problem remains
The focus on managing AI-related costs has increased, and it finds an interesting landscape:
Anthropic newer models (Opus 4.8, Sonnet 5) generate more tokens than their predecessors
OpenAI claims their newer models are more token-efficient
Chinese models are gaining popularity due to their cost-performance ratio
Some analysts discuss the “inevitable” next step: price wars
DeepSeek’s approach stands out by its drastic price reduction. An already cheap model (by comparison) became even cheaper.
While this move is definitely not the last one and it is welcomed by those that look for alternatives, alone it still does not solve the 100x problem associated with the existing AI business model.
As seen in this article, the traditional flat rate model is still susceptible to the multiplication factor, where, for example, a single agentic interaction can translate into multiple tool calls and disproportional token usage.
Now multiply this by the number of times the user triggers the agentic workflow, and a company can see its margins being consumed by the average user.
The trend that is emerging is having cost as part of agentic orchestration design.
This includes:
Using some sort of task/complexity-based routing, so not all requests require the most expensive model, nor the highest thinking setting
Leveraging KV caching to benefit from discounts up to 90% on the input cost price
Using tools that reduce the amount of information sent or received
As a developer, I recommend being aware of the cost aspect and exercising curiosity by looking at the techniques described and seeing how to incorporate them in your AI SDLC.
Introducing EmDash, the WordPress successor
According to Cloudflare, WordPress powers over 40% of the Internet, with millions of sites and an ecosystem of plugins that expand its original blogging platform capabilities well beyond that.
In this article, Cloudflare presents its proposal for a replacement called EmDash based on Typescript and Astro.
Besides the language and framework of choice, it has some interesting architectural decisions:
Serverless (although it can be run on regular servers)
Plugin isolation via dynamic workers
The last one is the most needed, as the vast majority of the security vulnerabilities with WordPress installations originate in the plugins you install.
In EmDash, the plugins explicitly need to define what capabilities they need to use. Since they are defined statically, you know during installation time what it requests. Platform owners or administrators can then define what is allowed or not based on the user requesting the installation.
For example, imagine this plugin
It exposes two capabilities in the manifest:
capabilities: [”read:content”, “email:send”],
This is the way of the plugin says: “I need to read content, and I need to send an email. Nothing else.” The runtime enforces that, so ctx.email.send() works, but if the plugin tried to write to the database or make an HTTP call to some external host, it would be blocked.
The hooks section defines the access point:
hooks: {
“content:afterSave”: async (event, ctx) => { ... }
}
The hook is the only way the plugin gets invoked. Rather than running arbitrary code at any time, the plugin declares: “call me when this specific lifecycle event fires.”
EmDash also supports the x402 standard for internet-native payments. It is nice to have this baked in as the monetization model of content creation shifts in the age of AI.
Being a modern solution, we also find some agentic niceties:
Agent skills
EmDash CLI
MCP server
Those enable you to integrate its maintenance with your agent workflow.
The Marginal Cost of Correctness
The only constant in life is change, so it shouldn’t be a surprise that one should have healthy habits and periodically revisit practices to see what could be changed, what I should try, and so on.
As this article presents, in the past, aka before AI, many engineers could differentiate themselves with raw technical talent. With the widespread use of agents and their ever-improving cycle, that is no longer true, or at least, not all the time.
The idea is that if an agent can write correct code and know all the patterns and standards that exist, you should shift your approach towards being able to judge when things are not right and have the willpower to make them so.
The first one still requires you to know what right should look like, while the second expects that you still care enough about what is being produced to nudge it correctly where it needs to be.
Together, they take advantage of the cost to achieve correctness to be failing as the models and harnesses around them improve.
My advice: don’t forget the basics, keep reading, and experimenting with how to use the tools to your advantage.