DEV Community: speedy_devv

I Shipped a SaaS MVP With Three Emails. Then I Watched It Die.

speedy_devv — Sun, 03 May 2026 15:16:06 +0000

I just shipped a SaaS MVP last month. Auth worked. Payments worked. The product did the thing it was supposed to do. I opened the dashboard on a Monday morning, coffee in hand, ready to watch the trials convert.

Three weeks later my trial-to-paid was sitting at 8%. Users were signing up, clicking around for a day, and vanishing. Nobody was churning loudly. They were just leaving. Quietly. Like the app was a restaurant they walked into, looked at the menu, and walked out of without ordering.

I looked at my email setup. A welcome email, a password reset, a payment receipt. That was it. Three emails covering maybe 10% of the lifecycle. The other 90% was silence, and that silence was costing me every single trial that did not convert on its own.

The Number That Made Me Stop Coding and Start Reading

I went down a research rabbit hole for two days. I read every email marketing study I could find. One number kept showing up, and it kept me up at night.

Automated email flows make up about 2% of total email volume but drive 37% of email revenue. Two percent. Thirty-seven percent. That ratio is insane. The emails most founders skip are the ones generating most of the money.

Two percent of your email volume drives 37% of your revenue. That is the gap where silent SaaS products go to die.

I had shipped the product. I had not shipped the lifecycle. And the lifecycle was the product, because nobody reaches the product if nobody leads them to it.

Why I Stopped Trusting My Email Tool

The standard advice is: open your email platform, pick a template, write the copy, set a 3-day delay, repeat. I tried that. I hated it. Here is what I kept running into.

Timers Ignore What Users Actually Do

Most tools schedule emails on fixed delays. Send email 2 three days after email 1. That logic treats every user the same. A user who activated on day 1 gets the same nudge as someone who never logged in. It is spam disguised as personalization.

The research is blunt about this. Triggered emails, meaning emails sent based on what a user does, get 76% higher open rates and 152% higher click-through rates than timed sends. If I wanted the 37% revenue, I had to build triggered, not timed.

HTML Templates Look Professional and Underperform

I had been building rich HTML emails with my logo, images, layout grids, the whole thing. They looked great in preview. They also tanked in practice.

Plain text emails get 42% more clicks than HTML. Gmail and Apple Mail render plain text well. Heavy HTML triggers spam filters. Half the devices your users carry render your beautiful layout like a ransom note. I had been optimizing for what looked good in my design tool, not for what clicked in real inboxes.

External Tools Have No Idea What Your App Is Doing

This is the one that killed me. My email platform could not check if a user had already activated before sending the activation nudge. It could not skip the upgrade email for someone who upgraded yesterday. The email system and the product lived in separate worlds. I was sending people upgrade prompts after they had upgraded.

What I Actually Wanted to Build

I wrote down what a correct email system would do. It would:

Read my product, my user journeys, my brand voice, and design sequences that sounded like my product
Cover all six major lifecycle stages, not just welcome and billing
React to what users do, not when they signed up
Check the database between every email so I never sent something stupid
Render both HTML and plain text so every client got the version it preferred
Wire triggers to events my app already fires (signup, limit hit, cancellation)

Then I looked at what that would take to build by hand. Seventeen templates. Six background job functions. Trigger wiring across three codebases. Type checking. Tests. Maybe a week of focused work if nothing went sideways.

I did not have a week. I had a conversion problem right now.

So I built it differently.

One Command, Six Agents, Seventeen Emails

I built a slash command called /emails that runs a pipeline of Claude Code agents. One command reads my product, designs every sequence, waits for approval, then builds in parallel.

The command runs in two phases.

Phase 1 is design. One agent reads my product overview, user journeys, brand guidelines, feature map, auth flow, billing setup, and brand colors. From that it builds an Email Brief: the product name, the "aha moment" (the specific action where the product clicks), pricing model, top features to educate about, and upgrade triggers. Then it designs all 17 emails. Subject lines, timing, goals, copy angles.

Nothing gets built yet. The plan goes to me first. I can cut sequences, rewrite subject lines, change timing, or kill emails I do not want. The build phase uses my approved plan as its spec.

Phase 2 is build. Six agents work in parallel. One base agent goes first and creates the shared layout and sending utility. Then five agents build their sequences at the same time. Templates are React components. Background jobs use Inngest (a job engine that handles scheduling, retries, and event-driven workflows).

Twenty minutes of wall-clock time. Six parallel agents. Seventeen typed templates. Six functions. One type check at the end.

The Six Sequences Every SaaS Is Missing

Here is the lifecycle the system builds. I did not invent this. I read about 40 email marketing studies and pulled the pattern that worked.

1. Welcome (4 emails, days 0 to 7)

This is the highest-value sequence you will ever send. First welcome emails average 55 to 70% open rates. Top-performing SaaS companies hit 75% plus. That is the best attention you will ever get from a user. Four emails over the first seven days, each one guiding them closer to the moment your product clicks for them.

2. Activation Nudge (+48h if no key action)

Someone finishes onboarding, sees the dashboard, and leaves. This is the single biggest drop-off point in most SaaS products. One email 48 hours later, focused on one specific action, pulls a chunk of them back.

3. Feature Education (days 14 to 28)

The user is active but only uses one feature. Three emails, each highlighting something they have not touched yet. Segmented campaigns like this drive up to 760% more revenue than broadcast blasts.

4. Upgrade Prompt (on limit hit)

This one fires when the user hits a real limit, not on a timer. They tried to do something the free plan does not allow. That is the moment they actually understand the value. Three emails over five days: what happened, what the paid plan includes, and an offer.

5. Churn Prevention (7 to 30 days inactive)

Runs on a daily cron job. Every morning at 9 AM, the system queries the database for users inactive for 7 plus days. Three emails spread across the next 30 days, each using a different angle: here is what you are missing, your data is still here, tell us what went wrong.

6. Win-Back (0 to 30 days after cancellation)

Starts when Stripe sends a cancellation webhook. Three emails over 30 days. The first acknowledges the cancellation. The second highlights what improved. The third makes an offer.

Here is the part that floored me. A study of 38 SaaS companies found that only 2 covered all of these stages. Two out of thirty-eight. Most stop at welcome and billing. The other 36 are leaving 37% of their email revenue on the table.

Only 2 of 38 SaaS companies cover all nine lifecycle stages. Everyone else is bleeding revenue politely.

The Part That Actually Matters: Behavioral Branching

The thing that separates a real lifecycle system from a timer-based drip is branching. Reacting to what users do, not when they signed up.

Inngest has a feature called step.waitForEvent. In plain terms, it pauses a sequence and waits for a specific thing to happen before continuing. If that thing does not happen in a time limit, the sequence takes a different path.

Here is how that plays out for a new user.

They sign up. The welcome sequence starts. Email 1 sends immediately. Then the function calls step.waitForEvent and waits up to 48 hours for a user.activated event, meaning the user completed the product's core action.

If the event arrives, the sequence skips the activation nudge and jumps straight to feature education. The user already found the value. Nudging them would be noise.

If the event does not arrive, the activation nudge fires. One email focused on the specific action they have not taken.

That same branching happens inside every sequence. The upgrade prompt checks if the user upgraded between emails. Churn prevention checks if they logged back in. Win-back checks if they re-subscribed. Between every step.sleep() call, the function opens a fresh database connection and checks the user's current state. If the user already converted, the sequence stops.

No one gets an upgrade email the day after they upgraded. No one gets a churn email the morning they came back. The email system knows what the product knows, because it is built inside the same app.

The Copy Angle Nobody Teaches You: Loss Framing

I want to single out one specific thing the research changed about my copy. The win-back sequence.

Most founders write cancellation follow-ups that are sunny and optimistic. "Come back, we miss you, look at all the great new things we built." Positive framing. It feels right.

It underperforms. By a lot.

Loss-framed messaging, meaning what you are giving up, converts 21 to 32% better than positive framing. My win-back emails now lead with what the user loses by staying away. The data they cannot access. The automations still running in the background waiting for them. The integration they set up that is about to go stale.

It feels counterintuitive. Loss framing sounds mean. But humans are wired to avoid loss more than to seek gain, and email copy is the place where that wiring shows up most clearly.

What Happened When I Actually Used This

I rolled out the full seven-email onboarding arc on my MVP.

Trial-to-paid went from 12% to 22% over six weeks. Monthly churn dropped from 8% to 4.8%. Those are the two numbers that compound. A 10-point conversion lift plus a 3-point churn reduction changes the math on every marketing dollar I spend. Every channel I was running suddenly paid back more, because the funnel behind it stopped leaking at the bottom.

The other thing I did not expect: my support volume went down. People stopped asking me basic feature questions. The education sequence was answering them before they hit the contact form.

Trial-to-paid went from 12% to 22%. Churn went from 8% to 4.8%. Support volume dropped. The emails did the work my onboarding was supposed to do.

Six Rules I Would Keep Even If I Rebuilt This

The pattern works with any email provider, any job engine, any framework. Here is what I would carry forward.

Read the product before designing emails

The most common mistake is writing emails that sound generic because the person writing them did not understand the product deeply enough. Feed the system your product docs, user journeys, and brand voice before it touches a template.

Design before you build

Present the full plan. Get approval. Then build. Changing a subject line in a plan is free. Changing it in a built template means re-rendering, re-testing, re-deploying.

Check user state between every email

Never assume the user is still in the state they were in when the sequence started. A step.sleep("3d") means three days of potential changes. Query the database before sending.

One action per email

Not two buttons. Not three links. One clear next step. Emails with a single call to action get higher click-through rates because there is no decision to make.

Build plain text alongside HTML

Do not treat plain text as an afterthought. Render both versions from the same template. Plain text emails get 42% more clicks in head-to-head tests, and you get it for free if you design for both.

Wire triggers to events your app already fires

Signup already happens. Cancellation already happens. Limit hits already happen. The email system hooks into events that already exist. That is zero new infrastructure.

The Pattern Works Beyond Email

The parallel-agents pattern, one base agent builds shared infrastructure, then specialized agents build on top of it at the same time, is not specific to email.

I have since used the same shape for notification systems (push, in-app, SMS), onboarding flows (modal, tour, checklist, empty states), and documentation (structure and shared components, then sections written in parallel). Same coordination. Same speed win.

Read the product context first. Design before building. Build in parallel with shared infrastructure. Check state before acting. Type-check everything at the end. That is the entire recipe.

If You Want the Whole Thing

The /emails command is part of Build This Now. It is an AI-powered build system for shipping production SaaS in 48 hours. Eighteen specialist agents, 55+ skills, a full production codebase with auth, payments, storage, analytics, and security built in. One-time payment. No subscriptions.

If you want to stop shipping products that die quietly three weeks after launch, start here:

Full system: buildthisnow.com
Read the full technical breakdown on the blog: buildthisnow.com/blog/ai-email-sequences

The MVP is the product. The lifecycle is the business. Build both.

MCP Tool Hooks in Claude Code

speedy_devv — Fri, 24 Apr 2026 13:22:05 +0000

Your hooks run shell scripts. Every time a hook needs to call an MCP server, it spawns a subprocess, wires up transport, handles auth, parses the response, and formats JSON back to stdout. For a security check that fires on every file write, that overhead adds up fast.

As of Claude Code v2.1.118, there is a cleaner path. Hooks have a new type that calls MCP tools directly. No subprocess. The MCP server is already running. The hook calls straight into its RPC connection.

Add this to .claude/settings.json to run a security scan after every file write:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "mcp_tool",
            "server": "semgrep",
            "tool": "scan_file",
            "input": { "path": "${tool_input.file_path}" }
          }
        ]
      }
    ]
  }
}

That is the whole thing. The tool's text output goes through the same JSON decision parser as any command hook. No shell, no PATH problems, no jq dependency.

What type: "mcp_tool" actually is

Before v2.1.118, hooks had four handler types: command, http, prompt, and agent. Now there are five:

command — shell subprocess (stdin/stdout)
http — POST to a URL endpoint
mcp_tool — direct RPC call to a connected MCP server
prompt — single-turn LLM evaluation (Haiku default)
agent — multi-turn subagent with Read/Grep/Glob access

The mcp_tool type works on every hook event, same as command and http. One practical caveat: SessionStart and Setup fire while servers are still connecting. Those hooks may get a "server not connected" error on first run. Subsequent runs are fine.

The full schema

{
  "type": "mcp_tool",
  "server": "my-mcp-server",
  "tool": "tool_name",
  "input": {
    "arg1": "${tool_input.file_path}",
    "arg2": "${session_id}"
  },
  "timeout": 30,
  "statusMessage": "Checking...",
  "if": "Edit(*.ts|*.tsx)"
}

Three fields are specific to mcp_tool hooks: server, tool, and input.

server must exactly match the server name in your MCP configuration. One character difference and the hook silently fails with a non-blocking error.

input values support ${field.path} dot-notation into the hook's full event JSON. For a PostToolUse hook on a Write call, the event includes tool_input.file_path, tool_input.content, session_id, cwd, duration_ms, and more. Any field is reachable.

if uses permission-rule syntax. "Edit(*.py|*.ts|*.js)" means the hook only fires when the matched file extension applies. On a docs-heavy project with constant markdown edits, this is a real performance difference.

Why this matters vs. command hooks

Two concrete differences, not just speed.

Stateful servers. A shell subprocess starts fresh every time. An MCP server is a live process with its own state: loaded configs, open connections, caches, accumulated session context. A linting MCP that pre-parsed your tsconfig.json on startup does not re-parse it on every file write. A command hook does.

No shell environment dependency. Command hooks fail silently when PATH is wrong, when jq is not installed, when ~/.zshrc prints something to stdout on non-interactive shells. MCP tool hooks bypass all of that. The call goes from Claude Code to the server over the existing RPC connection.

How the output is processed

The MCP tool's text content is treated exactly like a command hook's stdout. If it parses as valid JSON, Claude Code acts on the decision fields. If not, the text becomes context for Claude.

{
  "decision": "block",
  "reason": "Security issue found in src/api.ts: SQL injection risk on line 42."
}

Return this from a PostToolUse MCP tool hook and Claude gets the message and fixes the file. For blocking before a tool runs, use PreToolUse and return permissionDecision: "deny".

One field is exclusive to mcp_tool hooks on PostToolUse: updatedMCPToolOutput. It replaces what Claude sees as the tool's output before it enters the conversation. A running MCP server can post-process another tool's result before Claude reads it.

Pattern 1: Security scanning on every write

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "mcp_tool",
            "server": "semgrep",
            "tool": "scan_file",
            "if": "Write(*.ts|*.py|*.js|*.go)",
            "input": { "path": "${tool_input.file_path}" },
            "statusMessage": "Scanning..."
          }
        ]
      }
    ]
  }
}

The scan runs on the server's cached ruleset. Not a fresh subprocess parse on every keystroke. If the tool finds something, return decision: "block" with the finding. Claude reworks the file before continuing.

Pattern 2: Stop hook with external verification

A Stop hook that calls a Linear MCP to check whether the related ticket is actually closed before Claude declares done:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "mcp_tool",
            "server": "linear",
            "tool": "get_issue_status",
            "input": { "issue_id": "${tool_input.issue_id}" }
          }
        ]
      }
    ]
  }
}

Always check stop_hook_active in your Stop hook logic. The event JSON includes this field as "true" when Claude is already continuing from a previous Stop hook firing. A server that ignores this creates an infinite loop. Build the guard into the MCP tool: if stop_hook_active is "true" in the input, return empty output and exit cleanly.

Pattern 3: Production error check before stopping

After Claude finishes a feature, check whether anything new broke in staging before marking the session complete:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "mcp_tool",
            "server": "sentry",
            "tool": "get_new_errors_since",
            "input": { "minutes": "5", "skip_if_active": "${stop_hook_active}" }
          }
        ]
      }
    ]
  }
}

If new errors appeared in the last five minutes, the MCP tool returns them with decision: "block". Claude reads the error details and fixes the regression before stopping.

Pattern 4: Auto-inject docs before every prompt

A UserPromptSubmit hook with a Context7 MCP fetches live documentation for any library mentioned in the prompt, before Claude processes it:

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "mcp_tool",
            "server": "context7",
            "tool": "get_library_docs",
            "input": { "prompt": "${prompt}" },
            "timeout": 15
          }
        ]
      }
    ]
  }
}

Previously this required Claude to explicitly call the MCP tool. Now it happens on every prompt automatically. Claude starts with current docs instead of training data.

Pattern 5: Policy enforcement for agent teams

When running multi-agent workflows, a shared policy MCP server can enforce which agent writes to which directories:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "mcp_tool",
            "server": "policy-server",
            "tool": "check_write_permission",
            "input": {
              "agent": "${agent_name}",
              "path": "${tool_input.file_path}"
            }
          }
        ]
      }
    ]
  }
}

Update the server once and every agent in every project inherits the new rules. No touching individual settings.json files.

Pattern 6: MCP tool hooks in agent frontmatter

Hooks can live in an agent's YAML frontmatter, scoped to that agent's lifecycle:

---
name: backend-developer
description: "Builds API endpoints and database logic"
hooks:
  PostToolUse:
    - matcher: "Write"
      hooks:
        - type: mcp_tool
          server: semgrep
          tool: scan_file
          input: { "path": "${tool_input.file_path}" }
  Stop:
    - hooks:
        - type: agent
          prompt: "Verify all API endpoints have corresponding tests. Block if any are missing."
---

Each specialist agent in an orchestrated team carries its own validation logic. The backend agent scans for security issues. The frontend agent checks accessibility. Neither needs a global hook that applies to everyone.

MCP servers worth pairing with hooks

Server	Event	What it does
Semgrep	PostToolUse: Write	Security scan on every write
Sentry	Stop	Check for new staging errors before completing
Linear / Jira	Stop	Verify ticket status, update on completion
Context7	UserPromptSubmit	Auto-fetch live docs for mentioned libraries
ElevenLabs	Stop	TTS audio on task completion
Slack	Notification, Stop	Team alerts without curl boilerplate
E2B	Stop	Run generated scripts in a sandbox before marking done
claude-mem	PostCompact, SessionStart	Restore session context after compaction
n8n	TaskCompleted	Trigger an external workflow on completion

Known issue: PostToolUse + MCP events + additionalContext

There is an open bug (GitHub issue #24788) where additionalContext from hooks gets silently dropped when the triggering event was an MCP tool call. This affects type: "command" hooks that respond to MCP tool events, not mcp_tool hooks themselves.

The distinction matters: hooks that are MCP invocations work fine. Hooks that respond to MCP tool calls and return additionalContext do not. Workaround is exit 2 plus stderr for critical messages. The blocking pattern works. Advisory injection does not.

The hook system's last missing piece

Before this, hooks were a safety net. Shell commands that could block dangerous things or run formatters. Stateless, process-local, disconnected from everything your MCP servers already know.

After: hooks are a deterministic orchestration layer. Any event, any MCP tool, full decision control, with state that persists across calls and no subprocess overhead.

PreToolUse validates. PostToolUse formats and scans. PostToolBatch runs tests. Stop verifies with real external data. Every step can be an MCP tool invocation. None of them require a shell script.

Full reference with schema, substitution syntax, and all event types: https://buildthisnow.com/blog/tools/hooks/mcp-tool-hooks

5 Frontier Models Compared

speedy_devv — Thu, 23 Apr 2026 19:43:03 +0000

I kept picking the wrong model.

Not because I didn't know the benchmarks. Because the benchmarks don't tell you what a model actually costs when you're running it daily, or whether it holds up across a 3-hour agent session, or whether it can fit your whole codebase without truncating half of it.

Five frontier models shipped in early 2026. All of them are good. None of them is good at everything. DeepSeek V3.2 costs $1 per million input tokens. GPT-5.4 costs $2.50 for the same volume. That is a 2.5x spread at the top of the lineup, and the cheaper model is not always worse for the job at hand.

Here is what I learned after running them all.

The price gap nobody talks about

The headline numbers first, because they set the frame.

Model	Input / Output (per 1M tokens)	Context Window
Claude Opus 4.7	$5 / $25	1M tokens
GPT-5.4	$2.50 / $15	256K tokens
Kimi K2.6	$3 / $15	512K tokens
Gemini 3.1 Pro	$2 / $12	2M tokens
DeepSeek V3.2	$1 / $4	128K tokens

The price gap is real. DeepSeek V3.2 costs a fifth of what Opus 4.7 costs per input token. Context windows vary by 16x from smallest to largest. DeepSeek's 128K window handles a medium codebase. Gemini's 2M window fits an entire monorepo.

These gaps are not footnotes. For the right workloads, they are the whole decision.

Coding: where the separation actually shows up

The standard benchmark is SWE-Bench, real GitHub issues where the model writes a fix that passes the test suite. Good benchmark. It skews toward clean, well-specified problems.

CursorBench runs a different evaluation. Real prompts from Cursor users. Messy, underspecified, half-broken codebases. The kind of problems actual developers bring to an AI every day.

Opus 4.7 leads CursorBench at 70%. GPT-5.4 comes close at 68% on SWE-Bench. On clean, well-defined problems the two are nearly even. On messy problems, the gap widens.

What makes Opus 4.7 different on hard coding tasks is self-correction. Most models generate code, declare it done, and move on. Opus 4.7 reviews what it just wrote, spots the type error or logic gap, and fixes it in the same pass. One fewer debugging loop per session adds up across a week of engineering work. I noticed it first on a nasty legacy codebase with no tests and inconsistent patterns: Opus 4.7 held the thread across multiple refactoring steps where others started drifting.

Gemini 3.1 Pro scores 63% on SWE-Bench and is a solid coding model when the task requires pulling context from a large codebase. The 2M window means it can read the whole thing. Where it falls behind is on complex reasoning chains where the model has to hold a long chain of logic without losing it.

DeepSeek V3.2 at 52% is surprisingly capable on standard implementation tasks for its price. Clear prompt, unambiguous problem, it delivers. It does not belong on hard, ambiguous work, and it mostly knows that.

Long documents: two different dimensions

Context window size and document reasoning quality are separate things. A huge window is useless if the model loses the plot. Strong reasoning is limited if the document doesn't fit.

Gemini 3.1 Pro's 2M context is genuinely useful for real workloads: a large monorepo, a full set of legal contracts, a year of financial filings. Nothing gets truncated. If the task is "read everything and extract what matters," Gemini is the right tool.

Opus 4.7's edge is accuracy over what it reads. On dense source material, it produces 21% fewer errors than its predecessor. That gap shows up most clearly in legal and financial work where a wrong clause or misread number has consequences. You can fit more raw text into Gemini, but Opus 4.7 does more with the text it reads.

A practical combination for large, high-stakes documents: Gemini 3.1 Pro for the initial pass across the full document, Opus 4.7 for the sections that require careful reasoning. Full picture from Gemini, accuracy from Opus on the parts that matter.

Multi-step agents: where the real separation is

Agent tasks are where the gap between models becomes undeniable. A model that is great at one-shot prompts can fall apart when it has to run for 20 steps, use tools, and keep track of what it already did.

The failure mode looks the same across models: the agent starts losing coherence around step 10 to 15. It forgets what it already checked. It tries an approach it already tried. It produces a "done" message when the task is half-finished.

Opus 4.7 stays coherent across hours of work. It has the lowest tool error rate of the group. When a tool call returns an unexpected result, it adjusts rather than proceeding on a false assumption. The practical payoff: you can set Opus 4.7 on a multi-hour task, walk away, and come back to actual results.

GPT-5.4 is strong on short chains, 3 to 5 steps, well-defined, fast. It is the fastest model in this group, which matters for interactive workflows where you are watching and course-correcting in real time. At the long end, reliability drops compared to Opus 4.7.

DeepSeek V3.2 is the right call for lightweight agent work at volume. Bulk tagging, classification pipelines, structured extraction from well-formatted documents. Running 10M tokens through DeepSeek instead of Opus saves about $61 per batch.

What it actually costs per real workload

Headline prices only tell half the story. The actual cost depends on what you are running.

Daily coding sessions (roughly 200K tokens each):

Model	Cost per Session
DeepSeek V3.2	$0.26
Gemini 3.1 Pro	$0.75
Kimi K2.6	$0.90
GPT-5.4	$1.60
Opus 4.7	$1.75

For coding sessions, DeepSeek is nearly 7x cheaper than Opus 4.7. GPT-5.4 and Opus are actually close in per-session cost — GPT-5.4 wins on speed, Opus wins on hard problems.

High-volume automation (10M tokens per month):

Model	Monthly Cost
DeepSeek V3.2	$14
Gemini 3.1 Pro	$35
Kimi K2.6	$39
Opus 4.7	$75
GPT-5.4	$78

At bulk volumes, DeepSeek is in a different price category. $14 versus $78 for the same token volume is a fundamentally different operating cost. Gemini 3.1 Pro at $35/month is the surprise here: 2M context at less than half the price of Opus.

The default pair for most builders

Opus 4.7 handles the tasks where quality decides the outcome: hard coding, debugging legacy code, long agent runs, precise document analysis. DeepSeek V3.2 handles the tasks where volume and cost decide the outcome: bulk automation, classification, templated generation, anything with a clear spec.

Those two together cover 90% of what most builders actually need.

The other three have specific edges worth knowing. Gemini 3.1 Pro for any workload that needs a 2M context window at a competitive price. GPT-5.4 for fast interactive work on clean codebases. Kimi K2.6 for Chinese-language documents at a competitive price.

The question is never "which model is best." It is "which model is right for this task." Get that right and you spend less, finish faster, and fix fewer mistakes on the other side.

Full breakdown with all the benchmark tables and cost scenarios is here: buildthisnow.com/blog/models/2026-04-21-opus47-vs-frontier

Claude Opus 4.7: What Actually Changed for Agentic Coding

speedy_devv — Thu, 16 Apr 2026 17:46:11 +0000

Anthropic shipped Opus 4.7 on April 16, 2026. Same $5/$25 pricing as 4.6. Same 1M context. Same 128K output ceiling. Different model entirely when you put it in an agentic coding loop.

If you run Claude Code or build agent pipelines on the Claude API, this post is the migration brief I wish someone had handed me on release day. Benchmarks, the five behavioral shifts that actually matter, the new API features, and the breaking changes you will hit if you just flip the model ID.

The Benchmark Table First

| Benchmark              | Opus 4.6 | Opus 4.7              |
|------------------------|----------|-----------------------|
| CursorBench            | 58%      | 70%                   |
| Rakuten-SWE-Bench      | Baseline | 3x resolution         |
| XBOW visual-acuity     | 54.5%    | 98.5%                 |
| OfficeQA Pro errors    | Baseline | 21% fewer             |
| BigLaw Bench (Harvey)  | Lower    | 90.9% at high effort  |
| Notion Agent errors    | Baseline | 1/3 the errors        |
| Factory Droids         | Baseline | +10-15% task success  |
| Bolt long-running apps | Baseline | +10% best case        |
| CodeRabbit recall      | Baseline | +10%                  |

Rakuten's 3x is the one I keep coming back to. That is real production SWE tasks, not a synthetic eval. CursorBench moving 58 to 70 is what you actually feel in a Claude Code session: fewer rounds per feature.

Five Behavioral Shifts

1. Self-Verification Is New

Prior Claude models did not verify their own assumptions before acting unless you prompted them to. 4.7 does.

Vercel reports the model runs proofs on systems code before starting work. Hex reports it flags missing data instead of inventing plausible-but-wrong fallbacks, and resists dissonant-data traps that 4.6 falls for.

In a Claude Code session this looks like:

Before I write this migration, let me verify the actual shape
of the response object, because my assumption here might be wrong.

[reads file]
[runs grep]

Confirmed. Writing migration now.

You did not ask for that step. The model added it.

2. Long Runs Stay Coherent

Devin reports 4.7 works coherently for hours on hard problems instead of giving up. Genspark measured loop rates: prior models looped indefinitely on roughly 1 in 18 queries, 4.7 posts the highest quality-per-tool-call ratio they have ever measured.

Notion saw tool errors cut to a third of 4.6's rate on multi-step workflows. That is not a small optimization. That is a different failure mode.

3. Fewer Tool Calls, More Thinking

Default behavior shifted. 4.7 thinks more and acts less. Ramp reports less need for step-by-step guidance on cross-tool, cross-codebase debugging.

If you want the old tool-heavy behavior, raise effort:

claude --model claude-opus-4-7 --effort high
# or
claude --model claude-opus-4-7 --effort xhigh

4. Instructions Get Read Literally

Prompts that relied on 4.6 quietly filling in the gaps will hit unexpected behavior on 4.7. The fix is usually shorter and more explicit, not longer.

5. Fewer Subagents by Default

If your orchestrator relied on 4.6 fanning out aggressively to specialists, 4.7 will pull that back. You can still request parallel subagent work explicitly.

The `xhigh` Effort Tier

Adaptive thinking gained a fifth setting. Ordering is now:

low < medium < high < xhigh < max

xhigh sits between high and max. Claude Code raised the default to xhigh on all plans.

For API work, Anthropic recommends starting at xhigh and dialing down:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=8192,
    thinking={"type": "adaptive", "effort": "xhigh"},
    messages=[{"role": "user", "content": "Your agentic task here"}]
)

Hex's quote is the cost-math line worth memorizing: "low-effort Opus 4.7 is roughly equivalent to medium-effort Opus 4.6." Same quality, lower tier, fewer tokens.

Task Budgets (Public Beta)

Task budgets are the feature I keep recommending first. An advisory cap on a full agentic loop: thinking, tool calls, tool results, final output. The model sees a running countdown and self-paces against it.

Minimum value is 20k tokens. Distinct from max_tokens, which is a hard ceiling the model never sees.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=8192,
    extra_headers={
        "anthropic-beta": "task-budgets-2026-03-13"
    },
    task_budget=200000,
    thinking={"type": "adaptive", "effort": "xhigh"},
    messages=[{"role": "user", "content": "Build this feature end to end"}]
)

The model can now plan: "I have 200k tokens to spend. I will use 30k on exploration, 90k on writing, 40k on review, and leave a buffer." A hard max_tokens just cuts off mid-thought.

Vision: 3x Resolution

First Claude model with high-resolution image support. Max image resolution went from 1568px / 1.15MP on prior models to 2576px / 3.75MP on 4.7. Roughly 3x the pixel budget.

What changes in practice:

Dense screenshots where small text has to be readable
Complex diagrams with nested labels
High-fidelity design mockups
Pointing, measuring, counting, bounding-box localization
Coordinates returned are 1-to-1 with real image pixels (no scale conversion)

Cost note: a full-resolution image can consume up to roughly 4,784 tokens, versus roughly 1,600 on prior models. Downsample when you do not need the fidelity.

Breaking Changes in the API

This is the section you have to read before flipping the model ID.

Extended Thinking Is Removed

# 4.6 and earlier (still valid on 4.6)
thinking={"type": "enabled", "budget_tokens": 8192}

# 4.7 (old shape returns 400)
thinking={"type": "adaptive", "effort": "xhigh"}

Adaptive thinking is now off by default on 4.7. A request with no thinking field runs with no thinking at all.

Sampling Parameters Are Removed

Setting temperature, top_p, or top_k to non-default values returns a 400:

# Returns 400 on 4.7
response = client.messages.create(
    model="claude-opus-4-7",
    temperature=0.7,  # <-- remove this
    top_p=0.9,        # <-- remove this
    messages=[...]
)

Drop them. Use prompting to shape behavior.

Thinking Content Is Omitted by Default

Thinking blocks still appear in the response stream but their thinking field is empty unless you opt in:

thinking={
    "type": "adaptive",
    "effort": "xhigh",
    "display": "summarized"
}

If your UI streamed thinking to users on 4.6, the new default reads as a long pause before output begins. Add display: "summarized" back.

Prefill Is Blocked

Prefilling assistant messages returns a 400. Use structured outputs or output_config.format instead. This one carries over from 4.6.

New Tokenizer

The same input can now map to 1.0x to 1.35x the prior token count, content-dependent. Re-run /v1/messages/count_tokens against your representative payloads and re-baseline:

max_tokens ceilings
Compaction triggers
Client-side token estimates
Cost projections

Automated Migration

Inside Claude Code, most of the above is handled for you. On the API side:

claude /claude-api migrate

Applies the changes across the codebase.

New Product Features

/ultrareview runs a review session reading through changes and flagging bugs a careful human reviewer would catch. Pro and Max users get three free ultrareviews. I have been using it as a pre-commit gate.

Auto mode for Max. Previously gated to Team and Enterprise. Now extends to Max subscribers. Longer runs with fewer interruptions, and with less risk than fully skipping permissions.

File-system memory improvements. Agents keeping a scratchpad, notes file, or structured memory store across turns make cleaner notes and actually leverage them on later tasks.

Pricing Did Not Move

Input:        $5.00 / 1M tokens
Output:      $25.00 / 1M tokens
Prompt cache: up to 90% savings
Batch:        50% savings

Two things will nudge your bill up:

New tokenizer (up to 1.35x input token count on some content)
High-resolution images (up to ~4,784 tokens each)

Task budgets and the effort parameter are how you trade back.

On GitHub Copilot, 4.7 went GA the same day on Pro+, Business, and Enterprise, carrying a 7.5x premium request multiplier through April 30 as promotional pricing.

Switching Claude Code to 4.7

# Set as default
claude config set model claude-opus-4-7

# Or override per session
claude --model claude-opus-4-7

The opus alias in Claude Code points at it on current releases. Available on claude.ai, Claude Platform API, AWS Bedrock (research preview), Google Cloud Vertex AI, Microsoft Foundry, and GitHub Copilot.

When to Reach for It

4.7 when reasoning depth, long agent runs, or high-resolution screenshots are what the job needs. Sonnet 4.6 is still the right call for smaller, faster work where speed and cost decide the tradeoff.

Full breakdown on the webapp: buildthisnow.com/blog/models/claude-opus-4-7

Build your own agentic SaaS with Claude Code in 48 hours: buildthisnow.com