Tygart Media

Tag: AI Agents

  • BYOK on OpenRouter: Provider Keys, Prioritization, and Fallback Strategy

    BYOK on OpenRouter: Provider Keys, Prioritization, and Fallback Strategy

    BYOK on OpenRouter: Bring-Your-Own-Key on OpenRouter means configuring direct provider credentials for any of dozens of supported providers, with per-provider prioritization, fallback chains, and the ability to pin specific BYOK keys to specific OpenRouter API keys (meaning specific agents). The result is a routing system where you can mix discounted enterprise contracts with pooled access, transparent to the calling code.

    This is a deep dive on the BYOK system inside OpenRouter. For the broader operator’s perspective on OpenRouter, see our OpenRouter operator’s field manual. For the underlying hierarchy that governs where BYOK lives, see the 5-layer mental model.

    What BYOK actually means here

    Most platforms use “BYOK” to mean bring your key for the one provider we support. OpenRouter means something more interesting: bring your key for any of dozens of providers, configure prioritization and fallback per provider, pin keys to specific agents and models, and let OpenRouter handle the routing logic when a key fails or runs out.

    The result is a routing system where you can mix and match. Run your high-volume agent through a discounted enterprise contract at Provider A. Route everything else through OpenRouter’s pooled pricing. Fall back to OpenRouter’s pool when your enterprise key is rate-limited. All transparent to the calling code.

    This is genuinely useful for an agency stack. It’s also where most teams misconfigure things in ways that don’t fail loudly.

    The Providers tab

    This is where the bulk of BYOK lives. Every provider — from AI21 at the top of the alphabet to Z.ai at the bottom — gets its own configuration card. Each card has two slots: Prioritized keys (tried first, before falling back to OpenRouter’s pooled access) and Fallback keys (tried last, after everything else fails).

    Per-key configuration is granular. Each key has:

    • A name (free text — use it well, you’ll thank yourself later)
    • The API key value itself
    • An “Always use for this provider” toggle that disables OpenRouter’s pooled fallback entirely for calls routed through this key
    • Filters: Models (All, or a specific subset) and API Keys (All OpenRouter API keys, or a specific subset)

    The filter system is the part most teams miss. You can pin a BYOK key to specific OpenRouter API keys, meaning specific agents. Read that twice. It means a single BYOK key can be the routing target for exactly one agent’s calls, while every other agent on the workspace continues using pooled access.

    This unlocks a powerful pattern for agency work: a client who has their own enterprise contract with a model provider can have their work routed exclusively through that contract, billed to that contract, while your other clients use pooled pricing. The routing happens at the provider layer, invisibly to the calling code.

    Prioritization and fallback in practice

    Here’s the order of operations OpenRouter uses when you call a model:

    1. Is there a Prioritized BYOK key for this provider, this model, and this calling key? Use it.
    2. If that key has “Always use for this provider” enabled, return any failure as-is. Don’t fall back.
    3. Otherwise, fall back to OpenRouter’s pooled access.
    4. If that fails too, try any Fallback BYOK keys configured for this provider.
    5. If everything fails, return the error.

    The “Always use for this provider” toggle is a sharp edge. Enabling it means a single failed enterprise contract — expired credentials, network issue at the provider, momentary rate limit — becomes a hard failure for every call routed through that key. Disabling it gives you graceful degradation but means your enterprise contract isn’t strictly enforced.

    Our pattern: enable “Always use” only for clients with hard data-policy requirements (no third-party touching of their data, ever). For everyone else, leave it disabled and let OpenRouter’s pooled access catch the failures.

    The Web Search slot (Firecrawl)

    The Providers tab has a second section that isn’t strictly BYOK: workspace-level Firecrawl integration. OpenRouter partnered with Firecrawl to provide 10,000 free credits per workspace, with a three-month expiry, contingent on accepting Firecrawl’s Terms of Service.

    This is wired at the workspace level, not per-key. Once accepted, any plugin that uses Web Search inherits the Firecrawl integration. Cheap, useful, easy to forget you enabled it.

    The mistake to avoid: assuming the 10,000 credits are forever. Three months. If you’re going to depend on this, plan for renewal.

    How to think about provider selection

    The temptation with dozens of providers is to spin up BYOK keys for every model you might ever want. Don’t.

    Start with three categories:

    Volume providers — the ones you call most. For us that’s Anthropic (Claude family) and Google (Gemini family). Worth getting BYOK keys for these even if you don’t have an enterprise contract; it makes the routing explicit and the costs auditable.

    Specialty providers — ones you call for specific jobs. We use OpenAI for some specific reasoning tasks. We use specialized model providers (Stepfun, others) for niche work. BYOK keys here only if you have a contract worth routing through.

    Experimental providers — everything else. Don’t bother with BYOK. Use OpenRouter’s pooled access. If a model from one of these providers becomes a regular part of your workflow, promote it to specialty.

    The audit story

    In March 2026 we ran a security audit on 122 Cloud Run services and discovered five of them had hardcoded OpenRouter keys in their environment variables — same key across all five. We stripped them, rotated, and re-scanned to zero.

    That was an OpenRouter key, not a BYOK provider key, but the lesson generalizes: API keys do not belong in environment variables on shared infrastructure. They belong in a secret manager with audited access. GCP Secret Manager, AWS Secrets Manager, HashiCorp Vault — pick one and use it.

    The standing rule we wrote afterward applies equally to BYOK provider keys: any key, any provider, any environment, lives in a secret manager. Period.

    Pinning keys to agents: the operational unlock

    The BYOK feature most teams underuse is the per-key filter system. You can configure a BYOK provider key to be used only by specific OpenRouter API keys.

    This sounds abstract until you map it to a real workflow:

    • Your content production agent runs through OpenRouter key A
    • Your customer support bot runs through OpenRouter key B
    • Your enterprise client has a contract with Anthropic and wants their work routed through that contract

    You create a BYOK Anthropic key for the enterprise contract. In the BYOK key’s filter, you specify “API Keys: only OpenRouter key C” (the key used by the agent serving that client). Now content production (key A) and customer support (key B) use OpenRouter’s pooled access. The enterprise client’s agent (key C) routes through the enterprise contract.

    No code changes. No service restarts. Just routing config at the provider layer.

    This is the kind of pattern that pays for OpenRouter’s existence in the stack. Most teams discover it only after they’ve outgrown a simpler setup. Start with it from day one if your shape looks anything like an agency.

    What to do today

    If you’re getting started with BYOK on OpenRouter:

    1. Identify the two or three providers you call most. Get BYOK keys for those.
    2. Store every key in a secret manager. Not in code. Not in env vars on shared infra.
    3. Use the per-key filter system from the start. Don’t let one BYOK key get used by every agent unless you actually want that.
    4. Leave “Always use for this provider” off unless you have a hard policy reason to enforce it.
    5. Set a calendar reminder for any time-limited credits (looking at you, Firecrawl).

    The BYOK system is one of the genuinely useful features on the platform. Treat it like the routing layer it is, not like a credentials dump, and it’ll pay for the setup time many times over.

    Frequently asked questions

    What is BYOK on OpenRouter?

    BYOK (Bring-Your-Own-Key) on OpenRouter means configuring direct provider credentials for any supported provider. OpenRouter then routes calls through your provider key instead of (or before falling back to) its pooled access. You can configure prioritization, fallback chains, and per-agent pinning.

    Should I use BYOK on OpenRouter even without an enterprise contract?

    For the providers you call most, yes. Even without a discount, BYOK makes the routing explicit and the costs auditable on your provider’s billing rather than buried in OpenRouter’s aggregate. For providers you barely call, don’t bother — OpenRouter’s pooled access is simpler.

    What does “Always use for this provider” actually do?

    It disables OpenRouter’s pooled fallback for any call routed through that BYOK key. If your enterprise contract fails for any reason — expired credentials, rate limit, network issue — the call returns the error instead of silently falling back to OpenRouter’s pool. Useful for hard data-policy requirements; risky for general reliability.

    Can I pin a BYOK key to specific agents?

    Yes. The per-key Filters section lets you specify which OpenRouter API keys (meaning which agents) can route through this BYOK key. This unlocks the pattern of running one client’s work through their enterprise contract while every other agent uses pooled access — all transparent to the calling code.

    How should I store BYOK provider keys?

    In a secret manager — GCP Secret Manager, AWS Secrets Manager, HashiCorp Vault. Never in environment variables on shared infrastructure. We learned this from a March 2026 audit that found five Cloud Run services with hardcoded keys baked into env vars. Standing rule now: any key, any provider, any environment, lives in a secret manager.

    See also: The Multi-Model AI Roundtable: A Three-Round Methodology for Better Decisions · What We Learned Querying 54 LLMs About Themselves (For $1.99 on OpenRouter)

  • How We Actually Use OpenRouter in Production: An Operator’s Field Manual

    How We Actually Use OpenRouter in Production: An Operator’s Field Manual

    What OpenRouter actually is: A routing and policy layer that sits between your code and AI model providers. It replaces the place where you’d otherwise write direct API calls to Anthropic or Vertex AI, adding budget caps, guardrails, prompt-injection filtering, PII redaction, model fallbacks, and observability hooks — with access to hundreds of models behind one unified endpoint. It does not replace your memory system, your hosting environment, your operator console, or the models themselves.

    The 30-second version

    OpenRouter is one of the most useful AI infrastructure tools we’ve adopted, but the value lives at exactly one layer of the stack: the model-calling layer. It replaces the place where you’d otherwise write fetch("https://api.anthropic.com/...") or call Vertex AI directly. It does not replace your memory system, your hosting environment, your operating console, or the models themselves. Get that framing wrong and you’ll build a house of cards. Get it right and you’ve added budget controls, guardrails, observability, and hundreds of models with one config change per agent.

    This is how we use it across a stack that runs 27+ WordPress client sites, autonomous content pipelines, multi-model decision tools, and an autonomous behavior promotion system. None of this is theory. Every number in this article comes from our own usage logs.

    What OpenRouter actually is

    Strip away the marketing and OpenRouter is a routing and policy layer for AI model calls. You point your code at one endpoint — openrouter.ai/api/v1/chat/completions — and OpenRouter handles model selection, provider fallback, budget enforcement, content filtering, and observability.

    It is not a model. It is not a runtime. It is not a database. It is a smarter middle layer between your code and the dozens of providers whose models you might want to call.

    The mistake we almost made early on was framing it as “replace GCP and Notion with this.” That framing is wrong in a specific way that’s worth naming: OpenRouter has no servers, no operational memory, no execution environment, no isolated network. It has hundreds of models behind one API and a thoughtful policy layer in front of them. That’s the entire product, and it’s enough — at the right layer.

    The 5-layer hierarchy nobody tells you about

    When you log into OpenRouter, the UI presents a flat set of menus. The actual mental model — the one that maps to real operational decisions — is a five-layer hierarchy:

    Organization is the top. Sovereign billing and member context. We run two: one personal, one for Tygart Media. The personal org has 48 API keys and a balance; the Tygart Media org has empty balance but exposes Members management that personal accounts can’t access. If you’re operating as an agency, you want the agency org as primary so you can add seats.

    Workspaces sit inside organizations. They’re segmented domains for guardrails, BYOK provider keys, routing rules, and presets. Most accounts run on a single Default Workspace and never think about this layer. The moment you operate across multiple businesses with different data policies, workspace segmentation becomes a real decision.

    Guardrails are workspace-level enforcement policies. Four categories: Budget Policies, Model and Provider Access, Prompt Injection Detection, and Sensitive Info Detection. By default they’re all unconfigured, which means your workspace has no enforced budget cap, no provider restrictions, and no PII filtering. This is fine until it isn’t.

    API Keys are per-agent identity. Each key carries a credit cap, a reset cadence, and a guardrail overlay. The mental model that matters: one autonomous behavior = one API key. If a scheduled task starts hemorrhaging tokens, the cap on its key contains the damage to that key alone.

    Presets are versioned bundles of system prompt, model, parameters, and provider config. You call them as "model": "@preset/name" in any API call. They’re the closest thing OpenRouter has to a software release artifact — a thing you can version, test, and roll back.

    That hierarchy is the entire operational surface. Everything you’d want to do with the platform happens at one of those five layers. Confuse them and you’ll spend hours hunting for a setting that lives at a different tier than you think.

    What OpenRouter replaces (and what it doesn’t)

    The honest answer: OpenRouter replaces the direct API call. Nothing more, nothing less.

    In our case, every scheduled task, every skill that calls a model, every Claude Project — all of them used to make direct calls to Anthropic’s API or Vertex AI. OpenRouter sits in front of those calls and adds budget caps, guardrails, prompt-injection filtering, PII redaction, model fallbacks, observability hooks, and access to a model catalog of hundreds of options instead of the handful any single provider exposes.

    What it does not replace:

    Your memory system. Notion remembers; OpenRouter doesn’t. OpenRouter’s logs are call-level telemetry — what model was called, what it cost, what the response was. That’s not operational memory. It can’t tell you “this customer pitch was sent three weeks ago and got no response.” For that, you need a real second brain.

    Your hosting environment. OpenRouter has no servers, no WordPress, no database, no VPC. If you’re running a fortress architecture on GCP — VPC isolation, Cloud SQL, Cloud Run services — none of that goes away. OpenRouter sits next to that infrastructure, not in place of it.

    Your operator console. Wherever you actually do the work — Claude in chat, your terminal, your IDE — that surface stays. OpenRouter is a transport layer for model calls, not a place you live.

    The models themselves. OpenRouter is one path to reach Anthropic’s Claude; Vertex AI is another; the direct Anthropic API is a third. They’re interchangeable transports. The model is the model.

    Mapping OpenRouter to an autonomous behavior system

    Here’s where the framing gets interesting. We run an autonomous behavior system where every long-running task — a scheduled content pipeline, an SEO audit, a publishing job — sits on a promotion ledger that tracks its trustworthiness over time. Tier C behaviors run autonomously. Tier B requires a human in the loop. Tier A is proposal-only.

    OpenRouter maps to that system with almost no friction:

    • Each behavior becomes a versioned Preset — system prompt, model, parameters, all bundled and versioned.
    • Each preset is bound to its own API Key with a monthly credit cap and reset cadence.
    • That key sits under a Workspace whose Guardrail enforces the appropriate data policy.
    • Observability is broadcast to a webhook that writes back to the operational memory layer.

    The result: when a behavior misbehaves — hits its spend cap, trips a policy violation, gets blocked by Sensitive Info Detection — the failure is auto-logged at the routing layer and surfaced to the operator console. The promotion ledger row catches the gate failure and demotes the behavior automatically.

    This is the concrete answer to a question every operator running autonomous AI work eventually asks: how will I know when something goes wrong? The answer is: you build the routing layer so that going wrong is itself a signal.

    The 270/238 reality check

    A small piece of grounding before we go further. As of mid-May 2026, our personal OpenRouter org showed a balance of $31.93 remaining of $270 total credits purchased. That’s $238.07 of actual usage across roughly two months. Spread across 48 API keys, that’s an average of about $5 per key.

    The highest-spend key was a testing key at $83.26. The next was a development key at $33.05. Most keys had spent less than $1. That distribution tells you something true about real-world AI operations: a handful of behaviors do most of the work, and the long tail of agents barely registers.

    We mention this for one reason: if you’re evaluating OpenRouter, the cost is not the story. The cost is small. The story is whether the policy layer is worth wiring into your stack. Our answer is yes — but the work of wiring it is real, and it requires you to first understand what layer you’re wiring.

    The Cloud Run reality

    One real-world note that any production team needs to internalize: when we ran AI calls from Cloud Run services on GCP, we occasionally hit 402 responses from OpenRouter that we did not hit when calling Anthropic’s API directly from the same services. We don’t have conclusive evidence of where the issue originated — Cloud Run’s egress IP ranges are widely shared and trip fraud-detection thresholds at many providers, including direct calls to first-party APIs. The lesson is not about OpenRouter specifically. The lesson is that production routing requires deployment-context testing.

    Our policy now: for services where reliability is mission-critical, we maintain a fallback path that can switch routing layers under failure. OpenRouter is the default. Direct Anthropic is the fallback. The decision logic lives in the service itself, not in OpenRouter’s config. This is defense in depth, not a critique of any one provider.

    The standing rule we wish we’d had earlier

    In March 2026 we ran a security audit on 122 Cloud Run services and discovered five of them had hardcoded OpenRouter API keys baked into environment variables — all sharing the same key. We stripped the keys, rotated, and re-scanned to zero. Then we wrote a standing rule into operational memory:

    OpenRouter is off-limits for any task without explicit per-task permission. Image generation always goes through Vertex AI.

    The reason for the second half of that rule deserves naming. Image generation via OpenRouter is technically possible, and the model variety is appealing. But image calls are expensive, latency-sensitive, and easy to fire by accident in a loop. One misconfigured behavior can drain a development budget in a single session. Vertex AI’s first-party image generation runs through GCP service accounts with project-level budget alerts, which gives us a natural circuit breaker. We use OpenRouter for the right jobs. We use Vertex for image work.

    This is the kind of operational rule you only write after you’ve lost money to a runaway script. Save yourself the lesson.

    When OpenRouter is the right answer

    Use OpenRouter when:

    • You want model variety and a unified API across providers
    • You need workspace-level budget caps that work across many keys
    • You want PII detection and prompt-injection filtering at the routing layer instead of in every service
    • You need observability broadcast to your existing stack (we ship to webhooks)
    • You’re running an autonomous behavior system that needs per-agent identity and per-agent budget enforcement
    • You want the option to swap models without redeploying code

    When it isn’t

    Don’t reach for OpenRouter when:

    • You only call one model from one app and don’t need policy enforcement
    • You need single-digit-millisecond latency (the extra hop matters)
    • You’re running image generation at scale (use the first-party provider directly)
    • You need network isolation guarantees that only your own infrastructure can provide
    • You’re deploying from an environment with shared egress IPs to a provider that flags those ranges (test first)

    The bottom line

    OpenRouter is excellent at exactly one thing: being a thoughtful policy layer between your code and the AI models you call. Don’t ask it to be more than that. Don’t replace your memory, hosting, console, or models with it. Wire it into the model-calling layer of an existing system that already has those other pieces sorted, and you get budget controls, guardrails, observability, and hundreds of models with about a day’s worth of integration work.

    The framing that works: the model layer of an existing system. Not the system itself.

    If you’re operating multiple autonomous AI behaviors and you don’t yet have per-agent budget caps and per-agent observability, OpenRouter is probably the fastest path to getting them. If your stack is one app calling one model, you’re paying for complexity you don’t need yet.

    Going deeper

    This pillar is the operator’s overview. Each of the five layers and the major workflows we built on top of OpenRouter has its own deep dive:

    Frequently asked questions

    What is OpenRouter and what does it do?

    OpenRouter is a routing and policy layer for AI model API calls. It sits between your application code and AI providers like Anthropic, OpenAI, and Google, providing one unified API endpoint that handles model selection, budget enforcement, guardrails, fallback routing, and observability across hundreds of models from dozens of providers.

    Does OpenRouter replace direct Anthropic or OpenAI API calls?

    Yes, that’s exactly what it replaces. Your code calls one endpoint (openrouter.ai/api/v1/chat/completions) instead of provider-specific endpoints. The model is selected via a parameter rather than the URL. Everything else about your stack — your memory system, hosting, and operator console — stays the same.

    Can OpenRouter replace GCP, Notion, or my hosting infrastructure?

    No. OpenRouter is a routing layer for model calls. It has no servers, no database, no operational memory, and no network isolation. If you’re running a fortress architecture on GCP with VPC isolation, Cloud Run services, and Cloud SQL, OpenRouter sits alongside that infrastructure, not in place of it.

    How expensive is OpenRouter in practice?

    For most operational workloads the platform fee is negligible compared to the underlying model costs. Our personal organization spent $238 over roughly two months across 48 API keys serving multiple autonomous behaviors. The distribution is heavily skewed — a few keys do most of the work, and the long tail barely registers. Cost is rarely the decision factor; the policy layer is.

    What is the right way to think about OpenRouter API keys?

    One autonomous behavior, one key. Each key gets its own credit cap and reset cadence. When a scheduled task starts hemorrhaging tokens, the cap on its key contains the damage to that key alone. Sharing one key across all services is the single fastest way to lose visibility and bound risk.

    Should I use OpenRouter for image generation?

    We don’t. Image generation runs through first-party providers (Vertex AI in our case) where project-level budget alerts give a natural circuit breaker. Image calls are expensive, latency-sensitive, and easy to fire by accident in a loop. The routing layer is for text-completion workloads where the policy benefits compound.

    What’s the deal with Cloud Run and OpenRouter 402 errors?

    Cloud Run egress IP ranges are widely shared, and they sometimes trip fraud-detection thresholds at various providers — including direct calls to first-party APIs, not just OpenRouter. The lesson is that production routing requires deployment-context testing. Maintain a fallback path that can switch routing layers under failure, and you’ve got defense in depth instead of a single point of failure.

  • Claude Code Case Studies: What the Numbers Actually Say in 2026

    Claude Code Case Studies: What the Numbers Actually Say in 2026

    Most “Claude Code changed my life” posts are vibes. The interesting case studies are the ones with a number attached — a PR count, a token spend, a defect rate, a codebase size. After spending the week reading every concrete writeup I could find and cross-referencing them against Anthropic’s own internal usage report, three patterns hold up. Everything else is marketing.

    Here is what the credible Claude Code case studies actually say, what they share in common, and where the wheels come off when teams try to repeat them.

    Case 1: The 350k-line solo codebase

    The most cited solo-developer case study right now is a maintainer of a 350,000+ line codebase spanning PHP, TypeScript/React, React Native, Terraform, and Python. Since August 2025, 80%+ of all code changes in that codebase have been written by Claude Code — generated, then corrected by Claude Code after review, with only minimal manual refactoring. The author has been working in commercial software for 10+ years, so this is not a beginner overstating things.

    The two operational constraints they call out are the ones that matter:

    • Context selection is the job. A 200k token context window is less than 5% of a codebase this size. Include the files that show your patterns, exclude anything irrelevant, and accept that “too much context” degrades output as badly as “too little.”
    • Speed parity is the gate. If an LLM implementation isn’t at least as fast as doing it yourself, you’ve added a tool and lost time. They keep working documents to 50–100 lines and start every task with the bare minimum context.

    This is the case study to send to anyone asking “does Claude Code work on legacy code.” The answer is yes, but only after you treat context curation as a first-class engineering activity.

    Case 2: Anthropic’s own internal teams

    Anthropic published a usage report covering ten internal teams. It is the highest-signal document in the ecosystem because every example is from a team that has unlimited access and zero incentive to oversell it. The patterns worth stealing:

    • Data Infrastructure lets Claude Code use OCR to read error screenshots, diagnose Kubernetes IP exhaustion, and emit fix commands. The team is not writing prompts about Kubernetes — they’re handing Claude a screenshot and a goal.
    • Growth Marketing built an agentic workflow that processes CSVs of hundreds of existing ads with performance metrics, identifies underperformers, and uses two specialized sub-agents to generate replacement variations under strict character limits. Sub-agents matter here — a single agent loses the constraint discipline.
    • Legal built a prototype “phone tree” to route team members to the right Anthropic lawyer. Non-engineering team, real internal tool, shipped.
    • Finance staff describe requirements in natural language; Claude Code generates the query and outputs Excel. No SQL skill required from the requester.

    The Claude Code product team itself uses auto-accept mode for rapid prototyping but explicitly limits that pattern to the product’s edges, not core business logic. The RL Engineering team reports auto-accept succeeds on the first attempt about one-third of the time. That’s the honest number to hold onto when someone tells you their agent “just works.”

    Case 3: The Sanity staff engineer’s six-week journey

    The single most useful sentence in any Claude Code case study this year came from a staff engineer’s six-week writeup at Sanity: “First attempt will be 95% garbage.” That’s not a complaint — it’s an operating manual. The engineer’s workflow runs three or four parallel agents, treats every first pass as a draft to be re-prompted, and reserves human attention for architecture and steering rather than typing.

    This is also the case study that matches the Pragmatic Engineer’s February 2026 survey of 15,000 developers, which ranked Claude Code as the most-used AI coding tool on the market. The teams who report the biggest gains are not the ones treating it like autocomplete. They’re the ones running multiple threads, accepting that most first drafts are throwaway, and putting their senior judgment on review rather than authorship.

    What every credible case study has in common

    Cross-reference the three above with the dozen other writeups that include real numbers and the same five operational habits show up every time:

    • A written context doc. Every successful team has something Claude reads first — a CLAUDE.md, a .clauderules file, a project README that defines patterns and conventions. Teams without one get inconsistent output.
    • Sub-agents for constraints. One agent that has to remember the character limit, the style guide, the schema, and the deadline will drop one of them. Two agents — generator and constraint-checker — won’t.
    • Real review on the way in. The 80% figure from the 350k-LOC case includes “corrected by Claude Code after review.” Nobody is shipping unreviewed agent output to production and reporting wins.
    • A measurement loop. Faros and Jellyfish reports both show teams using Claude Code analytics to track PRs and lines shipped with AI assist. The teams that measure ship more; the teams that don’t, drift.
    • Honest scoping. Auto-accept on edges, synchronous prompting on core business logic. Every team that ignores this distinction generates the “tech debt nightmare” posts.

    Where the case studies break down

    Two warnings from the data. First, Jellyfish’s AI Engineering Trends report shows a 4.5x increase in companies running agentic coding workflows, but most engineering teams using these tools spend $200–$600 per engineer per month and report a 1.6x productivity multiplier — not the 10x that vendor marketing implies. The case studies you read are the wins; the median outcome is more modest.

    Second, the model version you run matters more than any workflow trick. As of this week the flagship is claude-opus-4-7, the workhorse is claude-sonnet-4-6, and the fast option is claude-haiku-4-5-20251001. Opus 4.7 lifted resolution on a 93-task coding benchmark by 13% over Opus 4.6 — including four tasks that neither Opus 4.6 nor Sonnet 4.6 could solve. Teams running on stale model strings are leaving real capability on the table.

    The takeaway

    If you only steal one thing from the credible case studies, steal the context discipline. The 350k-LOC maintainer keeps documents to 50–100 lines. Anthropic’s own teams use sub-agents to enforce constraints. The Sanity engineer runs parallel agents and treats first drafts as garbage by default. None of these patterns require a special prompt or a hidden flag. They require deciding, before you start a task, what Claude is allowed to see and what it isn’t.

    That’s the whole game. The teams shipping 80% of their code with Claude Code aren’t using a better model — they’re feeding it a better context.

    📖 Recommended Reading in Claude Code Insider

  • The Three-Legged Stack: Why I Run Everything on Notion, Claude, and Google Cloud

    The Three-Legged Stack: Why I Run Everything on Notion, Claude, and Google Cloud

    Last refreshed: May 15, 2026

    A surveyor's tripod with copper, porcelain, and steel legs planted on rocky ground at sunrise above the clouds — representing the Notion, Claude, and Google Cloud three-legged stack
    The three-legged stack — Notion, Claude, Google Cloud — is what’s actually holding up the operation.

    I run a portfolio of businesses — restoration companies, content properties, creative ventures, a software platform, a comedy site, a few things I haven’t decided what to do with yet — on three legs. Notion. Claude. Google Cloud. That’s it. Everything else either fits inside that triangle or it doesn’t last in my stack.

    This article is the doctrine. Not “here’s a list of tools I like.” The actual operating philosophy of why this specific three-piece architecture is what holds the work up, where each leg’s job ends, and what I learned the hard way about which tools belong on the floor instead of the table.

    If you’re trying to decide what your own AI-driven operating stack should look like, what follows is what I’d tell you over coffee.

    Why three legs and not two, four, or twelve

    I tried twelve. I tried four. I lived for a while with two. Three is what’s left after everything else either failed in production, got absorbed into one of the three legs, or became overhead that didn’t pay for itself.

    The reason it’s not two is that you need a place where state lives, a place where reasoning happens, and a place where heavy compute runs. If you collapse two of those into one tool, the tool has to be excellent at both jobs and almost nothing is. If you keep them separate, each tool gets to be excellent at its actual job.

    The reason it’s not four is that every additional leg multiplies the surface area of what can break, what needs to be monitored, what needs to be paid for, what needs to be learned by every new person you bring in. Four legs sounds like it would be more stable but it isn’t. It’s more rigid. Three legs sit flat on uneven ground.

    The reason it’s not twelve is that I tried that and the cognitive cost of remembering which tool did which job was higher than the work the tools were supposed to be saving.

    Notion is the system of record

    State lives in Notion. That’s the rule. If a piece of information needs to exist tomorrow, it goes in Notion first.

    That includes the things you’d expect — clients, projects, content pipelines, scheduled tasks, the Promotion Ledger that governs which autonomous behaviors are running at what tier — and a lot of things you might not. Meeting notes go in Notion. Random ideas at 11pm go in Notion. The reasons I made a particular architectural decision six months ago go in Notion. Anything I might want Claude to read later goes in Notion.

    The reason this leg has to be Notion specifically — and not, say, a folder of markdown files, or a Google Doc, or Airtable — is structured queryability paired with human-readable rendering. Notion databases let me describe my business in shapes (a content piece is a row, a project is a row, a contact is a row) while keeping every row a real document I can read and write to like a normal page. That dual nature is rare. Most systems force you to pick between structured and prose. Notion lets the same object be both.

    The May 13, 2026 Notion Developer Platform launch made this leg even stronger. Workers, database sync, and the External Agents API mean the system of record can now do active things on its own and host outside agents (including Claude) as native collaborators. Notion stopped being a passive document store and started being a programmable control plane. That’s a big deal for this architecture and I wrote about it in my piece on the platform launch.

    Claude is the reasoning layer

    Claude does the thinking. That’s the rule on the second leg.

    Anywhere I would otherwise have to write something from scratch, decide between options, summarize a long document, generate code, audit content, or do any task that requires a brain rather than just a database query, Claude is the first thing I reach for. The work happens in Claude. The result lands in Notion.

    I want to be specific about why Claude and not “an LLM” generically. I have used the others. I have used GPT in production. I have used Gemini in production. They all work. Claude is what I picked, and the reasons aren’t religious.

    First, the writing is recognizable. Claude’s voice has a calibration to it that the others don’t quite have for the kind of work I’m doing — long-form content, operator-voice editorial, technical explainers. I can edit a Claude draft to feel like me much faster than I can edit the others.

    Second, the agentic behavior is the most stable across long sessions. Claude Managed Agents and Claude Code in particular are willing to think for a long time without losing the plot. For multi-step work that involves reading a lot of context, holding it, and acting on it across many turns, the difference is real.

    Third, the tooling around Claude — Claude Code, Cowork, the Agent SDK, MCP — is the most operator-friendly of the bunch right now. The other models will catch up. As of May 2026, Claude is the best fit for how I actually work.

    Fourth, and this matters more than people give it credit for: I am willing to bet on Anthropic the company. I am betting my operations on the leg that bears my reasoning load. Whose roadmap I’m comfortable with, whose values I find legible, whose engineering culture I trust to keep shipping the thing without breaking it underneath me — that’s a real input to the decision, not a soft preference.

    Google Cloud is the substrate

    The third leg is the heavy one. Google Cloud is where the things live that have to be reliable in a way that Notion can’t be and Claude isn’t supposed to be.

    The 27 WordPress sites I manage all live on GCP infrastructure. The knowledge-cluster-vm hosts five interconnected sites. The proxy that lets Claude talk safely to WordPress sites runs on Cloud Run. The cron jobs that fire scheduled work, the Python services that handle image pipelines, the AI Media Architect that runs autonomously — all on GCP. Anything that involves real compute, regulated data, behind-a-firewall execution, or sustained reliability lives on the third leg.

    The reason this leg has to be a real cloud and not just a laptop or a Hetzner box is that I run autonomous behaviors. Tier C autonomous behaviors run unattended, which means the substrate they run on has to be more reliable than I am. GCP gives me that. It’s also where Anthropic’s Claude is available through Vertex AI, which means there’s a path where the entire stack can run inside one cloud’s perimeter when that becomes operationally necessary.

    I picked GCP specifically over AWS or Azure for a few reasons. Vertex AI’s first-party Claude access matters to me. The GCP control surface is the one I’m fastest in. Cost-wise it’s been competitive for the workloads I run. None of those are universal — your third leg might be AWS, or Azure, or a hybrid with on-premise hardware. The doctrine isn’t “use GCP.” The doctrine is “have a real substrate that can carry the heavy work.”

    How the three legs hold each other up

    The thing that makes this an actual stack and not just three tools is the load each leg puts on the others.

    Notion holds Claude’s memory. Claude doesn’t have persistent memory across sessions in any deep way — what it remembers is what’s in the prompt and what it’s allowed to look up. Notion is where I put the things I want Claude to know tomorrow. Project briefs, brand voice docs, the Promotion Ledger, client context, my preferences. When Claude starts a session it looks at Notion. When the session is done, what mattered gets written back to Notion. The memory leg is Notion. Without it, Claude is amnesiac and has to be re-briefed every time.

    Claude does the work that Notion can’t and that GCP isn’t shaped for. Notion can hold structured data and run light automation through Workers and database sync. Notion can’t write a 2,000-word article in your voice. GCP can run a reliable cron job and host whatever you want on Cloud Run. GCP isn’t going to read your existing client notes and propose a follow-up email. The reasoning leg is Claude. Without it, you have a database and a server and no one to think.

    GCP holds the things that have to keep running when nobody is watching. Notion can’t host a WordPress site. Claude can’t run a cron job by itself. The compute leg is GCP. Without it, the autonomous behaviors that make this a system instead of a tool collection have nowhere to live.

    Each leg fails gracefully into the others. If Notion is down, GCP keeps the live workloads running and Claude can still do work in a session. If Claude is down, Notion still holds state and GCP still runs the autonomous infrastructure. If GCP is down, the websites are unreachable but the planning surface (Notion) and the reasoning surface (Claude) still let me figure out what to do about it. No single failure takes the whole operation down.

    What I tried that didn’t make the cut

    For honesty’s sake, here’s what I had in earlier versions of the stack that’s no longer there:

    Zapier and Make for orchestration. They worked. They cost real money at the volumes I was running. The May 13 Notion Developer Platform launch absorbed most of what I was using them for into native Notion functionality. What’s left I do with Cloud Run jobs.

    Multiple LLMs for “best tool for the job.” I went through a phase of routing different work to different models. The cognitive overhead of “which one for this task” was higher than any quality gain from the routing. I picked Claude and stayed.

    Custom CRMs and project management tools. Tried several. None of them did the job better than a well-structured set of Notion databases with the right templates and views. The CRM is in Notion now. The project management is in Notion. The pipeline tracking is in Notion.

    A second cloud “for redundancy.” Sounded smart, was actually overhead. If GCP goes down catastrophically I have bigger problems than my stack. Single-cloud is fine for a small operator portfolio.

    Local AI models for cost savings. The math didn’t work for me. I have a powerful workstation that can run open models, but the time cost of running them, debugging them, and maintaining them outweighed the API savings. Claude through the subscription and through Vertex when I need it is what I pay for now.

    Why this matters beyond my own operation

    I write about this not because anyone is required to copy it but because the shape of the answer — three legs, one for state, one for reasoning, one for compute — generalizes.

    If you’re a solo operator, a small agency, a content business, a service business with operational complexity, this shape works. Your specific tool choices for each leg will be different. Maybe your state lives in Airtable instead of Notion. Maybe your reasoning leg is GPT or Gemini. Maybe your substrate is AWS or Vercel or your own bare metal. The three-leg architecture survives the substitutions.

    What doesn’t survive substitutions is collapsing the legs. Putting state and reasoning in the same tool (anyone who has tried to use ChatGPT as their CRM knows what I mean) doesn’t work. Putting reasoning and compute in the same tool means you’re either compromising on reasoning to keep compute simple or compromising on compute to keep reasoning fluid. The separation is where the strength is.

    Where the stack is going next

    Three things I’m watching:

    Notion’s platform maturation. The May 13 launch is version 1 of what Notion as a programmable platform looks like. If Workers and database sync continue to grow into real automation surface, more of what I do on GCP could move to Notion. I don’t expect the heavy stuff to migrate, but the lightweight glue is moving in that direction.

    Claude’s agentic capabilities. Claude Managed Agents and the Agent SDK are getting better fast. Some of what I currently script in Python on Cloud Run will move into Claude-native agentic loops as the agents become more capable of long-running, reliable work without supervision.

    The fortress pattern on GCP. The ability to run Claude inside a private GCP perimeter via Vertex AI is becoming more important as I take on regulated industry work. The substrate leg is staying GCP precisely because of this — the perimeter matters.

    The stack will evolve. The three-leg shape probably won’t.

    Frequently Asked Questions

    Why Notion and not Airtable, Coda, or Obsidian?

    Notion’s combination of structured databases and human-readable page rendering is what makes it work as both a database and a knowledge base for Claude. Airtable is more powerful as a database but worse as a document. Coda is similar in spirit but smaller community and tooling around it. Obsidian is excellent for personal knowledge but doesn’t have the multi-user, structured-database surface I need to run businesses on.

    Why Claude and not GPT or Gemini?

    Voice quality for the kind of writing I do, agentic stability across long sessions, operator-friendly tooling (Claude Code, Cowork, MCP), and Anthropic’s roadmap and culture being legible to me. The other models work; Claude is what I picked.

    Why Google Cloud and not AWS?

    Vertex AI’s first-party Claude access, GCP’s control surface fitting how I work, competitive cost on my specific workloads. AWS would also work. The doctrine is “have a real substrate,” not “use GCP specifically.”

    Can a small operator afford this stack?

    Yes. Notion is $10/seat. Claude Pro is $20/month, Max is $100-$200. GCP costs scale with what you actually run — my 27-site infrastructure runs in the low three figures monthly. Total monthly stack cost for a solo operator running this architecture is well under what most people pay for a single SaaS tool that does only one of these jobs.

    What if one of the legs goes away or pivots badly?

    Each leg is replaceable. The shape of the stack matters more than the specific brands. If Notion pivots away from being useful, the state leg moves somewhere else. If Anthropic pivots, the reasoning leg moves. If I leave GCP, the substrate leg moves. The architecture is durable; the specific tool choices are not load-bearing in the way the architecture is.

    How long did it take to settle on this shape?

    Roughly two years of trying things. I write the doctrine now because I want my own next iteration to start from this shape rather than rebuilding it from scratch. If you want to skip those two years, this is the shortcut.

    Related Reading

  • Notion Developer Platform Launch (May 13, 2026): What Changes for Claude Users and the Three-Legged Stack

    Notion Developer Platform Launch (May 13, 2026): What Changes for Claude Users and the Three-Legged Stack

    Last refreshed: May 15, 2026

    The Three-Legged Stack: Claude, Notion, GCP - walnut stool with copper, porcelain, and steel legs representing the Tygart Media AI operating stack
    Notion’s May 13 Developer Platform launch reshapes how the Notion + Claude + GCP stack fits together.

    On May 13, 2026, Notion shipped what is, structurally, the biggest change to how Notion fits into an AI-driven operating stack since the original Notion AI launch. Version 3.5 — the Notion Developer Platform — turns Notion from a workspace that you operate into a platform that other agents can operate inside. Claude is one of the launch partners.

    This article is written from inside the practice of running a business on a three-legged stool of Notion, Claude, and Google Cloud. The Developer Platform launch matters to that stool in specific ways, and most of the day-one coverage is missing them. The goal here is to pin down what shipped, what it actually changes for an operator who already runs Claude against Notion, and where the seams are between this platform and the way most of us were already wiring things together.

    What Notion actually shipped on May 13, 2026

    From Notion’s own release notes for version 3.5 (verified May 15, 2026), the Developer Platform comprises four meaningfully distinct pieces:

    Workers. A cloud-based runtime that runs custom code inside Notion’s infrastructure. Workers is how you take a Notion-resident workflow and bind real compute to it — running on a schedule, reacting to a database trigger, fanning work out to other systems — without standing up your own infrastructure for the runtime.

    Database sync. Notion databases can now pull live data from any API-enabled external source. The thing that used to require a Zapier or Make.com bridge becomes a property of the database itself.

    External Agents API. The piece that matters most for Claude users: an outside AI agent can appear and operate inside the Notion workspace as a first-class collaborator. Claude is one of the launch partners, alongside Cursor, Codex, and Decagon.

    Notion CLI. A command-line tool through which both developers and agents interact with the platform. Available across all plan tiers.

    The packaging detail worth noting: Workers and the Developer Platform deployment surface are limited to Business and Enterprise plans, but the External Agents API and the CLI are available on all tiers. The whole platform is free to use through August 11, 2026.

    The shift in framing, in operator terms

    Before May 13, the standard pattern for getting Claude to work with Notion looked like this: install a Notion MCP server, point Claude Code at it, and use Claude as the active driver that reads from and writes to Notion through tool calls. Notion was the database, Claude was the agent, MCP was the wire.

    After May 13, the relationship can flip. The External Agents API lets Claude appear inside Notion — not as an external tool you switch to, but as a collaborator your team can assign work to from the same task board where you assign work to humans. The wire is no longer “Claude reaches into Notion when called.” It’s “Notion can hand work to Claude the same way it can hand work to a person.”

    For an operator running a second-brain architecture, that’s a meaningful change. It moves Claude from a tool you invoke into a participant your system operates against. Both modes are still available — MCP wiring still works fine — but the External Agents API opens a different set of patterns where the system of record stays in Notion and Claude becomes one of several agents that the system orchestrates.

    Where this fits in the three-legged stool

    For anyone running Notion + Claude + Google Cloud as the operating stack of a small business or solo operator setup, the Developer Platform launch reinforces something the architecture was already pointing at: Notion is the system of record, Claude is the reasoning layer, GCP is the compute and data substrate. The May 13 launch makes that division of labor more legible.

    • Notion as system of record — Workers and database sync make Notion an active control plane, not just a passive document store. State lives here. Workflows initiate here.
    • Claude as reasoning layer — The External Agents API gives Claude a formal role inside Notion’s task management, planning, and review loops. Claude does the thinking; Notion holds the result.
    • GCP as compute substrate — Anything Workers can’t do (long-running automation, heavy compute, custom data pipelines, things that need to live behind a firewall), Cloud Run and Compute Engine still handle. Workers doesn’t replace GCP for the operations that need real horsepower; it extends Notion into the lightweight automation gap that previously required a Zapier-class bridge.

    The leg that grows the most from this launch is Notion. It picks up native automation and native AI-agent orchestration in one shipment. The leg that doesn’t change is Google Cloud — GCP is still where the heavyweight workloads live, the per-site WordPress fortresses run, and the custom Python and Node services that hold the operational glue together.

    The Claude-specific implications

    Anthropic’s customer page on Notion (verified May 15, 2026) confirms that Notion has integrated Claude Managed Agents — the version of Claude designed for long-running sessions with persistent memory and high-quality multi-turn outputs. Notion has also made Claude Opus available inside Notion Agent for the first time as part of the broader integration. The framing from Anthropic’s side: Notion is a design partner that helped shape Claude Code’s early development, and the External Agents API is the formal extension of that partnership into the Notion product surface.

    Practically, three things change for someone who already runs Claude against Notion:

    1. The MCP wiring is no longer the only path. If you’ve been using a Notion MCP server to give Claude Code read-write access to your workspace, that pattern still works and still has its place — particularly for developer workflows where Claude is doing the driving. But for operational workflows where Notion should drive and Claude should respond, the External Agents API is now the more natural fit.

    2. Multi-agent orchestration becomes a first-class concept. When Notion can address Claude, Cursor, Codex, and Decagon as discrete agents, the question stops being “which AI tool do I use” and becomes “which agent gets which task.” That’s a richer surface for actually distributing work across capabilities — Cursor for IDE-bound coding, Claude for long-form reasoning and writing, Decagon for customer-facing workflows. The orchestration sits in Notion.

    3. The persistent-memory pattern gets cleaner. The “Notion as Claude’s memory” architecture that we and others have been building with MCP wiring is now a supported, native pattern rather than a clever workaround. The structured pages, databases, and templates that hold what Claude needs to remember between sessions can now be addressed through a sanctioned API rather than reverse-engineered through tool calls.

    What we’d actually rebuild now

    If we were starting our second-brain architecture from scratch on May 15, 2026, knowing what shipped on May 13, the build order would be different than what we have today:

    • Database structures stay in Notion — same as before. The systems of record (clients, projects, content pipelines, scheduled tasks, the Promotion Ledger) all live in Notion databases.
    • Sync replaces a meaningful chunk of Zapier/Make — anywhere we currently bridge Notion to an external API for read or for write, native database sync becomes the first thing to try before reaching for a third-party automation tool.
    • Workers handles light recurring automation — the kind of thing we currently run as a Cloud Run cron job, where the trigger and state both live in Notion. Workers is closer to the data and easier to reason about for operators who don’t want to context-switch out of Notion.
    • External Agents API for Claude orchestration — Claude assignments come from inside Notion’s task surfaces. The Promotion Ledger, the editorial calendar, the client deliverable boards all become places where Claude can be assigned the same way a teammate is assigned.
    • GCP holds everything that’s heavyweight or sensitive — WordPress fortresses, custom data pipelines, anything HIPAA/regulated, the AI Media Architect run on Cloud Run, the knowledge-cluster-vm. None of this moves. Notion’s platform doesn’t compete here.

    The honest part: most of our existing infrastructure is staying. The Developer Platform launch isn’t a “rebuild everything” moment. It’s a “reach for Notion-native first when the workflow naturally lives in Notion anyway” moment. Where we used to glue together MCP servers, Zapier flows, and custom Cloud Run jobs to bridge gaps, the gaps are smaller now.

    The seams worth noticing

    Three things to be honest about:

    Workers is plan-gated. If you’re on a Notion plan below Business, you can use the External Agents API and the CLI but not Workers. The full programmable-platform vision requires the upgrade. For solo operators on Plus or below, this is a real friction point.

    The free-through-August window is a usage signal, not a permanent state. The Developer Platform is free through August 11, 2026. Notion has not yet published post-window pricing. Anyone building production workloads against the platform should plan for the possibility of a usage-based or tier-gated pricing model after that date.

    External Agents is a launch-partner-first model. Claude Code, Cursor, Codex, and Decagon are first-class. Other agents — and there will be other agents — show up later through the API. If your stack depends on an agent that isn’t on the launch partner list, the surface for integrating it is smaller right now than it will be in a few months.

    What to actually do this week

    If you’re running Claude against Notion in any operational capacity:

    1. Read Notion’s official release notes for 3.5 (notion.com/releases/2026-05-13). It’s short and concrete.
    2. Try the Notion CLI on a non-production workspace. The CLI is the lowest-friction way to feel what’s actually changed.
    3. If you have any workflow currently glued together with Zapier/Make where the trigger and state are both in Notion, evaluate whether database sync or Workers replaces it more cleanly.
    4. If you currently invoke Claude through MCP for tasks that would more naturally be assigned to Claude from inside Notion’s task boards, prototype the same workflow through the External Agents API and compare.
    5. Don’t migrate anything you don’t have to. The May 13 launch creates new options, not new mandates.

    Frequently Asked Questions

    What is the Notion Developer Platform?

    It’s the May 13, 2026 release (Notion 3.5) that adds Workers (cloud-based runtime), database sync (live data from external APIs), an External Agents API (outside AI agents operating natively inside Notion), and a Notion CLI. It turns Notion from an application you use into a platform you and your agents can build on.

    Is Claude one of the launch partners?

    Yes. Per Notion’s release notes and Anthropic’s customer page on Notion (both verified May 15, 2026), Claude is a launch partner alongside Cursor, Codex, and Decagon. Notion has also integrated Claude Managed Agents and made Claude Opus available inside Notion Agent.

    How is the External Agents API different from connecting Claude through MCP?

    MCP wiring lets Claude reach into Notion through tool calls — Claude is the driver, Notion is the data source. The External Agents API lets Claude appear inside Notion as a collaborator that can be assigned work — Notion is the driver, Claude is one of several agents responding. Both patterns coexist. Pick the one that matches who should be in charge of the workflow.

    What does the Developer Platform cost?

    Free through August 11, 2026, per Notion’s release notes. Workers and the deploy surface are limited to Business and Enterprise plans; the External Agents API and CLI are available across all tiers. Post-window pricing has not been published as of May 15, 2026.

    Does this replace MCP servers?

    No. MCP servers remain useful — particularly for developer workflows where Claude is doing the driving from inside Claude Code, and for cases where you need Claude to talk to multiple systems (not just Notion). The External Agents API adds an alternative pattern for the cases where Notion should hold the workflow and Claude should respond to it.

    Should I move workloads off Google Cloud onto Notion Workers?

    For most things, no. Workers is suited to lightweight, Notion-native automation. Heavy compute, regulated workloads, custom data pipelines, and anything that needs to live behind a firewall still belong on GCP (or your equivalent cloud). The Developer Platform extends what Notion can do natively; it doesn’t replace what cloud infrastructure does.

    Related Reading

    How we sourced this

    Sources reviewed May 15, 2026:

    • Notion official release notes: May 13, 2026 – 3.5: Notion Developer Platform at notion.com/releases/2026-05-13 (primary source for what shipped, pricing window, plan-tier gating)
    • Anthropic customer page on Notion at claude.com/customers/notion (primary source for Claude Managed Agents integration, Opus availability in Notion Agent, design-partner relationship)
    • TechCrunch coverage of the May 13 launch (Tier 2 confirming source for partner agent list and “control room for AI agents” framing)
    • InfoWorld coverage of the Notion Developer Platform launch (Tier 2 confirming source)
    • BetaNews and Dataconomy coverage (additional Tier 2 confirming sources)

    This article will need a refresh after August 11, 2026, when the free-pricing window ends and Notion publishes post-window pricing details. The verified-vs-reported standard from our other May 2026 pieces applies — anything beyond what Notion’s own release notes and Anthropic’s customer page confirm has been clearly distinguished.

  • Claude Agent SDK Dual-Bucket Billing: What Changes June 15, 2026 (And Why It Matters)

    Claude Agent SDK Dual-Bucket Billing: What Changes June 15, 2026 (And Why It Matters)

    Last refreshed: May 15, 2026

    If you’ve been running Claude Code’s claude -p command in production, kicking off background jobs through the Claude Agent SDK, or wiring the Agent SDK into a third-party app, the way you pay for that work is about to change.

    Starting June 15, 2026, Anthropic is splitting Claude subscription billing into two separate buckets: one for the things you do interactively (Claude.ai chat, Claude Code in your terminal, Claude Cowork), and a brand-new credit pool that only covers programmatic, autonomous, and SDK-driven work.

    This is a meaningful shift. It’s also one of the most under-explained changes Anthropic has made to subscription pricing this year. If you don’t know about it before June 15, you can find yourself with stopped automations, surprise overage charges, or both.

    This guide walks through exactly what’s changing, what the credits cover, what they don’t cover, what each plan gets, and how to plan for it before the cutover.

    The short version

    Claude subscription plans (Pro, Max, Team, Enterprise) currently have one shared usage limit. Whether you’re chatting with Claude on the web, using Claude Code in your terminal, or running unattended jobs through the Agent SDK, all of that draws from the same plan-level allowance.

    On June 15, 2026, Anthropic is separating those two modes of use:

    • Bucket 1 — Interactive use: Claude.ai chat, Claude Code in the terminal/IDE, Claude Cowork. Uses your existing subscription usage limits, exactly as before.
    • Bucket 2 — Agent SDK monthly credit: A separate, dollar-denominated credit pool. Funds the Claude Agent SDK, the claude -p non-interactive command, the Claude Code GitHub Actions integration, and any third-party app that authenticates via the Agent SDK.

    The two buckets do not commingle. Agent SDK work cannot draw from your interactive subscription limit, and interactive use cannot draw from your Agent SDK credit. If you exhaust your Agent SDK credit and don’t have extra usage enabled, your background jobs simply stop until the credit refreshes the following month.

    What each plan gets

    Here is the official monthly Agent SDK credit by plan, as published in Anthropic’s Help Center (verified May 15, 2026):

    • Pro: $20/month
    • Max 5x: $100/month
    • Max 20x: $200/month
    • Team — Standard seats: $20/month per seat
    • Team — Premium seats: $100/month per seat
    • Enterprise — usage-based: $20/month
    • Enterprise — seat-based Premium seats: $200/month

    Important detail buried in the announcement: Enterprise seat-based plans on Standard seats are not eligible to claim the Agent SDK credit at all. If you administer one of those plans and have engineers running automation, that’s a gap to plan around.

    What the credit covers (and what it doesn’t)

    Anthropic’s documentation is specific about what counts as Agent SDK use, so this is worth reading carefully.

    Covered by the credit:

    • Claude Agent SDK usage in your own Python or TypeScript projects
    • The claude -p command in Claude Code (non-interactive mode)
    • The Claude Code GitHub Actions integration
    • Third-party apps that authenticate with your Claude subscription through the Agent SDK

    Not covered (these still draw from your normal subscription limits):

    • Interactive Claude Code in your terminal or IDE
    • Claude conversations on web, desktop, or mobile
    • Claude Cowork
    • Other features that draw from extra usage

    The plain-English version: if a human is sitting at the keyboard waiting for the response, that’s interactive use. If a script kicks off the work and the result lands somewhere else later, that’s Agent SDK use.

    How the credit actually works in practice

    Five mechanics matter for budgeting:

    1. Per-user, never pooled. Each eligible user on a Team or Enterprise plan claims their own credit. There is no organization-level pool. Credits cannot be transferred between users, shared, or stockpiled across accounts.

    2. Refreshes monthly with the billing cycle. Whatever you don’t spend in a given month evaporates. Unused credits do not roll over.

    3. One-time opt-in. You claim your credit through your Claude account once. After that initial claim, it refreshes automatically each cycle.

    4. Drains first, before any other source. When an Agent SDK request fires, it pulls from your monthly credit before any other paid usage source kicks in. This is good — it means you actually use what you’ve already paid for.

    5. After the credit, requests either flow to extra usage or stop entirely. When your monthly credit hits zero, additional Agent SDK requests draw from extra usage at standard API rates — but only if you have extra usage enabled. If you haven’t enabled extra usage, your Agent SDK requests stop until the next refresh.

    That last point is the one most likely to bite teams. If you’re running a daily cron job through the Agent SDK and you don’t enable extra usage, the day your credit runs out is the day your automation goes silent — without obvious warning if you’re not watching the credit balance.

    Why Anthropic is doing this

    Anthropic frames this as separating individual experimentation from production automation. From the Help Center documentation: “The Agent SDK monthly credit is sized for individual experimentation and automation. Teams running shared production automation should use the Claude Developer Platform with an API key for predictable pay-as-you-go billing.”

    The translation: a single user’s $20 or $200 of Agent SDK credit was never going to cover a real production workload anyway. Anthropic is making explicit what was already true under the hood — that a subscription was a chat product, and serious unattended automation belongs on the API.

    What this also does, structurally, is protect interactive subscription users from getting their experience degraded by heavy autonomous workloads sharing the same pool. If you’ve ever hit a subscription rate limit during a normal chat session because something else on your account was burning tokens in the background, this change removes that failure mode.

    What you should do before June 15, 2026

    If you run any unattended Claude work (the most important group):

    Audit every place your subscription is being used by something other than a human at a keyboard. The big four to check:

    • claude -p commands in cron jobs, CI pipelines, or shell scripts
    • Claude Code GitHub Actions workflows
    • Custom Python or TypeScript projects using the Agent SDK
    • Any third-party tool that asks for “Sign in with Claude” — those go through the Agent SDK

    For each one, estimate dollar consumption per day at standard API rates. If the total approaches or exceeds your plan’s Agent SDK monthly credit, you have three options: enable extra usage to allow overage, move that workload to a Claude Developer Platform API key (more predictable for sustained loads), or downsize the workload itself.

    If you administer a Team or Enterprise plan:

    Eligible users on your team will receive an email with claim instructions before June 15, 2026. You don’t need to take action yourself, but it’s worth communicating internally that the credits are per-user, can’t be pooled, and that any team-wide automation should be on an API key, not on a subscription seat.

    If you’re a solo Pro or Max user who only chats with Claude:

    You probably don’t need to do anything. The split affects you only if you’re running scripts or background jobs. If you’ve never used claude -p or the Agent SDK directly, your interactive usage limits don’t change.

    Frequently Asked Questions

    What happens to my Agent SDK usage on June 14 vs. June 15, 2026?

    Before June 15, Agent SDK and claude -p usage counts against your subscription’s general usage limits. Starting June 15, that same usage no longer touches your subscription limits and instead draws from the new Agent SDK monthly credit pool. Your interactive Claude Code, web chat, and Cowork usage continues to work exactly as before.

    Can I share the Agent SDK credit across my team?

    No. Per Anthropic’s official documentation, “Credits are per-user. Each eligible user on your team claims their own credit. Credits can’t be pooled, transferred, or shared across the organization.” If your team needs shared automation budget, the Claude Developer Platform with an API key is the recommended path.

    Do unused Agent SDK credits roll over?

    No. Unused credits expire at the end of each billing cycle and do not carry into the next month.

    What happens if I run out of Agent SDK credit mid-month?

    If you have extra usage enabled, additional requests flow to extra usage at standard API rates (the same per-token prices listed in Anthropic’s pricing documentation). If extra usage is not enabled, your Agent SDK requests stop until your credit refreshes at the start of the next billing cycle.

    Does this affect Claude API customers using their own API key?

    No. If you authenticate with the Agent SDK using a Claude Developer Platform API key, nothing changes. Pay-as-you-go billing continues, and you do not receive an Agent SDK monthly credit. The credit only applies to subscription-authenticated Agent SDK use.

    Is interactive Claude Code in my terminal still covered by my subscription?

    Yes. Interactive Claude Code (typing commands and getting responses in your terminal or IDE) continues to draw from your subscription usage limits exactly as before. Only the non-interactive claude -p mode and direct Agent SDK calls move to the new credit pool.

    What’s the dollar value of the credit on each plan?

    As of May 15, 2026: Pro $20, Max 5x $100, Max 20x $200, Team Standard $20/seat, Team Premium $100/seat, Enterprise usage-based $20, Enterprise seat-based Premium $200. Enterprise seat-based Standard seats do not receive a credit.

    Related Reading

    How we sourced this

    Every factual claim in this article was triple-checked across the following sources, all reviewed on May 15, 2026:

    • Anthropic Help Center: Use the Claude Agent SDK with your Claude plan (primary source for credit amounts, eligibility, and mechanics)
    • Anthropic Pricing Documentation: docs.claude.com/en/docs/about-claude/pricing (primary source for standard API rates and tool-use pricing)
    • Independent press coverage from The New Stack, The Decoder, and InfoWorld confirming the announcement and its scope

    If you spot a number that’s drifted out of sync with Anthropic’s current published rates, treat the official documentation as authoritative. The pricing surface around Claude is moving quickly in 2026, and we date-stamp specifics so readers know which facts to re-verify.

  • Is Zapier Building the Everything App? The Connector That Became an Orchestrator

    Is Zapier Building the Everything App? The Connector That Became an Orchestrator

    What Is Zapier?
    Zapier is a no-code automation platform founded in 2011 that connects over 8,000 apps through a unified workflow engine. Originally built around simple “if this, then that” triggers, Zapier has transformed in 2025–2026 into an AI orchestration platform—adding autonomous agents, multi-model AI routing, natural language workflow building, and an MCP server that exposes its entire integration library to external AI models including Claude.

    Every company in this series has come at the everything app from a position of strength. Microsoft from enterprise software. Google from search. OpenAI from the frontier model. Mistral from sovereignty and open source. But none of them started where Zapier started: already inside your workflows, connected to every tool you use, trusted with the actual operations of your business.

    That’s the sleeper advantage in this race. While everyone else is building toward the everything app from the outside in, Zapier has been inside the everything app since the day you first connected your Gmail to your CRM.

    The question is whether a 13-year-old automation company can evolve fast enough to own the AI orchestration layer—or whether it becomes the platform that makes everyone else’s AI more powerful.

    📚 Everything App Series

    This is article 9 in our ongoing series examining which AI companies are building the everything app:

    The Transformation: From Connector to Orchestrator

    For most of its first decade, Zapier’s value proposition was simple: connect two apps without writing code. You set a trigger (“when I get a new email in Gmail”), define an action (“add a row to my Google Sheet”), and Zapier ran the automation in the background. Powerful, but fundamentally passive. Zapier did what you told it to do.

    In 2025, that changed fundamentally. Zapier relaunched its positioning as an AI Orchestration Platform and shipped three products that move it from passive connector to active AI layer:

    Zapier Copilot lets you describe a workflow in plain language and watch Zapier build it. Instead of manually connecting triggers and actions, you say “whenever a new lead comes in from our website form, research them on LinkedIn, score them, and add the qualified ones to our CRM with a draft follow-up email.” Copilot builds the multi-step Zap. This collapses the skill barrier that kept many users on simpler workflows.

    Zapier Agents, launched in January 2025 and reaching general availability in December 2025, are autonomous AI teammates. Unlike Zaps (which follow a fixed sequence), Agents decide how to accomplish a goal. You give an Agent a role—”you are our inbound lead coordinator”—a set of tools from Zapier’s app library, and a goal. The Agent reasons through the task, calls the appropriate tools in whatever order makes sense, handles exceptions, and reports back. In August 2025, Zapier added agent-to-agent orchestration, letting Agents delegate subtasks to specialist Agents—the first multi-agent architecture available to non-developers at scale.

    Zapier Canvas is the visual command center that maps how all of this fits together: your Zaps, Tables, Interfaces, Chatbots, and Agents displayed as a connected system. Canvas makes the invisible visible—you can finally see the full automation architecture of your business and edit it from a single surface.

    The 8,000-App Moat

    Here’s the number that matters more than any AI feature: 8,000 connected apps.

    Building an AI integration with a single app is straightforward. Building reliable, maintained, authenticated integrations with 8,000 apps—including niche tools that serve specific industries, legacy enterprise software, and the long tail of SaaS that most AI companies ignore—is a 13-year infrastructure investment that no new entrant can replicate quickly.

    Every AI model that wants to take actions in the real world faces the same problem: getting access to the apps where work actually happens. OpenAI is building these integrations one by one. Google has its own ecosystem but a limited integration library beyond Workspace. Microsoft covers the Office stack but leaves everything else to third parties.

    Zapier already has the connectors. That means Zapier Agents can operate across your full stack on day one—not the curated stack of apps a closed AI platform supports, but the actual combination of tools your business uses, however idiosyncratic.

    Zapier MCP: The Move That Changes the Competitive Map

    The most strategically significant product Zapier shipped in 2025 wasn’t Agents. It was Zapier MCP.

    Model Context Protocol (MCP) is the emerging standard that lets AI models call external tools. Zapier built an MCP server that exposes its entire integration library—all 8,000+ apps, tens of thousands of actions—to any AI model that speaks MCP. Claude can use it. GPT-4o can use it. Any MCP-compatible AI can use it.

    This is Zapier making a platform bet rather than a product bet. Instead of trying to be the AI model that users talk to, Zapier is becoming the action layer that every AI model reaches into when it needs to do something in the real world. The developer and coding agents plug in through the SDK. The AI assistants plug in through MCP. IT administrators see everything through unified audit logs and governance controls.

    Zapier is an official Anthropic integration partner. When Claude users need their AI to actually send an email, update a CRM record, add a calendar event, or post to Slack—Zapier is the infrastructure doing that work. That’s not a small bet. That’s positioning as the execution layer for the entire AI industry.

    The Financial Position: Profitable, Independent, Patient

    One underappreciated aspect of Zapier’s strategic position is its financial independence. Unlike most AI companies burning through venture capital at extraordinary rates, Zapier has been profitable for years. It has raised minimal external funding—approximately $1.4 million in a 2012 seed round and nothing significant since—and generates its own growth from revenue.

    Revenue reached $310 million in 2024 and is projected to approach $400 million in 2025. The company serves over 100,000 business customers. Its valuation is estimated around $5 billion—modest relative to OpenAI, Anthropic, or Mistral’s recent rounds, but built on actual cash flow rather than projected futures.

    This matters for the everything app question because Zapier is not under pressure to show explosive AI growth to justify a valuation. It can evolve its platform deliberately, double down on enterprise reliability, and build the trust that enterprise automation requires—without the distraction of a fundraising cycle or the fear of running out of runway.

    Zapier’s Approach to Enterprise AI Governance

    One of the signal differences between Zapier’s AI platform and its competitors is the emphasis on controls alongside capability. The February 2026 product updates focused specifically on AI guardrails and governance: who can create agents, what apps agents can access, what actions require human approval, and full audit logs of everything that ran.

    This is the unsexy but critical work of making AI deployable in regulated environments. An autonomous agent that can send emails, update databases, and call external APIs is a significant liability risk without proper governance. Zapier’s enterprise controls—managed credentials, admin dashboards, approval workflows for high-risk actions, comprehensive audit trails—represent years of enterprise trust-building that AI-first startups are only beginning to think about.

    The AI guardrails feature allows administrators to set boundaries on what Agents can do autonomously versus what requires a human in the loop. This isn’t a limitation on Zapier’s AI ambitions—it’s the feature that gets Zapier past the enterprise security review that blocks most AI tools from production deployment.

    The Notion Everything Database Connection

    If you’re using Notion as an everything database—as we explored earlier in this series—Zapier is one of the most powerful connectors in your stack. Zapier’s Notion integration supports triggers on database property changes, creating and updating pages, querying databases, and more. Zapier Agents can use these Notion actions as tools, meaning an Agent can reason about your Notion data, make decisions, and update records—all without you touching a line of code.

    The practical architecture looks like this: your Notion everything database stores structured business context. A Zapier Agent monitors specific triggers (a new record appears, a property changes, a status updates). The Agent pulls relevant context from Notion, reasons over it using its AI model, takes actions across your other connected apps, and writes results back to Notion. The entire workflow runs in the background, governed by your Zapier admin controls, with full audit logs.

    For teams building on the Notion everything database model, Zapier isn’t competing with that architecture—it’s the automation and agent layer that makes it operational. You design the data model in Notion; Zapier handles the movement and the intelligence on top of it.

    Where Zapier Falls Short

    Zapier’s everything app candidacy has real limits, and they’re worth naming plainly.

    First, Zapier is a B2B tool that has never built meaningful consumer presence. Everything apps in the historical sense—WeChat, Line, Grab, Gojek—succeed by capturing daily personal habits: messaging, payments, food delivery. Zapier operates in the workflow automation category, which is powerful for businesses but invisible to consumers. There is no path from Zapier’s current position to consumer everything app.

    Second, Zapier depends on the apps in its library. If OpenAI, Google, or Microsoft decides to deprecate their public APIs or make integration prohibitively expensive, Zapier’s connectors break. The 8,000-app moat is only as strong as those 8,000 companies’ continued willingness to maintain open APIs. As AI platforms consolidate, that willingness may erode.

    Third, Zapier’s AI layer is not a frontier model. Zapier Agents use third-party models (primarily OpenAI’s GPT-4o and related) for their reasoning capabilities. This means Zapier’s AI quality ceiling is set by someone else. When OpenAI ships a better model, Zapier agents get smarter—but so does every OpenAI customer. Zapier cannot differentiate on model quality the way Mistral or OpenAI can.

    Finally, the no-code positioning that made Zapier accessible also limits its ceiling. Complex enterprise workflows—the kind that justify serious AI investment—often require the custom logic, error handling, and integration depth that Zapier’s visual interface makes difficult. Competitors like n8n (open-source), Make (formerly Integromat), and enterprise-focused platforms like MuleSoft are taking direct aim at the workflows Zapier can’t handle.

    The Verdict: The Action Layer, Not the Interface Layer

    Is Zapier building the everything app? Not in the way the term is usually understood. Zapier is not trying to be the app you open every morning, the one that knows your identity, your preferences, and your social graph. It has no interest in capturing your attention or your feed.

    Zapier is building something that might matter more for AI’s actual impact on work: the universal action layer. The layer that every AI model reaches into when it needs to do something that matters. The layer that connects AI reasoning to business reality across the entire software ecosystem—not the 50 apps in one company’s walled garden, but the 8,000 apps that businesses actually use.

    In a world where every AI platform is competing to be your interface, Zapier is quietly becoming the infrastructure that makes any interface actually work. That’s not the everything app thesis. It’s the everything execution thesis. And given that 13 years of profitable growth and 100,000 enterprise customers are backing it, it may be the most durable bet in this entire series.

    Key Takeaway

    Zapier is not competing to be the everything app. It’s becoming the action layer that makes every everything app actually functional—the 8,000-integration infrastructure that AI models plug into when they need to do real work in real systems.

    What’s Next in This Series

    This article closes the core competitive series on everything app contenders. But the conversation isn’t finished. Two threads we’ve opened in this series deserve their own deep dives: the xAI infrastructure pivot story—whether Elon Musk is quietly turning Colossus and X into the “everything app ability” rather than the everything app itself—and a Track 2 series on how to actually connect each of these platforms to a Notion everything database as your operational backbone.

    If you’ve been following this series from the beginning, you’ve seen the landscape of AI consolidation from nine different angles. The conclusion that keeps emerging: the everything app isn’t a product. It’s a position. And the race to own that position is just getting started.

    Frequently Asked Questions About Zapier and the Everything App

    What is Zapier’s current AI platform called?

    Zapier relaunched in 2025 as an AI Orchestration Platform. The platform includes Zapier Agents (autonomous AI teammates), Zapier Copilot (natural language workflow builder), Zapier Canvas (visual system map), Zapier Tables, Zapier Interfaces, Zapier Chatbots, and Zapier MCP (an integration server for external AI models). The foundational Zaps automation engine remains the core, with these AI products layered on top.

    What is Zapier MCP and why does it matter?

    Zapier MCP is a Model Context Protocol server that exposes Zapier’s entire integration library to external AI models. Any MCP-compatible AI—including Claude, GPT-4o, and others—can use Zapier MCP to take actions across the 8,000+ apps Zapier connects. This makes Zapier the action execution layer for AI systems built by other companies, not just for Zapier’s own agents. Zapier is an official Anthropic integration partner through this mechanism.

    How many apps does Zapier connect?

    As of 2026, Zapier connects over 8,000 apps. This integration library has been built and maintained over 13 years and represents Zapier’s primary competitive moat. No AI-first entrant has built a comparable breadth of authenticated, maintained app integrations.

    What are Zapier Agents?

    Zapier Agents are autonomous AI teammates that reason about goals rather than following fixed if-then sequences. Launched in January 2025 and reaching general availability in December 2025, Agents can browse the web, read data sources, update CRMs, draft communications, and delegate to other specialist agents through multi-agent orchestration. They’re configured with a role, a set of tool permissions, and a goal—then run autonomously within governance guardrails set by administrators.

    How does Zapier integrate with Notion?

    Zapier’s Notion integration supports database triggers, page creation and updates, and database queries. Zapier Agents can use these as tools in their reasoning loops, enabling autonomous workflows that read from and write to Notion databases. For teams using Notion as an everything database, Zapier provides the automation and agent execution layer that makes that data architecture operational across connected business apps.

    Is Zapier profitable?

    Yes. Zapier has been profitable for years and has raised minimal external funding since a $1.4 million seed round in 2012. Revenue reached $310 million in 2024 with projections near $400 million for 2025. This financial independence distinguishes Zapier from most AI platform companies and gives it patience to evolve its platform without fundraising pressure.

    What are Zapier’s AI governance features?

    Zapier offers enterprise AI governance through managed credentials, admin controls on which users and teams can create or deploy agents, approval workflows for high-risk actions, AI guardrails that bound what agents can do autonomously, and comprehensive audit logs of all agent activity. These controls were prominently featured in the February 2026 product update and represent Zapier’s push to make AI deployment safe for regulated enterprise environments.

    How does Zapier compare to Make (Integromat) and n8n?

    Make and n8n are Zapier’s primary competitors in workflow automation. Make offers more complex branching logic at competitive pricing. n8n is open-source and self-hostable, appealing to developers and privacy-conscious enterprises. Zapier differentiates on breadth of integrations, ease of use for non-technical users, and its newer AI layer (Agents, Copilot, MCP). For enterprises prioritizing AI orchestration with governance controls, Zapier’s platform depth currently leads. For developers wanting maximum flexibility or self-hosting, n8n is the primary alternative.

  • Claude Code Hooks: The Workflow Control Layer That Actually Enforces Your Rules

    Claude Code Hooks: The Workflow Control Layer That Actually Enforces Your Rules

    Last refreshed: May 15, 2026

    You’ve been there. You add a rule to CLAUDE.md — “always run prettier after editing files” — and Claude follows it, most of the time. Then it doesn’t. The formatter doesn’t run, the lint check gets skipped, and you’re back to reviewing diffs manually.

    Hooks fix this. Claude Code hooks are shell commands, HTTP endpoints, or LLM prompts that fire deterministically at specific points in Claude’s agentic loop. Unlike CLAUDE.md instructions, which are advisory, hooks are enforced at the execution layer — Claude cannot skip them.

    As of early 2026, Claude Code ships with 21 lifecycle events across four hook types. This article covers the two that matter most for daily workflow: PreToolUse and PostToolUse.

    How Hooks Work Architecturally

    Claude Code’s agent loop is a continuous cycle: receive input → plan → execute tools → observe results → repeat. Hooks intercept this loop at named checkpoints.

    Every hook is defined in .claude/settings.json under a hooks key. A hook entry has three parts: the lifecycle event name, an optional matcher (a regex against tool names), and the handler definition — either a shell command, an HTTP endpoint, or an LLM prompt.

    {
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write "$CLAUDE_TOOL_INPUT_FILE_PATH""
          }
        ]
      }
    ]
  }
}

    That’s it. Every file Claude writes or edits now auto-formats. No CLAUDE.md reminders, no hoping Claude remembers — the formatter runs on every single Write or Edit tool call, period.

    PreToolUse: Enforce Before Claude Acts

    PreToolUse fires before Claude executes any tool. Your hook receives the full tool call — name, inputs, arguments — and can return one of three signals:

    • Exit 0 → allow the tool call to proceed
    • Exit 2 → block the tool call; Claude receives your error message and adjusts
    • Exit 1 → hook error; Claude proceeds but logs the failure

    This makes PreToolUse the right place for guardrails. Here’s a real example: blocking npm in a bun project.

    #!/bin/bash
# .claude/hooks/check-package-manager.sh
# Blocks npm commands in projects that use bun

if echo "$CLAUDE_TOOL_INPUT_COMMAND" | grep -qE "^npm "; then
  echo "Error: This project uses bun, not npm. Use: bun install / bun run / bun add" >&2
  exit 2
fi
exit 0

    Wire it in settings.json:

    {
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/check-package-manager.sh"
          }
        ]
      }
    ]
  }
}

    Now when Claude tries npm install, the hook exits 2, Claude sees the error message, and it switches to bun install without you intervening. The correction happens in the same turn.

    Another production pattern: blocking writes to protected paths.

    #!/bin/bash
# Prevent Claude from modifying migration files already run in production
if echo "$CLAUDE_TOOL_INPUT_FILE_PATH" | grep -qE "db/migrations/"; then
  echo "Error: Migration files are immutable after deployment. Create a new migration instead." >&2
  exit 2
fi
exit 0

    PostToolUse: React After Claude Acts

    PostToolUse fires after a tool completes successfully. It can’t block execution, but it can provide feedback — and it can run any side-effect you need automatically.

    Auto-format every edit:

    {
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write "$CLAUDE_TOOL_INPUT_FILE_PATH" 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}

    Run tests after code changes:

    #!/bin/bash
# Run affected tests after any source file edit
FILE="$CLAUDE_TOOL_INPUT_FILE_PATH"
if echo "$FILE" | grep -qE "\.(ts|js|py)$"; then
  if [ -f "package.json" ]; then
    npx jest --testPathPattern="$(basename ${FILE%.*})" --passWithNoTests 2>&1 | tail -5
  fi
fi

    Desktop notification on task completion:

    {
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification "Claude finished" with title "Claude Code"'"
          }
        ]
      }
    ]
  }
}

    Environment Variables Available to Hooks

    Claude Code exposes context about the triggering tool call through environment variables. The ones you’ll use most:

    Variable Value
    $CLAUDE_TOOL_NAME Name of the tool being called (e.g., Edit, Bash, Write)
    $CLAUDE_TOOL_INPUT_FILE_PATH File path for Edit, Write, Read calls
    $CLAUDE_TOOL_INPUT_COMMAND Shell command for Bash calls
    $CLAUDE_SESSION_ID Current session ID — useful for audit logging
    $CLAUDE_TOOL_RESULT_OUTPUT Output of the tool (PostToolUse only)

    These are injected by Claude Code before your hook runs. You don’t configure them — they’re always there.

    The Model Question: Which Claude Runs Agentic Tasks?

    One practical consideration for hook-heavy workflows: the default model affects how well Claude responds to hook feedback. As of May 2026:

    • claude-opus-4-7 ($5/MTok input, $25/MTok output) — highest agentic coding capability; best at interpreting hook rejection messages and self-correcting without re-asking
    • claude-sonnet-4-6 ($3/MTok input, $15/MTok output) — strong balance of speed and reasoning; handles most hook-corrected flows well
    • claude-haiku-4-5-20251001 ($1/MTok input, $5/MTok output) — fastest; may require more explicit hook messages to course-correct reliably

    For workflows with complex PreToolUse guardrails — especially ones that provide long error messages with corrective instructions — Opus 4.7 handles the feedback loop most reliably. For simpler PostToolUse automation (formatters, notifications), model choice doesn’t matter; the hook runs regardless.

    To configure the model: export ANTHROPIC_MODEL=claude-opus-4-7 before launching Claude Code, or set it in your team’s .env.

    Hooks vs. CLAUDE.md: When to Use Each

    CLAUDE.md is the right place for context, preferences, and guidance — things you want Claude to know about your project. Hooks are the right place for behavior that must happen every time without exception.

    The practical test: if failing to follow the instruction costs you five minutes of manual cleanup, put it in a hook. If it’s a style preference or a reminder about architecture decisions, put it in CLAUDE.md. The two are complementary — you’ll likely end up with both in any mature project setup.

    A team that gets this right builds CLAUDE.md as documentation for Claude and hooks as the CI/CD equivalent for the agentic loop.

    Getting Started

    The fastest path to a working hook setup:

    1. Create .claude/settings.json in your project root if it doesn’t exist
    2. Add a PostToolUse hook wired to your formatter — this is low-risk and immediately valuable
    3. Test it by asking Claude to edit a file; the formatter should run automatically
    4. Add PreToolUse guardrails for any tool calls that have caused problems in the past

    The official hooks reference is at code.claude.com/docs/en/hooks — it covers all 21 lifecycle events, HTTP handler format, and the full JSON output schema for hook responses.

    Hooks are the difference between Claude Code as a powerful suggestion engine and Claude Code as a reliable automation layer. Once you have a PostToolUse formatter running on every edit, going back feels like working without version control.

    📖 Recommended Reading in Claude Code Insider

  • Singapore’s Foreign Minister Built His Own Claude AI Second Brain — And Published the Blueprint

    Singapore’s Foreign Minister Built His Own Claude AI Second Brain — And Published the Blueprint

    Last refreshed: May 15, 2026

    On April 21, 2026, Singapore’s Foreign Minister Dr Vivian Balakrishnan published the architecture of his personal AI assistant on GitHub. He called it NanoClaw — “a second brain for a diplomat.” It runs on a Raspberry Pi 5. It costs roughly $80 in hardware and $5–20 a month in API fees. It connects to his WhatsApp, Gmail, and voice notes. It drafts speeches, runs scheduled briefings, and — unlike every standard chatbot — gets smarter over time because it maintains a structured knowledge graph that persists across sessions.

    His summary: “It answers every question, researches topics, provides daily updates, drafts speeches and condenses information. It has become invaluable — I don’t dare switch it off.”

    A sitting cabinet minister of a G20-adjacent nation just open-sourced his personal AI second brain on GitHub. That’s worth slowing down to look at.

    What NanoClaw Actually Is

    NanoClaw is built on four open-source components running on a Raspberry Pi 5:

    • NanoClaw (agent framework, built by developer Gavriel Cohen, 28k+ GitHub stars) — orchestrates Claude agents in isolated Docker containers. Each chat group gets its own sandboxed container.
    • Mnemon — the knowledge graph layer. Extracts discrete facts, insights, and style preferences from raw documents and conversations into a structured, retrievable graph database. Each entry is a self-contained statement, not a raw text chunk.
    • OneCLI — credential proxy.
    • Karpathy’s LLM Wiki pattern — the memory architecture that lets the system synthesize knowledge rather than just retrieve it.

    WhatsApp integration runs through Baileys, an open-source implementation of the WhatsApp Web protocol — no commercial API required. Voice notes are transcribed locally via Whisper.

    The full architecture is published at: gist.github.com/VivianBalakrishnan/a7d4eec3833baee4971a0ee54b08f322

    The Architecture Detail That Matters Most

    Standard chatbots are stateless. Each session starts from zero. The standard workaround is RAG — retrieval-augmented generation, which pulls chunks of raw text from a document store when they seem relevant. Balakrishnan’s system does something different. Mnemon’s Extract function pulls discrete facts and insights from raw documents into a graph database. Each entry is a self-contained, retrievable statement — not a text chunk.

    This is the same distinction that Anthropic’s Dreaming feature (announced May 6 for Managed Agents) is built on: the difference between storing raw experience and synthesizing it into structured knowledge. A system that synthesizes what it learns compounds in usefulness over time. One that just accumulates raw text doesn’t.

    Balakrishnan acknowledged this in a reply on his GitHub gist: “Local models will not give you the big context needed for digesting the memory graph, but will be good enough for querying it. You may want to use a bigger model that works well with a 128K token context at the very least.” He chose Claude specifically for the reasoning capability on the memory graph.

    He Built It With Claude Code, Not Traditional Coding

    This detail matters. Balakrishnan confirmed on X that he never used an IDE. Claude Code made all edits. His description of his own process: “No ‘vibe coding’. All I did was ‘tool assembly’ to create a utility that worked in my domain.”

    Tool assembly. That’s an important distinction. He didn’t write code — he assembled existing open-source tools using Claude as the implementation layer. A trained ophthalmologist and career diplomat, with no traditional software development background, built and deployed a production AI system running on commodity hardware by composing tools through Claude Code.

    His framing at the 17th Asia-Pacific Programme for Senior National Security Officers, the day he published NanoClaw: “AI agents have crossed a threshold I did not expect so soon. Not just impressive demos — but practical tools for daily use.” The audience was senior national security officials from across the Asia-Pacific region.

    Why This Is the Cowork Story in Miniature

    We run our own version of this — Claude operating scheduled tasks, content pipelines, and research workflows on our behalf through Cowork. The architecture Balakrishnan published is recognizably the same value proposition: persistent memory, multi-channel input, scheduled tasks, a system that improves over time.

    His total cost: ~$80 hardware, $5–20/month API. That’s a DIY Cowork running on a credit-card-sized computer on a diplomat’s desk in Singapore. The point isn’t that the price is better or worse than any specific product — it’s that the primitives are now accessible enough that a non-developer can assemble them into a working production system.

    His own thesis on why he published it: “Sharing the blueprint boosts the edge — the specific composition will be obsolete in months, but the builder’s ability to compose the right pieces is the durable advantage.” That’s as clean a statement of the AI-literacy case as we’ve seen from anyone, let alone a sitting foreign minister.

    The Broader Signal

    Singapore continues to be the most Claude-dense environment we track. The same week Balakrishnan published NanoClaw, a Claude Code meetup at Grab HQ drew 1,291 registrants. GIC (Singapore’s sovereign wealth fund) is a co-investor in Anthropic’s infrastructure JV. The country has institutional capital, developer community density, and now a sitting cabinet minister publishing working Claude architecture on GitHub. That triangle is unusual.

    Balakrishnan’s quote from the CNBC Converge Live fireside the day after publishing NanoClaw: “The diplomat who learns to work with AI will have a meaningful edge. I think that edge is now.” He wasn’t talking about chatbots. He was talking about a system running on his desk, integrated into his actual workflows, that he personally built and that he personally depends on.

    That’s a different kind of AI adoption signal than a press release about an enterprise partnership.

    Frequently Asked Questions

    What is NanoClaw?

    NanoClaw is an open-source Claude-powered personal AI assistant framework built by developer Gavriel Cohen. Singapore’s Foreign Minister Dr Vivian Balakrishnan published his own NanoClaw implementation on April 21, 2026 — a self-hosted assistant running on a Raspberry Pi 5 that connects to WhatsApp, Gmail, and voice notes, runs scheduled tasks, and maintains a persistent knowledge graph that grows smarter over time.

    How much does NanoClaw cost to run?

    Balakrishnan’s setup uses approximately $80 in hardware (Raspberry Pi 5) and roughly $5–20 per month in Anthropic API fees depending on usage volume. The software components (NanoClaw, Mnemon, OneCLI, Whisper, Baileys) are all open source. The full architecture is published at gist.github.com/VivianBalakrishnan/a7d4eec3833baee4971a0ee54b08f322.

    Did Vivian Balakrishnan write the code himself?

    He described his process as “tool assembly” rather than traditional coding — composing existing open-source components using Claude Code to handle implementation. He confirmed on X that he never used an IDE and that Claude Code made all edits. He has no traditional software development background; he’s a trained ophthalmologist and career diplomat.

    How is NanoClaw’s memory different from standard chatbot memory?

    Standard chatbots are stateless — each session starts from zero. NanoClaw uses Mnemon, a knowledge graph that extracts discrete facts and insights from conversations and documents into structured, retrievable entries. The system synthesizes knowledge rather than just storing raw text, meaning it compounds in usefulness over time rather than simply accumulating history.

  • Claude Dreaming Explained: Why AI Agents That Learn Between Sessions Change the Game

    Claude Dreaming Explained: Why AI Agents That Learn Between Sessions Change the Game

    Last refreshed: May 15, 2026

    At the Code with Claude conference on May 6, Anthropic announced a Managed Agents feature called Dreaming. The press covered it briefly — VentureBeat, 9to5Mac — but mostly as a developer story. The Harvey result (a legal AI company reporting roughly a 6× task completion rate increase) was cited but not unpacked. This is the non-developer version of that story, written for people who run workflows, manage operations, or use Claude professionally without writing code.

    What Dreaming Actually Does

    Here’s the mechanism in plain terms. Normally, when an AI agent finishes a session, it’s done. Whatever it learned — the patterns it noticed, the decisions it made, the context that turned out to matter — stays in that session and disappears when the session closes. The next session starts fresh.

    Dreaming changes that. After a session ends, the agent reviews what happened: it reads its own memory store alongside the session transcripts and produces a new, improved version of its memory. Duplicates are merged. Stale information is replaced. New patterns that emerged from the session get incorporated. The next session doesn’t start from scratch — it starts from a richer, more accurate knowledge base.

    The Anthropic documentation describes it this way: a dream reads an existing memory store alongside past session transcripts, then produces a new reorganized memory store with insights no single session could see alone. Docs: platform.claude.com/docs/en/managed-agents/dreams.

    This is a developer-layer feature — it requires implementation, not just subscribing to a plan. But understanding what it does helps you ask the right questions about the tools you’re evaluating and the agents you’re eventually going to run.

    Why Harvey’s 6× Result Is the Right Hook

    Harvey is a legal AI company. Their workflows are exactly the kind of work where this matters: complex research tasks that span multiple sessions, with context that compounds over time. A lawyer doesn’t approach a new matter without the knowledge they’ve accumulated from previous matters. Historically, AI agents did. Each new session was a blank slate.

    Harvey reported roughly a 6× task completion rate increase after implementing Dreaming. That’s not a benchmark number from a controlled test — it’s a production system showing measurable improvement from session-to-session memory refinement. The mechanism is the same as how human expertise compounds: not by accumulating raw experience, but by periodically synthesizing and reorganizing what’s been learned.

    Whether 6× holds across every use case is unknown. The direction of the effect is the signal. Agents that improve between sessions outperform agents that don’t. That gap widens over time.

    The Cowork Parallel

    We run our own Cowork setup — Claude operating scheduled tasks, content pipelines, and site management workflows on our behalf. The Dreaming announcement is relevant to us not because we’re going to implement it today (it’s developer preview, invitation-only access), but because it’s the roadmap signal for where agentic AI is heading.

    The systems we’re building now — Cowork routines, scheduled tasks, skill libraries — are the foundation that Dreaming-style memory will eventually sit on top of. Agents that accumulate context across sessions. Workflows that get better at your job the more you run them. That’s the direction. The Harvey result is the first public production evidence that the direction is real.

    What This Looks Like for Non-Developer Workflows

    Dreaming isn’t in consumer Claude products yet — it’s a developer preview. But the pattern it represents is worth thinking about now for anyone who uses AI in recurring work:

    • Legal and compliance work: Each matter builds on prior matter context. An agent that synthesizes what it learned from 50 prior research sessions before starting the 51st is doing something closer to what an experienced associate does.
    • Operations and project management: Recurring status meetings, weekly reports, vendor communication — these have patterns. An agent that notices “the Friday report always needs these three data sources” and incorporates that into its working memory doesn’t need to be told again.
    • Content and editorial work: Our own content pipeline is a clear example. Style preferences, site-specific constraints, recurring topic clusters — knowledge that currently lives in skill files and desk specs. Dreaming is the mechanism that would let an agent accumulate and refine that knowledge from session experience rather than requiring it to be manually specified.
    • Customer-facing workflows: Agents that handle recurring customer interactions and improve their response quality based on what worked in prior sessions — without a human having to manually update a prompt each time something changes.

    Current Access Status

    To be direct about where this stands today:

    • Dreaming: Developer preview only. Invitation-based access. Not available in claude.ai or any subscription tier.
    • Multiagent Orchestration: Public beta. Available via the Claude API.
    • Outcomes: Public beta. Available via the Claude API.

    If you’re not a developer implementing your own Claude agents, Dreaming isn’t something you can use yet. It will become relevant when it moves to GA and when products built on top of it surface in tools you already use. The Harvey result is the preview of what those products will eventually be able to do.

    Our Take

    The briefing note we wrote when this story broke said: “Dreaming is the story the press mostly missed.” The Harvey 6× result landed in VentureBeat but was treated as a developer-tier data point. We think it’s more broadly significant than that.

    What makes expertise valuable isn’t the accumulation of raw information — it’s the synthesis. A junior lawyer with access to the same case law as a senior partner isn’t equally useful, because the senior partner has synthesized 20 years of patterns into a working model that guides their reasoning. Dreaming is Anthropic’s attempt to give agents a version of that synthesis capability. It’s early, it’s developer preview, and the 6× figure is from one company’s specific workflow. But the direction is clear, and it’s the right direction.

    For anyone building with Claude or evaluating where agentic AI is heading: this is the development worth tracking most closely from the May 6 announcement. Not the SpaceX rate limits (immediately useful), not the Managed Agents public beta (available now), but Dreaming — because it’s the piece that changes the fundamental model of how AI agents improve over time.

    Frequently Asked Questions

    What is Claude Dreaming?

    Dreaming is a Claude Managed Agents feature (developer preview as of May 2026) that lets AI agents review and reorganize their own memory between sessions. After a session ends, the agent reads its memory store alongside session transcripts and produces an improved memory store — merging duplicates, replacing stale information, and surfacing patterns from the session. The next session starts with a richer knowledge base than the previous one ended with.

    What did Harvey report about Dreaming?

    Harvey, a legal AI company, reported roughly a 6× task completion rate increase after implementing Dreaming in their Managed Agents workflow. Harvey’s use case involves complex legal research spanning multiple sessions — exactly the kind of work where session-to-session memory improvement has the highest value.

    Can I use Dreaming in claude.ai?

    No. As of May 2026, Dreaming is a developer preview available only to selected developers implementing their own Claude agents via the Anthropic API. It is not available in the claude.ai interface or through any subscription tier.

    How is Dreaming different from Claude’s memory feature in claude.ai?

    Claude’s memory feature in claude.ai extracts key facts from conversations and injects them into future sessions as a summary. Dreaming is a more sophisticated agent-layer system where the agent itself reviews and reorganizes its full memory store and session history, producing a restructured knowledge base — not just a collection of extracted facts. They serve different purposes at different layers of the stack.

    When will Dreaming be available to non-developers?

    Anthropic hasn’t announced a GA timeline for Dreaming. It will likely surface in consumer and professional products after the developer preview phase completes and the implementation patterns are well understood. Harvey’s result suggests the mechanism works in production; the path to broader availability depends on how Anthropic packages it for non-developer deployment.