I Tested Claude Opus 4.7, Opus 4.6, and GPT-5.5 on Real Coding Tasks

The week of April 16, 2026 was a genuinely strange one to be a developer.

Anthropic dropped Claude Opus 4.7 on Tuesday. Seven days later, OpenAI shipped GPT-5.5. Both claimed to be the best model for coding. Both had benchmark tables that told a different story depending on which row you looked at. My Twitter feed went from “Opus 4.7 is incredible” to “actually GPT-5.5 destroys it” within 72 hours, often from people who had used each model for approximately two hours.

I decided to test them myself. For real. On the actual codebase my team works in daily.

This post is what I found.

---

⚡ TL;DR (For People Who Don’t Have 12 Minutes)

What you’re doing	Use this
Fixing hard bugs in a real codebase	Opus 4.7
Unattended shell/terminal automation	GPT-5.5
Daily pair programming (fast iteration)	GPT-5.5
Code review and architecture decisions	Opus 4.7
Tight API budget, high output volume	GPT-5.5 (72% fewer output tokens)
Upgrading from Opus 4.6?	Yes — but benchmark your costs first
Single model for everything	Opus 4.7 (wins more categories that matter)

Short version: Opus 4.7 is better at hard thinking. GPT-5.5 is faster and cheaper to run at scale. Neither is obviously right for every team. The rest of this post shows you exactly how I landed on that.

---

The Setup: What I Tested and Why It Matters

I want to be upfront about methodology, because most “I tested these models” posts are actually “I sent five prompts to each model and picked my favorite response.”

That’s not what I did.

Our codebase context: We run a Python/FastAPI backend with a PostgreSQL database, a React frontend, a handful of internal services, and a CI/CD pipeline that’s been in production for three years. It’s not a toy project. It has real technical debt, a real test suite (~2,200 tests), and real legacy decisions that made sense at the time.

What I tested (four task types):

1. Bug fixing — an actual intermittent race condition we’d been chasing for two weeks
2. Refactoring — breaking up a 2,200-line orders module that had become unmaintainable
3. Large-context reasoning — architecture questions with the full codebase in context (~180K tokens)
4. Agentic workflow — a 6-step autonomous task running without human intervention between steps

How I controlled for fairness:

• Same system prompt for all three models
• Same task descriptions, same attached files, same context
• Effort levels set to each model’s highest non-max setting: Opus 4.7 at xhigh, Opus 4.6 at high, GPT-5.5 at xhigh
• Each task run 3 times per model; I’m reporting median results
• I evaluated output by running the actual code — tests pass or they don’t

I’m an engineer, not a benchmark scientist. My evaluation isn’t perfect. But it’s a lot closer to “real” than most comparison posts you’ll read.

---

The Models, Briefly (So We’re on the Same Page)

Claude Opus 4.7 — Released April 16, 2026. Anthropic’s current flagship for production coding and agentic workflows. The headline number is 64.3% on SWE-bench Pro, up from Opus 4.6’s 53.4%. The big new feature most people don’t talk about: it verifies its own output before reporting back. Same price as 4.6 on paper ($5/$25 per million tokens), but a new tokenizer means real costs can run 0–35% higher on the same prompts.

Claude Opus 4.6 — The previous flagship. Still available, still strong. I included it because most teams aren’t starting from scratch — they’re deciding whether to upgrade from something they already know and trust.

GPT-5.5 — Released April 23, 2026. OpenAI’s new frontier model, codenamed “Spud” internally. The headline is 82.7% on Terminal-Bench 2.0 (command-line/shell agentic tasks). It generates approximately 72% fewer output tokens than Opus 4.7 on equivalent tasks — which sounds like a detail but has significant cost implications at production scale. Priced at $5/$30 per million tokens — same input, 20% higher output rate than Opus 4.7.

---

Test 1: The Race Condition That Had Been Ruining Our Week

We’d been chasing an intermittent bug for two weeks. The error appeared under load — specifically, when multiple async database writes hit the same table within a narrow time window. The traceback pointed to our async context manager in the db/session.py module, but the failure wasn’t deterministic and our initial fixes hadn’t held.

What I gave each model:

• The full db/session.py module (~400 lines)
• Three related utility files (db/pool.py, services/order_writer.py, utils/retry.py)
• The error traceback (sanitized)
• The instruction: “Identify the bug and propose a fix. Do not explain what async context managers are — I know. Just find the problem.”

Opus 4.6’s Response

Opus 4.6 identified the likely culprit in about 45 seconds: a missing await in the async context manager exit method. The fix it proposed was clean and correct for that specific issue. I ran the tests. Most passed.

But the bug came back under load the next day.

Looking back at its response, Opus 4.6 had found the obvious surface issue and stopped there. It never looked at db/pool.py, which had a related problem: shared mutable state in the connection pool configuration that wasn’t properly isolated between concurrent requests. That was the second failure mode, and Opus 4.6 never flagged it.

Grade: Identified part of the problem. Missed the full picture.

---

Opus 4.7’s Response

Opus 4.7 was slower to respond — maybe 20 seconds more than Opus 4.6. What it produced was noticeably different.

It found the same missing await. But before delivering its fix, it added a section I didn’t ask for:

“Before I propose a fix, I want to flag a related issue I noticed in db/pool.py at line 147. The _pool_config dict is being mutated without a lock in configure_pool(), which is called during session initialization. In a high-concurrency async context, this can produce a race condition independent of the context manager issue. I’d recommend addressing both simultaneously.”

I stared at that for a second. I hadn’t mentioned db/pool.py in the prompt. It had read all four files and connected a dot I’d been too tunnel-visioned to see.

The fix it proposed covered both issues. I ran the test suite — 2,247 tests, all green. I ran the load test — no failures after 50,000 requests.

The bug that had cost us two weeks was gone after one Opus 4.7 session.

Grade: Found the complete problem without being asked. Fix held under load.

---

GPT-5.5’s Response

GPT-5.5 found the await issue quickly and accurately. Its response was about 60% shorter than Opus 4.7’s — no verbose preamble, no “here’s what I noticed” section. Just: problem identified, fix proposed, done.

It did not flag the db/pool.py issue unprompted. When I explicitly told it about that file and asked it to look, it produced a clean fix in seconds.

Grade: Correct and fast on the stated problem. Missed the proactive catch. Better as a directed tool than an autonomous investigator.

---

Test 1 Verdict: Opus 4.7 won — and it wasn’t close. The proactive catch of a related bug we didn’t know to ask about is exactly what “self-output verification” means in practice. GPT-5.5 was faster and more concise, but conciseness that misses a bug costs more than verbosity that finds one.

---

Test 2: The Refactoring Task Nobody Wanted to Touch

Our orders module had been growing since 2023. By April 2026 it was 2,200 lines across three files, handling order creation, inventory checks, payment processing, and notification dispatch — all in the same module because “we’ll clean it up later.”

Later had arrived.

What I gave each model:

• All three orders files in full
• The existing test coverage for those modules (~340 tests)
• The instruction: “Decompose this into four services with clean interfaces. Preserve all existing caller interfaces — there are 22 call sites across the codebase I don’t want to touch.”

The “preserve caller interfaces” instruction was the critical constraint. I deliberately didn’t list the call sites — I wanted to see if each model would figure out what mattered without being told.

Opus 4.6’s Response

Opus 4.6 produced a thoughtful decomposition plan. The proposed service boundaries made sense. Then I looked more carefully.

Two of the proposed interfaces had signature changes that would break existing callers. Not obvious breaks — subtle ones. create_order() had gained a new required parameter that was actually optional in the current implementation. The check_inventory() return type had shifted from a tuple to a dict.

When I flagged these, Opus 4.6 corrected them immediately. But it required flagging. Left unsupervised, those changes would have broken production.

Grade: Good structural thinking. Needed intervention to respect the interface constraint fully.

---

Opus 4.7’s Response

Opus 4.7’s decomposition was slightly less elegant structurally — GPT-5.5 would produce cleaner naming — but it did something neither other model matched: it explicitly listed the 22 call sites it had identified and noted exactly which interfaces it was preserving and why.

“I’ve identified 22 external call sites across the codebase from the files you shared. I’m maintaining the following signatures unchanged: create_order(customer_id, items, metadata=None), check_inventory(sku_list, warehouse_id=None), process_payment(order_id, payment_method), and send_order_notification(order_id, channel='email'). Any signature changes would require updates to callers I can see — I’m flagging this rather than making the decision for you.”

I hadn’t given it a list of call sites. It had read the files, found them, and surfaced the constraint back to me with its own audit. The resulting refactor required zero changes to existing callers. Every one of the 340 tests passed on first run.

Grade: Respected the hardest constraint autonomously. Surfaces its own audit trail.

---

GPT-5.5’s Response

GPT-5.5 produced the most idiomatic design of the three. The service naming was cleaner, the interface design more elegant, and the overall structure was what a senior engineer would sketch on a whiteboard. I genuinely liked reading it.

It missed one integration point — a shared status enum between the payment and inventory services that needed to move — and it didn’t audit the caller interfaces unprompted. After I pointed out the enum issue and the interface constraint, it corrected both cleanly. But it needed the direction.

Grade: Best design aesthetic. Required steering on the critical constraints.

---

Test 2 Verdict: Opus 4.7 again, for autonomous correctness on a task with a hard constraint I didn’t fully spell out. GPT-5.5’s output was prettier, but pretty code that breaks callers is expensive to fix. If I were doing this refactor in a supervised pair-programming session, I’d prefer GPT-5.5’s aesthetic. In an agent running without human checkpoints, Opus 4.7’s thoroughness is what keeps you from deploying a breaking change.

---

Test 3: Architecture Questions with 180,000 Tokens in Context

For this test, I loaded the entire repository snapshot into context — services, tests, configuration, documentation, everything. Approximately 180,000 tokens. Then I asked three questions I genuinely didn’t have confident answers to:

1. Where should we introduce a caching layer to get the most latency improvement?
2. If we upgrade sqlalchemy from 1.4 to 2.x, what’s the blast radius?
3. Which components have implicit coupling that isn’t documented anywhere?

Question 3 was the trap. Implicit coupling is by definition not in the docs. Finding it requires actually reading the code.

Opus 4.6

Answered Q1 reasonably — identified the right database query as the latency bottleneck. Gave a partial answer on Q2 — missed two downstream services affected by the SQLAlchemy migration. Didn’t find the implicit coupling on Q3. It said “the codebase appears well-structured with clear separation of concerns,” which is exactly what a model says when it hasn’t deeply read the code.

Opus 4.7

Found the caching opportunity correctly. On Q2, produced the most complete blast radius map of the three — it identified all affected services, including a utility that used SQLAlchemy’s legacy Query API in a way I’d forgotten about.

On Q3 — implicit coupling — it found three undocumented dependency paths. Our senior engineer confirmed all three were real. The one that surprised me most: our notification service was making a direct database call to the orders table instead of going through the order service API. Nobody had documented that. It had been in the code for 18 months. Opus 4.7 found it.

GPT-5.5

Also found the caching opportunity. The blast radius answer was the most precise of the three — it cited specific line numbers and function names from the affected files, which made it easy to verify. On the implicit coupling question, it found two of the three undocumented paths Opus 4.7 caught. It missed the notification service direct DB call.

Test 3 Verdict: Opus 4.7 on comprehensiveness; GPT-5.5 on precision and citability. For architecture review sessions where you want a human to verify the findings, GPT-5.5’s specific citations are easier to work with. For autonomous discovery where you need complete coverage, Opus 4.7’s read is deeper. At 180K tokens, both are strong. Based on the benchmark data (MRCR v2: 74.0% GPT-5.5 vs 32.2% Opus 4.7 at 1M tokens), I’d expect GPT-5.5’s advantage to compound significantly near the 1M token limit.

---

Test 4: The Agentic Pipeline Test

This is the test that matters most for how developers actually use these models in 2026 — not as a chat tool, but as an agent running a multi-step workflow.

The task: Six steps, no human intervention between them.

1. Read a feature spec from a markdown file
2. Write the implementation (a new webhook handler with signature verification)
3. Run the existing test suite
4. Read the test output
5. Fix any failures
6. Run tests again and confirm passing

I set this up with tool access: file read/write, bash execution, test runner. Each model ran the full workflow autonomously.

Opus 4.6 — Where It Got Stuck

Steps 1–3 went fine. At step 4, reading the test output, Opus 4.6 misread one failure.

The test was failing because of an import path issue — the new handler module was in the wrong directory. But Opus 4.6 categorized it as a SignatureVerificationError (a logic bug in the implementation itself) and applied the wrong fix.

Step 5 introduced a change to the signature verification logic that wasn’t needed. Step 6 — running tests again — produced a different failure from the change it had just made. It entered a correction loop. Two more iterations before it stabilized.

Total: 4 test runs, 3 unnecessary code changes, correct output on the 4th run.

The implementation was ultimately correct. But if this were running in a CI/CD pipeline at 3am, I’d have a confusing commit history and wasted compute.

---

Opus 4.7 — The Verification Behavior in Action

Steps 1–2 ran cleanly. The implementation Opus 4.7 wrote was actually more careful than what I would have written — it added a hmac.compare_digest() call for the signature check instead of a plain ==, which is the correct timing-safe comparison. I hadn’t specified that. It knew.

Step 3: tests ran. Two failures.

Step 4 is where the difference showed up. Before applying any fix, Opus 4.7 wrote:

“Before I fix these failures, let me categorize them. Failure 1: ModuleNotFoundError: No module named 'services.webhooks.handler' — this is an import path issue, not a logic bug. The module needs to be at services/webhooks/handler.py, not services/handler.py. Failure 2: AssertionError in test_webhook_signature_valid — this is a test setup issue; the test is using a hardcoded HMAC key that doesn’t match the one in my implementation. I’ll fix both.”

One fix for the import path. One fix for the test fixture. Step 6: all tests pass.

Total: 2 test runs, 2 targeted changes, passing on the second run.

This is the self-verification behavior Anthropic described in the release notes. It’s not a minor improvement. It’s the difference between an agent that compounds its own mistakes and one that breaks the problem down correctly before touching anything.

---

GPT-5.5 — Fast, Quiet, Effective

GPT-5.5 also completed the task correctly in two test runs. Its implementation was clean and concise. It correctly identified both failure types without narrating its reasoning at length — it just fixed them and ran the tests.

Where it differed from Opus 4.7: it did not add the hmac.compare_digest() security improvement unprompted. The spec didn’t ask for it. GPT-5.5 implemented exactly what was specified. Opus 4.7 implemented what was specified plus one security improvement it decided was obviously correct.

Whether that’s a feature or a bug depends on your philosophy. I think it’s a feature for security-sensitive code. GPT-5.5 would argue it’s more predictable.

GPT-5.5’s response was also significantly shorter. Where Opus 4.7 narrated each step in detail, GPT-5.5 ran the workflow more quietly. In a single test, that’s just style. Across 1,000 agent runs per day, it’s the difference between $250/day and $350/day in output token costs.

Test 4 Verdict: Both Opus 4.7 and GPT-5.5 outperformed Opus 4.6 clearly. Opus 4.7 wins on autonomous correctness and proactive security improvement. GPT-5.5 wins on token efficiency and predictability. For agentic pipelines where you care most about cost at scale, GPT-5.5 is compelling. For pipelines where one missed error costs you more than the token savings, Opus 4.7’s thoroughness is worth the premium.

---

The Cost Math Nobody Is Doing Correctly

Everyone quotes the rate card. Almost nobody calculates actual cost per completed task.

Here’s the real math for our agentic pipeline test:

Model	Test runs to completion	Est. output tokens	Output cost @ rate	Effective cost/task
Opus 4.6	4 runs	~8,200 tokens	~$0.205	$0.205
Opus 4.7	2 runs	~5,400 tokens	~$0.135	$0.135 (+ tokenizer delta)
GPT-5.5	2 runs	~1,800 tokens	~$0.054	$0.054

These are estimated from our test runs — not precise billing data, but directionally correct.

The GPT-5.5 number is striking. Even though its output rate is $30/M (vs Opus 4.7’s $25/M), it produced roughly 72% fewer output tokens. The per-task output cost is less than half of Opus 4.7’s and about a quarter of Opus 4.6’s.

At 1,000 agentic tasks per day — a realistic production volume — that’s:

• Opus 4.6: ~$205/day
• Opus 4.7: ~$135/day (before tokenizer delta on input)
• GPT-5.5: ~$54/day

GPT-5.5’s token efficiency advantage is real. On high-volume pipelines, it changes the cost conversation entirely.

The caveat: this was our specific task on our specific codebase. GPT-5.5’s token advantage was largest on the agentic workflow test (where verbosity compounds across many steps). On the bug fixing and architecture tests, the gap was smaller because Opus 4.7’s reasoning depth was delivering genuine additional value.

My rule of thumb: If you’re running 500+ agentic tasks per day, run GPT-5.5 in parallel on 10% of traffic and measure the quality delta. If quality holds, the cost argument for GPT-5.5 is strong. If quality drops on your specific task type, the Opus 4.7 premium is justified.

---

What Actually Changed Between Opus 4.6 and Opus 4.7

Based on our tests and the official benchmark data:

What’s genuinely different:

The self-verification behavior is the real story of Opus 4.7. In two of our four tests, it caught something before applying a wrong fix that Opus 4.6 would have applied. At scale, that’s a significant reduction in the probability of compounding errors in agentic loops.

Instruction-following is more literal. This is great when your instructions are precise. It’s slightly frustrating when you relied on Opus 4.6’s interpretive flexibility to fill gaps. Review your prompts before migrating — some may need tightening.

The SWE-bench Pro improvement (53.4% → 64.3%) showed up in our tests as a real difference on the hardest tasks. Not on every task — Opus 4.6 handled most of our routine work fine. But on the race condition bug and the large-context architecture questions, Opus 4.7 consistently went deeper.

What people aren’t talking about:

The tokenizer change is the hidden cost story. The new tokenizer can produce up to 35% more tokens for the same input text. On our prompts — mostly code and structured data — we measured a roughly 18–22% increase in input token counts after migration. That’s not in the rate card. Plan for it.

Your prompt cache also resets on migration. Every cached input is invalidated because the tokenizer produces different token boundaries. On the first day after migration, your cache hit ratio drops to zero and rebuilds. For teams relying heavily on prompt caching for cost control, this is a meaningful one-time cost hit.

---

Which Model Should You Use?

Here’s my honest answer by persona — not a generic “it depends.”

You’re a solo developer building a product: Opus 4.7. You’re making complex decisions without a second engineer to catch mistakes. The proactive catch behavior and reasoning depth reduce your error rate. The token cost is real but manageable at solo volume.

You’re a startup with a small team (2–10 engineers): Opus 4.7 for complex work, Sonnet 4.6 for routine implementation. Don’t route everything through Opus — you’re paying a premium you don’t need on straightforward tickets. Use Opus 4.7 for architecture decisions, hard bugs, and refactoring sessions. Use Sonnet for everything else.

You’re running a high-volume agentic pipeline: Test GPT-5.5 seriously. The 72% output token efficiency advantage is not a rounding error. If your quality metrics hold on GPT-5.5, the cost savings at scale justify the switch. If they don’t, the data is in front of you.

You’re doing daily pair-programming in Cursor or a similar tool: GPT-5.5. It’s faster, more concise, and the interactive back-and-forth pace makes its directness an asset rather than a limitation. Use Opus 4.7 for the review pass.

You’re an enterprise team with large codebase reasoning needs: Split traffic. Opus 4.7 for code review, refactoring, and architecture. GPT-5.5 for automated pipelines. This isn’t hedging — it’s how the two models’ strengths actually map to different parts of a mature engineering workflow.

---

My Final Take

I came into this expecting GPT-5.5 to be a clear challenger and Opus 4.7 to defend its title narrowly. What I found was more nuanced.

Opus 4.7 is genuinely better at the tasks where better is hardest to fake: finding a bug you didn’t know existed, respecting a constraint you only half-specified, catching a security issue in a webhook implementation you said nothing about. That’s not benchmark performance — that’s the model understanding the shape of a problem more deeply than you described it.

GPT-5.5 is genuinely better at something equally important: running 1,000 tasks efficiently. The token efficiency isn’t a PR claim — it showed up clearly in our agentic tests. For teams where volume and cost matter more than finding the last 10% of edge cases, GPT-5.5 earns its place.

The honest recommendation: Opus 4.7 as your default. GPT-5.5 for pipelines where you’ve validated that quality holds and cost matters at scale. That’s not a hedge. That’s how we’re actually running things.

And if you’re still on Opus 4.6: yes, upgrade. But run your prompts through Opus 4.7 in a test environment first and measure the tokenizer delta before you move production traffic. The improvement is real. So is the cost change.

---

Running AI-powered engineering workflows and spending more time managing model costs than building product?

At SSNTPL, we’ve run this exact evaluation across dozens of client codebases — and we build the multi-model routing strategies that let teams get Opus 4.7 quality where it matters and GPT-5.5 efficiency everywhere else.

Talk to our engineering team → — bring your stack, your volume, and your current model spend. We’ll tell you where you’re leaving money on the table.

---

FAQ

---

Testing conducted May 2026 on SSNTPL’s internal production codebase. Benchmark data sourced from official Anthropic (April 16, 2026) and OpenAI (April 23, 2026) announcements. Pricing verified from official API documentation as of May 14, 2026. Token cost estimates are directional — run your own workloads before budgeting.

---