Claude Opus 4.7 vs 4.6: API Migration, Token Costs, and When to Upgrade

An Opus 4.6-to-4.7 migration needs more than a model ID change. Replace manual thinking settings, remove obsolete sampling controls, and recount your actual inputs before deciding whether better task completion justifies the cost. Keep the working 4.6 configuration available until the replacement passes your application's tests.

As of September 7, 2026, both models remain available, but they belong to the older Opus lineup. Anthropic's lifecycle table lists both as active, with retirement no sooner than February 5, 2027 for 4.6 and April 16, 2027 for 4.7. Those dates apply to Anthropic-operated platforms; partner schedules can differ. The migration steps below apply to existing integrations using these two model IDs. See the current lifecycle table.

What changes for an existing Opus 4.6 application?

The published standard API specifications match on several important dimensions: both offer a 1-million-token context window, up to 128,000 output tokens, and base pricing of $5 per million input tokens and $25 per million output tokens. Matching token prices do not guarantee matching request costs. The current Opus 4.6 specifications and Opus 4.7 specifications describe the direct Claude API, not a Claude subscription allowance or another provider's bill.

In its April 16 launch announcement, Anthropic reported improvements on difficult coding tasks and high-resolution visual work, along with more literal instruction following. These are reasons to test 4.7 on relevant work. They cannot establish that it will improve your particular codebase, extraction pipeline, or agent loop.

The practical migration differences are more specific:

Migrate the request before comparing output quality

Replace the manual thinking budget

Opus 4.6 accepts adaptive thinking and the older manual configuration. Opus 4.7 rejects manual thinking with a 400 error. Use thinking.type: "adaptive" and output_config.effort instead, as described in Anthropic's API thinking reference.

For example, an existing 4.6 request body might look like this:

{
  "model": "claude-opus-4-6",
  "max_tokens": 8192,
  "thinking": {
    "type": "enabled",
    "budget_tokens": 4096
  },
  "system": "Review the supplied code. Identify the bug and propose a minimal fix with a regression test.",
  "messages": [
    {
      "role": "user",
      "content": "Python function:\ndef first_or_none(items):\n    return items[0]\n\nThe function must return None for an empty list."
    }
  ]
}

Save the corresponding 4.7 request body as opus47.json:

{
  "model": "claude-opus-4-7",
  "max_tokens": 8192,
  "thinking": {
    "type": "adaptive",
    "display": "summarized"
  },
  "output_config": {
    "effort": "high"
  },
  "system": "Review the supplied code. Identify the bug and propose a minimal fix with a regression test.",
  "messages": [
    {
      "role": "user",
      "content": "Python function:\ndef first_or_none(items):\n    return items[0]\n\nThe function must return None for an empty list."
    }
  ]
}

The inputs stay identical; the thinking controls change. The 8192 output limit is a starting value for this small example, not a recommended limit for repository-scale agents. It caps total generated tokens, including thinking. It does not preserve the former 4,096-token thinking budget.

To send the new request through the direct API, use an API key already configured in your environment:

curl --fail-with-body https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  --data-binary @opus47.json

This command creates a response and incurs normal API usage charges when run. The JSON examples describe the documented request format; they are not recorded model responses.

For a comparison that isolates the model change more closely, also run 4.6 with adaptive thinking and explicit high effort. Otherwise, you are comparing the existing manual configuration against a new adaptive configuration as well as changing models. Both comparisons can be useful, but they answer different questions.

Remove sampling controls from the final payload

On 4.7, the server returns a 400 error for non-default values of temperature, top_p, or top_k. Remove those keys instead of substituting another value. Separately, Anthropic's Python SDK v1.0 and later removes these arguments, so supplying them can raise TypeError before an HTTP request exists. That distinction is documented under API parameter deprecations.

If a request still fails after editing your application code, inspect the serialized JSON: a shared client, agent framework, or gateway may add a sampling field back. A Python argument error calls for a client-side fix; an API 400 calls for checking what was actually sent. The Opus 4.7 sampling-parameter troubleshooting guide covers locating those injected settings.

Choose effort and thinking display deliberately

Both models default to high effort. Opus 4.7 adds xhigh between high and max; 4.6 does not support xhigh. Anthropic recommends trying xhigh for 4.7 coding and agentic work, but that recommendation is distinct from the API default. For xhigh or max, its guidance suggests starting with room for 64,000 output tokens and tuning from there. Effort steers how much work the model does; it is not a hard token budget. See the model-specific effort guidance.

Thinking is off on both models when you omit its configuration. With thinking enabled, 4.6 defaults to visible summaries, whereas 4.7 defaults to omitted text. The explicit display: "summarized" in the example keeps summaries available to an application that displays them. An empty thinking field does not mean no thinking occurred, and hiding it does not remove its charges. Preserve returned thinking blocks and their signatures unchanged when replaying them in a conversation. These are summaries, not raw internal reasoning. See thinking configuration and display.

Clear old Fast mode settings

Neither 4.6 nor 4.7 currently provides Fast mode. Their failure behavior differs: a 4.6 request with speed: "fast" runs at standard speed and reports usage.speed: "standard"; a 4.7 request with the same setting returns an error. Remove that field and the old Fast mode beta opt-in when making a standard 4.7 request. A successful old 4.6 call is therefore not proof that its Fast configuration still works. See the supported models and fallback behavior.

Count the same input under both tokenizers

Anthropic's April launch guidance said identical inputs could map to roughly 1.0–1.35 times as many tokens on 4.7, depending on content. Its current token-counting guide describes approximately 30% more text tokens, again with content-dependent variation. Neither figure is a universal multiplier for your input or your whole bill. Use the token-counting endpoint for the intended model.

The following Python script uses only the standard library and the HTTP endpoint, so it does not depend on a particular Anthropic SDK version. Save it as compare_input_tokens.py alongside opus47.json. For a useful estimate, replace the small demonstration input with a representative request, including the actual system text, messages, tool definitions, and any image or document content blocks.

import json
import os
from pathlib import Path
from urllib.request import Request, urlopen

request_body = json.loads(Path("opus47.json").read_text(encoding="utf-8"))
# Keep structured inputs and supported counting options.
# Do not pass generation-only fields such as max_tokens or output_config.
count_fields = ("system", "messages", "tools", "tool_choice", "thinking")
shared_input = {
    key: request_body[key]
    for key in count_fields
    if key in request_body
}

counts = {}
for model in ("claude-opus-4-6", "claude-opus-4-7"):
    payload = {**shared_input, "model": model}
    request = Request(
        "https://api.anthropic.com/v1/messages/count_tokens",
        data=json.dumps(payload).encode("utf-8"),
        headers={
            "x-api-key": os.environ["ANTHROPIC_API_KEY"],
            "anthropic-version": "2023-06-01",
            "content-type": "application/json",
        },
        method="POST",
    )
    with urlopen(request, timeout=60) as response:
        counts[model] = json.load(response)["input_tokens"]

for model, count in counts.items():
    print(f"{model}: {count:,} estimated input tokens")

baseline = counts["claude-opus-4-6"]
if baseline:
    ratio = counts["claude-opus-4-7"] / baseline
    print(f"4.7 / 4.6 input-token ratio: {ratio:.3f}x")

Run it with python3 compare_input_tokens.py. It makes two counting requests, not two generation requests. Token counting is free, with separate rate limits. The returned input_tokens values are estimates and may include system-added tokens that are not billed. The script prints your actual responses rather than assuming a result.

For a tool-using workload, count the complete request at representative later turns too. A short first message misses accumulated tool results and conversation history. Keep the content identical for the tokenizer comparison; test each model's independently generated conversation separately when measuring whole-task cost.

Turn token counts into a budget estimate

For a hypothetical standard request with no caching or Batch discount, suppose 4.6 uses 100,000 input tokens and 4.7 uses 130,000, while both generate 10,000 output tokens. These are illustrative values, not measured results:

Here a 30% input increase produces a 20% total increase. If generated output changes, the total changes again. Token counting cannot predict thinking volume, tool loops, retries, or whether a better answer saves a second attempt.

For production estimates, use the applicable input, output, cache, and Batch rates. Keep cache reads and cache writes in their own billing categories rather than charging all input at the base rate and adding cache charges again. Compare the final usage and cost records with your estimates after a controlled run.

Test the work that would justify upgrading

Start with tasks your team can judge: a bug with a regression test, an extraction with a known schema, a screenshot with a specific question, or an agent task with a verifiable final state. Define success before running either model.

Measure success rate, end-to-end latency, retries, input and output usage, and cost per successfully completed task. Repeated runs help separate a consistent improvement from a single favorable response. First compare both at a shared effort level such as high; then test 4.7 at xhigh as a separate option. This keeps a model improvement distinguishable from a higher-compute setting.

More literal instruction following makes ambiguous requirements worth checking. For example, “fix the bug, keep the patch minimal” leaves open whether adding a regression test is required. State that requirement explicitly, then rerun both models with the revised instruction before attributing the difference to capability.

Vision needs an additional check. Opus 4.7 raised the supported image long edge from 1,568 to 2,576 pixels, with automatic processing and no beta header. High-resolution images can use roughly three times the earlier image-token amount. That may help with small labels or dense interfaces, but it is not a threefold quality guarantee. Compare original-resolution and downsampled inputs only if the smaller version still preserves the detail your task requires. Anthropic documents the change in its April 16 release notes.

Promote a workload when it meets your chosen quality, latency, and cost thresholds. Keep 4.6 for a workload that does not improve enough to justify the change, while tracking its support schedule. A successful coding trial does not establish that the same setting should replace a tuned extraction job.

Two related migration questions

Is assistant prefill a new breaking change in 4.7?

No. Assistant prefill is already unsupported on Opus 4.6 and later: the final input message must be a user message. A trailing partial assistant response is therefore a shared incompatibility, not a new 4.7 regression. See the official prefill restriction and the guide to replacing assistant prefill for output-format alternatives.

Can task budgets replace a hard spending limit?

No. Task budgets, introduced with 4.7 under the task-budgets-2026-03-13 beta, advise the model about effort across an agent loop. They do not enforce a hard billing ceiling. Keep application-level limits on calls, retries, and total spend; use max_tokens for each response's generated-token cap. The distinction is covered in the task-budget documentation.