The Invisible Hand of Dario: What Anthropic's Subsidy Cuts Mean for Event-Driven AI

If you're following AI news lately, you've likely heard about Anthropic putting the final death blow to the heavily subsidized agentic AI workloads many of us have been running on Max plans. While I, like many of us, am sad that the free lunch is over, the sign that this day was coming has been blinking for a while.

What it's got me thinking about is how we think about interactive vs. agentic workloads.

My definitions:

Interactive: You prompt, review response, prompt, review response. You're sitting in the pilot's seat, even if you're just clicking continue.

Agentic: You define what you want done, and define when (or by what event) it should be triggered. Every 30 minutes, every time you receive an email — this is your event-driven AI.

When thinking about most workloads we've built prior to AI, a lot of your costs (particularly the uncontrollable ones) were the interactive costs. You had to be up, you had to respond quickly, and you had to work. You weren't blowing your budget on background jobs off-peak or sending emails async. Your costs were tied to how much time humans spent using your product.

Agents change all that. Agents (in their current iteration) are basically interactive workloads run on a schedule. They're cron-agents.

Example: "Review my emails every 5 minutes and determine if there's anything relevant that I should respond to." — invoke, MCP call, review, close.

Interactively, you can only run that a few times a day (depending on your schedule). You might run it with a larger window (24 hours perhaps), but it's not necessarily going to be meaningfully different. As an agent though — you're able to drive a huge amount of compute with very little value out of it. And oh btw, most of us were just running that on Opus because why not, it's free.

Now that the invisible hand of Dario has reached in, we're going to see a shift.

#1) Cron → Events. You need to optimize for event-driven architectures. If you're running cron, it'll be too expensive. Your AI needs to react to events, particularly sparsely populated ones. This is one of the biggest unlocks IMO.

We go from:

Email Review Agent (Opus): "Review my emails every 5 minutes and determine if there's anything relevant that I should respond to. If there is, draft an email and then notify me that it's ready for review."

To:

Inbox Event Agent (Sonnet): "Review the email you just received. If it matches one of these 5 categories, hand it off to the associated agents. If not, ignore."

Daily Digest Agent (Opus): "Review my emails from the past 24 hours and generate an overview of items I need to prioritize and what's already been taken action on."

#2) Model Selection. You can no longer just run Opus for everything. That's too expensive. You'll still reach for it on your interactive workloads, but you're going to need lesser models for the rest. That means Haiku, Sonnet, DeepSeek, Kimi, etc.

#3) Harness Selection. While you can continue to run Claude Code with OpenRouter and other models, you're going to want to investigate other options as well. Codex, OpenCode, Hermes.

#4) The Power of Intermediate State. If you're still using Gmail or Google Calendar as your source of truth, you're going to quickly find it's expensive and error-prone. Instead, more AI will need to be focused on taking raw sources and generating easy-to-parse memories and databases.

Example: I have a "Travel Agent" who reviews my calendar and emails every day and updates my "Travel Memory Bank" — a record of all my itineraries and plans. It flags discrepancies like incorrect date bookings, or when I fail to update a hotel booking after changing a flight.

A few things this unlocks. One, the daily sync only has to reason about the deltas — what changed since yesterday — not re-derive my entire travel history from raw emails every time. That's the difference between a cheap nightly run and a wildly expensive one. Two, the Memory Bank itself becomes a cheap, queryable surface that other agents can hit. When my Surf Agent needs to investigate the best days for me to go surfing, it doesn't need to re-read every flight confirmation to know where I’ll be that week or what else is on my itinerary— it just queries the Memory Bank. Same for whatever agent I build next.

And — critically — I own the schema and the data. The Memory Bank lives in my Notion, structured the way I want it. If I trusted a single platform’s “memories” function, I'd be locked into whatever shape they decided was useful — which, conveniently, is whatever keeps me on their platform. It also means it can be exposed to whichever platforms I happen to be working across.

I've always been long on vendor-neutrality with my AI stack. The best models constantly change, the needs constantly change — you simply cannot invest in only one vendor. We'll continue to see the model vendors attempt to fully capture your entire stack with all-in-one solutions. They want to lock in your memories, your data, your connectors, your harnesses. This won't be the last time you'll wish you weren't locked to a single model…