GPT-5 vs Claude Opus 4.7: seven workload decision factors

This piece compares seven workload categories: a code refactor, a marketing landing page, reasoning under uncertainty, an instruction-bound task, a paper summary, a difficult customer email, and a Python debug. The evidence comes from cited public benchmarks such as SWE-bench Verified and LMArena, plus each lab's published positioning. Public benchmarks do not directly score all seven scenarios, so the category leans below are editorial hypotheses to validate, not measured outcomes.

The pricing reference, since both come up in every workload decision: Claude Opus 4.7 lists at $5 per million input tokens and $25 output, per Anthropic's pricing page. GPT-5 lists at $1.25 and $10 per OpenAI's API pricing. For the full cost picture across workloads, see price per use case. For each model on its own terms, see the Opus review and the GPT-5 review.

One framing note before the seven categories: these are decision factors, not a record of seven private runs. Where a public benchmark maps imperfectly to a workload, the article says so. A defensible procurement decision still requires the same prompts, model versions, settings, rubric, and blind review on your own held-out cases.

Category one: refactor a class hierarchy

The workload: take a production class with five derived types and crosscutting concerns, name the architectural smell, propose a refactor, and produce the new files. This is the kind of work SWE-bench Verified is designed to score. Anthropic reports 87.6% for Opus 4.7, while OpenAI reports about 74.9% for GPT-5. Those are provider-published figures and may use different harness details, so they are evidence for candidate selection rather than a controlled benchr comparison.

SWE-bench is useful evidence for repository-level issue resolution, but it does not prove how either model will handle this particular architecture prompt. Use the scenario as a local test: pin the model versions and settings, hide model identity from reviewers, and score correctness, unnecessary scope, test coverage, and maintainability. The public ranking makes Claude a reasonable first candidate, not a guaranteed winner.

Editorial lean: start with Claude, then verify against the same repository cases.

Category two: write a marketing landing page

The workload: produce a single-page marketing site for a young technical audience. Vanilla HTML and CSS, mobile-first, bold typographic hierarchy. OpenAI's positioning for GPT-5 emphasizes visual design and structured output as model strengths. That positioning is a reason to include GPT-5 in the trial; it is not evidence that the same prompt will always produce a more shippable layout.

Score this category on requirements compliance, responsive behavior, accessibility, visual hierarchy, originality, and the amount of human revision required. Run multiple prompts and randomize the output order for design review. A single attractive sample is not enough to establish a model-level advantage.

Editorial lean: start with GPT-5 for the visual prototype, then blind-review both outputs.

Category three: reasoning under uncertainty

The workload: a specific regulatory or policy question where the right answer needs familiarity with both the underlying statute and the trajectory of its enforcement. A good answer names the relevant article, separates the statute from how it actually gets enforced, and is honest about the limits of what a non-specialist can assert.

Anthropic positions Opus around calibrated reasoning and appropriate uncertainty. Treat that provider claim as a hypothesis to test, not as independent proof. For a high-stakes evaluation, prepare questions with expert-verified references and score citation validity, separation of law from interpretation, calibration, and whether the model recommends human review at the right point.

The dangerous failure mode for either model is a nearly correct answer with one believable but wrong citation. Confidence and verbal caution are not substitutes for source verification. Require an expert or retrieval-backed check no matter which model drafts the answer.

Editorial lean: Claude is the first candidate; verified citations and expert review decide.

Category four: a constrained instruction-following task

The workload: an everyday task with a quantitative constraint, such as a time budget or a recipe built from a fixed set of ingredients. The interesting question is which model respects the constraint without adding scope.

Public general-purpose benchmarks do not answer this narrow question reliably. Build a small constraint suite with exact pass/fail checks, including time, length, allowed inputs, forbidden additions, and output schema. The useful result is your compliance rate by model version, not a general reputation for being concise or expansive.

No evidence-backed winner here: use deterministic checks on your own constraints.

Category five: summarize a long technical paper

The workload: take a 60-page technical paper and produce a 1500-word summary for an engineer who knows the basics but has not read it. There are two reasonable ways to structure this: by section (walk the paper in order) or by claim (identify the contributions and pull the supporting experiments into each one).

The right structure depends on the audience: an engineer may prefer claims and implications, while an academic reviewer may need section-by-section coverage. Specify that structure in the prompt instead of relying on an assumed model default, then score factual coverage against a reference outline prepared from the paper.

The secondary risk for both models is over-compressing the experimental section when it carries the paper's argument. Check every claimed contribution, limitation, and quantitative result against the source; prose quality comes after factual coverage.

Editorial lean: Claude for a claim-first draft, but source-grounded coverage decides.

Category six: a difficult customer email

The workload: a real-feeling customer-service scenario. A paying customer is upset. A bug took longer than it should have to fix. A downstream side effect hit something the customer cared about. Draft a reply that takes responsibility, explains the situation without excuses, offers a concrete remedy, and reads like a human wrote it.

Model reputations for warmth or restraint are too vague to settle this workload. Create anonymized examples that reflect your real support policy, and have reviewers score responsibility, clarity, prohibited promises, remedy accuracy, and tone. Preserve a human approval step before any message is sent.

Track first-draft acceptance and revision time during that evaluation. Those measurements can support a local decision; an unpublished anecdote about which model gets there on the first or second pass cannot.

Editorial lean: try Claude first, but let blind review and policy compliance decide.

Category seven: debug a broken Python script

A useful local workload is a Python script with deliberately introduced bugs, including one that only appears under specific async call patterns. Keep the answer key hidden and ask each pinned model to diagnose, patch, and add regression tests without hints.

SWE-bench Verified is relevant public evidence, but it does not establish the result of that custom script. Score defects found, incorrect edits, regression-test quality, and whether the model surfaces ambiguity instead of silently guessing. Repeat across several scripts before generalizing.

First-pass behavior matters because a production debugging workflow does not reveal what the reviewer has missed. Record it explicitly in the rubric and retain the outputs so another reviewer can reproduce the conclusion.

Editorial lean: Claude based on the cited public coding evidence; your hidden-bug suite decides.

How to use the seven factors

Use Claude as an initial candidate where the cited public coding evidence is relevant, and include GPT-5 early where visual or structured-output work matches OpenAI's published positioning. For constraint following, summaries, customer tone, and domain reasoning, neither the public record nor provider marketing establishes a winner for your use case. The seven sections define a reproducible evaluation protocol; they are not a cross-task ranking.

A model comparison is useful when it tells you what to test next, not when it turns editorial judgment into an unexplained score.

Which one for which work

For code with non-trivial structure, include Claude early because the cited provider-published coding benchmark makes it a reasonable candidate. That result does not guarantee performance on your repository: pin versions, use held-out issues, and blind-score correctness, scope, tests, and maintainability.

For landing pages, slide decks, and dashboard mockups, include GPT-5 because OpenAI's published positioning emphasizes visual and structured output. Compare anonymized outputs against the same accessibility, responsiveness, hierarchy, and revision-effort rubric before choosing.

Do not assign legal, medical, or financial decisions to either model on reputation alone. Use expert-verified sources, score citation validity and calibration, and keep qualified human review in the approval path.

For non-English writing where dialect or audience-specific voice matters, build a language-specific blind review set. Neither public leaderboards nor broad model reputations establish a winner for your audience; the Arabic content piece provides a local test design.

If your workload is high-volume and latency-sensitive, add lower-cost candidates such as Claude Sonnet 4.6 and GPT-5 Mini to the same test. Measure quality, p50/p95 latency, failure rate, and total reviewed cost; the small-models piece explains that decision.

There is no defensible subscription rule for every team. Start with a bounded API trial or the plans you already have, preserve model and prompt versions, and pay for a second provider only when the held-out evaluation shows distinct value that exceeds its total cost.