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

> Moving an existing Claude Opus 4.6 integration to 4.7 changes thinking controls, sampling parameters, and token counts. Use these request examples and a controlled workload comparison to decide whether the upgrade pays off.

- URL: https://blog.laozhang.ai/en/posts/claude-opus-4-7-vs-claude-opus-4-6
- Published: 2026-04-17
- Updated: 2026-09-07
- Author: LaoZhang AI Team (https://blog.laozhang.ai/en/about)
- Topic: Model Comparisons
- Tags: Claude Opus 4.7, Claude Opus 4.6, Anthropic, API Migration, Token Usage

---
**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](https://platform.claude.com/docs/en/about-claude/model-deprecations).

## 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](https://platform.claude.com/docs/en/models/opus-4-6/overview) and [Opus 4.7 specifications](https://platform.claude.com/docs/en/models/opus-4-7/overview) describe the direct Claude API, not a Claude subscription allowance or another provider's bill.

In its [April 16 launch announcement](https://www.anthropic.com/news/claude-opus-4-7), 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:

| Existing behavior or setting | What to do on Opus 4.7 |
| --- | --- |
| Manual thinking with `type: "enabled"` and `budget_tokens` | Use adaptive thinking; control effort separately. |
| Custom `temperature`, `top_p`, or `top_k` | Remove the fields, including values injected by wrappers. |
| Application expects visible thinking summaries | Set `thinking.display: "summarized"` explicitly. |
| Effort left unspecified | It still defaults to `high`; `xhigh` requires an explicit choice. |
| Old `speed: "fast"` setting | Remove it for standard-speed requests; 4.7 does not provide Fast mode. |
| Token counts measured on 4.6 | Count the same structured input with the 4.7 model ID. |

## Migrate the request before comparing output quality

![Request migration examples and a checklist for thinking settings, sampling parameters, and token counting.](https://blog.laozhang.ai/posts/en/claude-opus-4-7-vs-claude-opus-4-6/img/request-migration-and-token-counting.webp)

### 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](https://platform.claude.com/docs/en/claude_api_primer#thinking).

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

```json
{
  "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`:

```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:

```bash
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](https://platform.claude.com/docs/en/about-claude/model-deprecations#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](https://blog.laozhang.ai/en/posts/claude-opus-4-7-temperature-parameter) 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](https://platform.claude.com/docs/en/build-with-claude/effort#recommended-effort-levels-for-claude-opus-47).

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](https://platform.claude.com/docs/en/build-with-claude/thinking#controlling-thinking-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](https://platform.claude.com/docs/en/build-with-claude/fast-mode#supported-models).

## Count the same input under both tokenizers

Anthropic's [April launch guidance](https://www.anthropic.com/news/claude-opus-4-7) 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](https://platform.claude.com/docs/en/build-with-claude/token-counting) 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.

```python
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:

| Cost component | Opus 4.6 | Opus 4.7 |
| --- | --- | --- |
| Input at $5 per million tokens | $0.50 | $0.65 |
| Output at $25 per million tokens | $0.25 | $0.25 |
| Total | $0.75 | $0.90 |

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.

![Illustrative input and output cost comparison alongside migration steps and workload evaluation criteria.](https://blog.laozhang.ai/posts/en/claude-opus-4-7-vs-claude-opus-4-6/img/migration-cost-and-workload-comparison.webp)

For production estimates, use the applicable [input, output, cache, and Batch rates](https://platform.claude.com/docs/en/about-claude/pricing). 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.

| Workload | Hold constant | What would justify the migration? |
| --- | --- | --- |
| Code repair | Repository revision, instructions, tools, test command, and stopping rules | More correct fixes with passing tests and acceptable review effort. |
| Long document analysis | Document bytes, questions, expected supporting passages, and output requirements | Fewer missed constraints or unsupported conclusions. |
| Structured extraction | Input records, schema, validation rules, and retry policy | Higher valid-output and field-accuracy rates without excessive retries. |
| Visual debugging | Original screenshot, question, and any preprocessing | Better identification of relevant detail at an acceptable image-token cost. |
| Multi-step agent work | Starting environment, tool permissions, time limit, and completion criteria | More completed tasks within your total cost and latency limits. |

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](https://platform.claude.com/docs/en/release-notes/overview#april-16-2026).

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](https://platform.claude.com/docs/en/claude_api_primer#prefilling-claudes-response) and the [guide to replacing assistant prefill](https://blog.laozhang.ai/en/posts/claude-opus-prefill-error-fix) 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](https://platform.claude.com/docs/en/build-with-claude/task-budgets).

## Sources

External pages this guide links to, in the order they appear. Last updated 2026-09-07.

- [current lifecycle table](https://platform.claude.com/docs/en/about-claude/model-deprecations) (platform.claude.com)
- [Opus 4.6 specifications](https://platform.claude.com/docs/en/models/opus-4-6/overview) (platform.claude.com)
- [Opus 4.7 specifications](https://platform.claude.com/docs/en/models/opus-4-7/overview) (platform.claude.com)
- [April 16 launch announcement](https://www.anthropic.com/news/claude-opus-4-7) (anthropic.com)
- [API thinking reference](https://platform.claude.com/docs/en/claude_api_primer) (platform.claude.com)
- [model-specific effort guidance](https://platform.claude.com/docs/en/build-with-claude/effort) (platform.claude.com)
- [thinking configuration and display](https://platform.claude.com/docs/en/build-with-claude/thinking) (platform.claude.com)
- [supported models and fallback behavior](https://platform.claude.com/docs/en/build-with-claude/fast-mode) (platform.claude.com)
- [token-counting endpoint](https://platform.claude.com/docs/en/build-with-claude/token-counting) (platform.claude.com)
- [input, output, cache, and Batch rates](https://platform.claude.com/docs/en/about-claude/pricing) (platform.claude.com)
- [April 16 release notes](https://platform.claude.com/docs/en/release-notes/overview) (platform.claude.com)
- [task-budget documentation](https://platform.claude.com/docs/en/build-with-claude/task-budgets) (platform.claude.com)