Claude 4

Claude 4 Model Family Overview

Claude 4 targeted coding, reasoning, tool use, and long-running agent tasks.

The original family had two main models:

Prices are per million tokens. The original Sonnet 4 and Opus 4 models are deprecated and scheduled to retire on June 15, 2026.

Claude Sonnet 4 was the practical default for daily engineering work because it balanced speed, capability, and cost. Claude Opus 4 fit harder tasks where the model needed deeper reasoning, more careful tradeoff analysis, or stronger synthesis across a large codebase.

Teams maintaining older Claude 4 integrations should treat the retirement date as a migration deadline. Start by finding every configured Sonnet 4 or Opus 4 model ID, then map each usage to the workflow it supports: code review, test generation, bug fixing, research, architecture planning, or automation. After that, test the same workflows against the recommended newer Claude models before changing production defaults.

What Changed from Claude 3 to Claude 4

Claude 4 improved agentic execution compared with Claude 3.

The main changes were:

• Better long-horizon coding.
• Stronger tool use.
• Extended thinking.
• Improved memory workflows.
• More reliable multi-file changes.

The shift was from answering coding questions to completing longer coding tasks. Claude 3 was useful for explanations, snippets, and isolated reasoning. Claude 4 moved closer to agent workflows where the model had to inspect files, plan edits, use tools, preserve context, and complete a task across several steps.

That mattered for repository maintenance. A coding agent must understand the request, identify relevant files, avoid unrelated edits, modify code, run or recommend tests, and explain the result. Claude 4 made those workflows more realistic because it handled state, tools, and multi-file reasoning more reliably than earlier Claude 3 models.

For buyers and engineering leads, the practical change was workflow design. Claude 4 performed best when paired with clear task boundaries, scoped repository context, explicit acceptance criteria, and verification. Without those controls, a stronger model could still waste tokens, over-edit files, or miss project-specific constraints.

Opus 4 vs Sonnet 4 Comparison

Sonnet 4 was faster and cheaper. Opus 4 was designed for harder reasoning, deeper research, and more complex planning.

The simplest selection rule was cost versus reasoning depth. Use Sonnet 4 when the task was well-scoped, repetitive, or easy to verify. Use Opus 4 when the task required slower analysis, larger tradeoffs, or synthesis across many files and requirements.

For production systems, many teams used a tiered pattern: route planning, architecture, or difficult investigations to Opus 4, then route implementation, test updates, and routine follow-up work to Sonnet 4. That pattern reduced cost while keeping the highest-capability model available for the hardest decisions.

For current work, compare Sonnet 4.6 and Opus 4.8 instead. The same decision logic still applies: match the model to the task, then measure output quality, latency, retries, human review time, and total cost.

The distinction becomes clearer when comparing Sonnet 4 against Claude Opus 4 for slower planning, architecture tradeoffs, and high-stakes refactors.

For source-level validation, Claude is worth checking after you understand the Claude 4 workflow described here.

Context Window & Token Limits

The original Claude 4 models used 200K-token context windows.

A 200K-token context window helped with broad repository analysis, long documents, specifications, logs, and multi-file debugging. It allowed the model to see more material in one request, which reduced the need to constantly re-send missing background.

Large context did not remove the need for scope control. A model can still miss the important file if the prompt includes too much unrelated code. Large prompts also increase cost, latency, and distraction. The best workflow is to pass the smallest complete context that lets the model solve the task.

For development work, that usually means:

1. Start with the user request and acceptance criteria.
2. Add the relevant files, tests, and error output.
3. Include project conventions only when they affect the change.
4. Keep unrelated files out of the prompt.
5. Verify the result with tests, review, or static checks.

Verdent follows this principle by using planning and worker boundaries around the model. Plan Mode narrows the task before execution. Parallel workers can investigate or implement separate parts of the work without turning the entire repository into one unstructured chat prompt.

Current Claude models can offer larger or different context limits. Always check the active model table before setting production assumptions.

For latency-sensitive tasks where a smaller context is enough, Claude Haiku may be a better fit than sending large prompts to a higher-capacity model.

When details such as limits or setup steps matter, Youtube can help confirm the latest implementation surface.

Claude 4 Benchmarks vs GPT-5

Claude 4 and GPT-5 belong to different release periods, so direct benchmark tables can be misleading.

Public scores often mix different harnesses, prompts, tool permissions, retry policies, and token budgets. A model that performs well in one benchmark may behave differently inside a real repository with project conventions, failing tests, dependency constraints, and human review requirements.

Compare models with the same task instead:

1. Use one repository.
2. Give each model the same issue or feature request.
3. Set the same time limit.
4. Provide the same tools and file access.
5. Require the same tests or review checks.
6. Count retries, failed patches, and human fixes.
7. Measure total cost, not only token price.

The most useful benchmark for a development team is an end-to-end workflow score. Did the model understand the task? Did it edit the right files? Did it avoid unrelated changes? Did tests pass? Did the reviewer trust the diff?

> Production evidence > > 76.1% on SWE-bench Verified is Verdent's credibility anchor. Plan-First execution and review turn model capability into a result a team can inspect. > > Enterprise-Grade Safety controls the workspace. Code Verification controls the result.

For buyers, the takeaway is simple: benchmark the system, not only the base model. Claude 4, GPT-5, and newer models become more useful when they run inside a workflow that controls planning, execution, verification, and review.

Teams comparing Claude 4 variants should include Claude Opus 4.1 in the same workflow test before choosing a model for complex coding work.

Before you budget a real project around Claude 4, compare the claims here with Anthropic documentation.

Getting Claude 4 in Verdent

Verdent's current built-in model list uses newer models rather than the deprecated original Claude 4 models.

The list includes Claude Fable 5 and Opus 4.8. It also includes current models from OpenAI, Google, GLM, and Kimi.

Verdent adds an execution layer around those models. Instead of treating Claude as a single chat session, Verdent uses planning, parallel workers, safety controls, and verification to manage software work.

That matters during a Claude 4 migration. If a workflow is already defined around tasks, plans, worker boundaries, and tests, changing the model ID is less disruptive. The engineering process stays the same while the underlying model changes.

A practical migration in Verdent should follow this sequence:

1. Identify workflows that still depend on Claude Sonnet 4 or Claude Opus 4.
2. Select the newer Claude model that matches each workflow.
3. Run the same task through the old and new model where possible.
4. Compare diff quality, test results, review effort, latency, and cost.
5. Move production defaults after the newer model passes the workflow checks.

Verdent is designed for that kind of controlled model upgrade. The model can change while the planning, dispatch, safety, and verification process remains consistent.