When I first wired Claude into my n8n ticket triage workflow, the cost math gave me pause. Running Opus-class reasoning on every inbound support ticket was justifiable for complex cases, but hard to swallow for the roughly 60 percent of tickets that were entirely straightforward. Sonnet 4.6 was cheaper, but I'd seen it drop context on longer ticket threads and occasionally produce drafts that needed more editing than they saved. So I ran a hybrid: Sonnet for intake classification, Opus for anything requiring synthesis or a nuanced customer response. That extra routing logic added complexity I'd rather not maintain.
On June 30, Anthropic released Claude Sonnet 5. The TechCrunch headline described it as a cheaper way to run agents. After rebuilding three workflows around it over the past week, I'd refine that: it's a materially more capable model at the same or lower cost. For support automation specifically, that distinction matters.
What Sonnet 5 Actually Is
Sonnet 5 sits between the outgoing Sonnet 4.6 and the full Opus 4.8. On SWE-bench Pro, Anthropic's standard agentic benchmark, it scores roughly 63 percent, against 58 percent for Sonnet 4.6 and 69 percent for Opus 4.8. That's a real gap closed. You get most of Opus's agentic capability without paying Opus prices.
The improvements that matter for support work:
- Better multi-step tool use. Sonnet 5 completes agentic tasks where 4.6 would stall mid-flow and require a retry or a prompt rewrite. On a classification plus draft-response workflow, that reliability difference is the whole game.
- Lower hallucination rate vs 4.6. Critical when the model is drafting first responses. A factually wrong draft that an agent sends without reading closely is a CSAT problem, not just a model quality problem.
- Stronger prompt injection resistance. Support tickets are user-generated text. Some customers have figured out that certain phrasing can redirect a naive AI agent's behavior. Sonnet 5 is meaningfully more resistant to this than its predecessor, according to Anthropic's safety assessment.
- Better context retention across longer threads. Long ticket threads, especially escalations with six or more replies, were where Sonnet 4.6 would lose the plot. Sonnet 5 handles longer context without the same degradation.
Introductory pricing is $2 per million input tokens and $10 per million output tokens, running through August 31, 2026. After that it moves to $3 per million input and $15 per million output. For reference, Sonnet 4.6 runs at $3/$15 and Opus 4.8 runs at $5/$25. The intro window gives you near-Opus capability at well below Sonnet 4.6 pricing. Even at standard pricing, you get the same cost as 4.6 with noticeably better results.
How My Current n8n Setup Works
The core workflow is a ticket intake pipeline. When a new ticket arrives in Help Scout, n8n fires. The workflow pulls the ticket body and any existing thread history, sends it to Claude with a classification prompt, and gets back: ticket category, urgency level (1 through 3), whether this customer has raised the same issue before, and a suggested first-response draft. That output posts as an internal note in Help Scout, visible to the agent before they type anything.
Routing then branches on urgency. Level 1 tickets get an immediate Slack ping to the on-call agent. Levels 2 and 3 join the normal queue with the classification note attached.
A second workflow handles escalation detection. When a ticket has had three or more agent replies without a resolution tag, n8n triggers a separate Claude call that reviews the full thread, identifies the sticking point, and drafts a handoff summary for the senior agent taking over. The idea is that whoever picks it up cold shouldn't have to re-read the whole thread.
Both workflows were built on Sonnet 4.6. The classification workflow ran reliably. The escalation workflow had a documented weakness: on threads longer than roughly 15 exchanges, it would miss context from the early replies and occasionally misdiagnose the stall reason.
What I'm Changing
The model swap in n8n is a single node update per workflow. What I'm actually rebuilding is the prompt structure and some preprocessing logic, because Sonnet 5 handles more in one pass.
Ticket classification: I previously ran two separate API calls, one to classify and one to draft the response, because combining them in a single prompt made Sonnet 4.6 less consistent. Sonnet 5 handles both reliably in one call. That cuts latency per ticket by roughly 35 to 40 percent and halves the token cost on the classification workflow, since I'm making one call instead of two.
Escalation detection: I'm removing the preprocessing step that truncated long threads before sending them to the model. That was a workaround for Sonnet 4.6's context drift on long inputs. Sonnet 5 handles the full thread accurately. Removing the truncation logic takes out roughly 80 lines of preprocessing code and, more importantly, eliminates the edge case where the truncation itself caused the model to miss an early piece of context that was actually the crux of the issue.
L2 response drafting: This is new. Previously, the first-response draft only ran on Level 1 tickets, where the answer was typically a policy reference or a step-by-step instruction. L2 tickets were flagged for a human first response. With Sonnet 5's improved accuracy on nuanced replies, I'm extending the draft to L2 as well. The agent still reviews and edits every draft before sending. But having a strong starting point cuts average handle time meaningfully on the tickets that previously required the agent to compose from scratch.
What Stays on Opus 4.8
Not every workflow moves. Two stay on Opus 4.8 and will stay there for now.
Knowledge base article generation. When a ticket pattern repeats often enough, a separate workflow drafts a KB article from the ticket cluster and its resolutions. Longer-form writing with precise technical detail is still where Opus earns its cost premium. The gap between Opus and Sonnet 5 on this type of output is noticeable. Since this workflow runs maybe 10 to 15 times a week rather than on every ticket, the cost difference is manageable.
Weekly root cause analysis. A Sunday-night workflow pulls the previous week's tickets, clusters them by theme, and produces a summary of recurring issues with resolution patterns. The synthesis quality on Opus is genuinely better for this kind of cross-ticket reasoning. Runs once a week, so the higher per-run cost is justified.
The honest framework: use Sonnet 5 for high-frequency, per-ticket workflows where cost compounds quickly. Use Opus for low-frequency, high-stakes synthesis where quality delta matters more than cost.
The August 31 Window
If you're running or rebuilding Claude-based support automation, there's a practical timeline here. Sonnet 5's introductory pricing of $2/$10 per million tokens runs through August 31. After that, it moves to $3/$15, which is still excellent value for what you get, but the next eight weeks are the optimal time to run volume tests and benchmark your specific workflows against your current setup.
The concrete recommendation: pick your highest-frequency Claude workflow, the one you run on every ticket, and run a parallel test with Sonnet 5 for one week. Compare classification accuracy, draft quality, and any failure modes. If it holds up (it should), swap the model and bank the cost saving for the rest of the intro window. Then evaluate whether the standard pricing still pencils out at your volume when September comes. For most support automation workloads, it will.
The intro price makes the evaluation period cheaper. The capability upgrade is the actual reason to update.
Sources
- Anthropic: Introducing Claude Sonnet 5
- TechCrunch: Anthropic launches Claude Sonnet 5 as a cheaper way to run agents (June 30, 2026)
- MarkTechPost: Claude Sonnet 5 vs Sonnet 4.6 vs Opus 4.8 benchmarks and pricing (June 30, 2026)
- Anthropic Claude Platform: Pricing
If you're running Claude in a support automation stack and want to compare notes on what's working and what isn't, reach out here.
Comments