Claude Code and Opus 4.7: Complete setup and usage guide

The Claude Opus 4.7 has become the star model from the Anthropic ecosystem for programming, agents, and intensive professional work. It arrives just a couple of months after Opus 4.6, but it's not a simple patch: It introduces a new tokenizer, an xhigh effort level, changes to how it interprets instructions, and a huge improvement to Claude Code's vision and workflows.If you were already comfortable with Opus 4.6With 4.7 you'll notice that it "thinks" more and better... and also that it can spend more tokens if you don't tame it well.

The goal of this guide is for you to have A complete configuration manual for Claude Code + Opus 4.7How to choose the right effort, how to control costs with task budgets, how to migrate from 4.6 without breaking prompts, how to set up a consistent system with CLAUDE.md, settings.json, skills, and hooks, and when it's best to continue using Sonnet or Haiku. All explained in Spanish, for teams that bill in dollars but pay for their infrastructure with tight budgets.

What does Claude Opus 4.7 offer compared to 4.6

The first thing to be clear about is that Opus 4.7 does not change price or context windowYou still get up to 1M tokens per interaction, at the same cost as 4.6 ($5/MTok in, $25/MTok out)without a surcharge for long context. The difference lies in how it uses those tokens and the control it gives you as a developer.

In programming benchmarks, Anthropic reports that Opus 4.7 solves many more real-world tasks than version 4.6, especially in SWE-Bench tests and internal suites of 93 coding tasks. In practice, this translates to fewer retries when you ask it to perform large refactors, debug unusual bugs, or make architectural decisions. It's also noticeable in its reasoning: it plans better, makes fewer silly mistakes, and is more reliable in long agent flows.

Another key change is the Enhanced vision with resolution up to ~3,75 MP and 2.576 px on the long sideThis triples the accuracy with which it understands screenshots, technical diagrams, database schemas, or scanned PDFs. If you were already using the Vision API with 4.6, you can now input much larger screenshots without losing detail (keep in mind that higher resolution also means more input tokens).

Furthermore, Opus 4.7 adopts a new tokenizer that counts more tokens for the same textDepending on the content, you can see between 1,0x and 1,35x the number of tokens compared to 4.6x. Code, JSON, and non-Latin alphabets are what most significantly increase the cost. This matters because, even if the price per million tokens remains the same, if the text is broken down into more units, you'll pay more for the same workload if you don't optimize prompts and effort.

Finally, the interpretation of instructions becomes much more literalWhere version 4.6 filled in gaps with some flexibility (“short summary” would give you something reasonable of 150 words), version 4.7 tends to follow the rules to the letter (it will give you a minimum paragraph unless you specify a length). This has a direct impact on the prompts you had already fine-tuned for version 4.6.

Effort levels in Opus 4.7: low, high, xhigh and max

Version 4.7 brings a significant change in mindset: reasoning becomes adaptiveYou no longer adjust a fixed budget of "thinking tokens" as before, but the model decides how much to think based on the complexity of the task and the level of effort you configure.

The levels available in Opus 4.7 are low, medium, high, xhigh and maxThe key is the new xhigh: it sits right between high and max, designed for complex programming and long-term agents, without the exorbitant cost of max. In Claude Code, Opus 4.7 comes with xhigh as the default effort level, because Anthropic found that high fell somewhat short for agent development workflows.

To summarize the range, the typical behavior would be this: with low/medium You prioritize latency and cost (support, extraction, small transformations); with high You cover most coding, document analysis, and regular review tasks; with xhigh You're aiming for multi-project refactoring, architectural design, and fine-tuning debugging; and max You reserve it for demonstrations, formal tests, or security audits where you want it to exhaust every line of reasoning, even if it takes longer and costs more.

In the Claude Code CLI you can playing with the effort in the heat of the moment using the command /effortYou choose the level in an interactive selector or you skip directly /effort xhighFor example, at the API level, this is controlled via the adaptive thinking configuration field. If you need to force a lighter approach on certain routes, you can lower the setting to high for specific scripts or sub-agents.

One important detail: The maximum level does not persist between sessionsIt's useful for specific tasks within the current session; when you reopen Claude Code, you'll continue with the effort you had persistently configured (typically xhigh). This prevents you from accidentally burning through tokens for hours, leaving you at max.

Task budgets, Auto Mode and /ultrareview in Claude Code

The arrival of Opus 4.7 coincides with a series of powerful improvements in Claude Code. Three features stand out if you work daily with the CLI: task budgets, more accessible Auto Mode, and the /ultrareview command for in-depth reviews.

The task budgets This allows you to set a token limit for a Claude Code session, which is critical when the model acts as an autonomous agent and chains together reads, edits, tests, and tool calls. You can configure it with something like /config task_budget 50000If the officer approaches the limit, he stops and asks if you want to continue or stop. It's a safety barrier to prevent something that seemed like it would only take a little while from eating up half the month's budget.

El Auto Mode —which in practice is the sensible replacement for the old --dangerously-skip-permissions— has been expanded to Max users in combination with Opus 4.7. It works with a separate classifier (Sonnet 4.6) that reviews each action (bash, MCP, edits) and checks if it matches your intent and is safe. For tasks where you already trust the model and want it to "do its thing" without constant confirmations, this mode is invaluable.

Another star piece is /ultrareviewThis is a slash command that triggers an in-depth code review using a structured protocol. It runs the model with very high effort, examines architecture, logic, security, performance, and maintainability, and returns an organized report with flagged files and recommendations. The Pro and Max plans include several free runs per cycle; after that, billing is based on tokens, just like any other Opus 4.7 session.

To further reduce permission disruptions, Anthropic released a skill-type “fewer-permission-prompts” It scans your session history, detects repeated bash/MCP commands that you always approve, and suggests adding them to allowed lists in settings.json. It's the civilized way to go from asking "Can I do this?" every other minute to a smoother workflow without overcomplicating things.

The new tokenizer: real impact on costs and how to measure it

One of the less noticeable but most dangerous changes for your wallet is the updated tokenizer from Opus 4.7The same prompt you used in 4.6 now generates between 0% and 35% more tokens, depending on the content type. In English prose the change is almost negligible, but it's noticeable in source code, JSON, structured data, and some non-Latin languages.

In terms of billing, this means that If you previously spent $1.000/month with 4.6 using only OpusWith 4.7, you could see between $1.000 and $1.350 simply for re-tokenization, without having changed anything in your product. And since the model also thinks more (xhigh effort, adaptive reasoning), the sum can grow even more in heavy workflows.

To avoid going in blind, Anthropic exposes a token counting endpoint that lets you run your real prompts through the 4.7 tokenizerFrom the Python SDK you can call client.messages.count_tokens with model="claude-opus-4-7" and see the exact number of entry tokens for your production prompt. Compare it to the same count at 4.6 and you have your actual multiplier, not the theoretical one.

Once the impact has been detected, mitigation involves three fronts: Reduce effort where it's not needed, limit outputs, and direct simple tasks to cheaper models.You can explicitly instruct the model to be concise (“respond in a maximum of 150 words, without extra explanations”), reduce max_tokens in routine calls, and generate long summaries for discounted batch tasks instead of doing so in real time.

If you also combine prompt caching and Batch API (which charges half price for tokens with a 24-hour response time), you can offset a good portion of the tokenizer's extra cost. The key is to avoid using Opus 4.7 at xhigh in interactive mode for everything, because that's where the biggest cost increases.

Migrating from Opus 4.6 to 4.7 without breaking anything

Upgrading from 4.6 to 4.7 isn't just changing a model ID; there are five steps to follow If you already have things in production: update identifier, revalidate prompts, measure tokens, adjust effort, and test on real traffic before going to 100%.

The first part is quite mechanical: search the code for all references to claude-opus-4-6 and replace them with claude-opus-4-7A recursive grep for .py, .ts, .json, .yaml will return everything. If you use aliases like opus In Claude Code, the switch will be even simpler because the alias already points to the new version in many plans, but for backend infrastructure it is recommended to set the explicit ID.

Next, it's time to review key prompts. Since version 4.7 follows the instructions more literally, Vague prompts can degrade resultsA classic example: if you had "Summarize this document. Keep it short.", 4.6 would likely give you something of 150 words with reasonable bullet points; 4.7 might return 40-50 words and that's it. The solution is to be explicit ("Write a 100-150 word summary with the 3 key points").

The third step is benchmark token usage with count_tokens For some representative prompts, especially those with higher volume (support flows, RAG, evaluation pipelines), you calculate the percentage difference and adjust cost estimates. It's also advisable to review the maximum token output and reduce it where you have excessively generous ceilings.

Fourth, decide if you want explicitly set the effort in your calls. Claude Code already comes with xhigh in Opus 4.7, but if you're coming from 4.6 with high effort, you might want to maintain that level in some flows by declaring high effort in the project configuration or in the API call.

Finally, Don't migrate 100% of the traffic at once.Redirect 5-10% to 4.7, compare quality, cost, latency, and errors, and only complete the transition when you're comfortable. Tokenizer changes and literal interpretation are positive in the medium term, but in the short term they can expose fragile assumptions in your prompts.

Configure Claude Code for consistency: CLAUDE.md, settings and Skills

Most complaints about “Claude is not consistent” are not due to the model, but to the fact that There is no persistent configuration per project.If every time you open a new session you have to remember that you're using strict TypeScript, arrow functions, Vitest instead of Jest, and certain store conventions, the problem isn't AI: it's that there's no place to declare it once.

That place is CLAUDE.md in the root of the repoClaude Code automatically reads this file at the start of every conversation in that project. This is where you should specify the code stack, coding conventions, preferred patterns, known bugs, and environment constraints. No generic programming philosophy; the model doesn't need that.

The tool itself includes a command /init It analyzes the code and generates an initial CLAUDE.md file. It's not perfect (sometimes it includes obvious things or omits details), but it serves as a starting point. From there, the key is to maintain it. light and focused on the project contextDo not paste long code patterns; those go in Skills.

Then there is settings.jsonThis is where you define permanent permissions, environment variables visible to Claude, and hooks that always run before or after certain actions. The hierarchy is cascading: global user settings (~/.claude/settings.json) and project-specific settings (.claude/settings.json). When they conflict, the more specific (project-specific) settings prevail, which is great for applying different policies across repositories.

A sensible pattern is Leave broad options in the user configuration (for example, allowing reading code files or running the linter) and refine in the project what you don't want it to do without asking. (deployment scripts, migrations, access to secrets). If settings.json doesn't exist in the repo, you'll be stuck with global behavior, which is often too lax or, conversely, forces you to always accept the same thing.

Cost strategies: when to use Opus 4.7, Sonnet 4.6 and Haiku 4.5

Opus 4.7 is a beast, but it doesn't have to be your hammer for each nailAnthropic maintains a family of models to play with the cost: Haiku 4.5, Sonnet 4.6 and Opus 4.7 cover almost the entire spectrum of needs.

Haiku 4.5 It's the lightweight model: fast and very inexpensive. Ideal for classification, simple extraction, metadata generation, short summaries, and especially for sub-agents that perform file scanning and searches. If you have a system that launches many sub-agents to scan repositories, logs, or documentation, adding Haiku to that will drastically reduce your costs.

Sonnet 4.6 It's a well-rounded workhorse: mid-range price, sufficient intelligence for most daily development tasks (writing code, fixing bugs, generating tests, making reasonable refactors). It also has a 1M token context and adaptive thinking, so you can handle large codebases without always having to rely on Opus.

Opus 4.7 You should reserve it for situations where quality is non-negotiable: architectural decisions, delicate debugging, security analysis, coordinating agent teams, or projects where a failure costs far more than a few dollars in tokens. In many companies, the winning strategy is to route by task type: simple/moderate tasks to Sonnet or Haiku, complex tasks to Opus.

If you set up a routing layer that monitors the request type and complexity, you can achieve 40-60% cost reductions without sacrificing quality where it really matters. In fact, Anthropic documents teams that, simply by separating simple tasks into Sonnet and Haiku, have avoided exorbitant bills.

In the end, if you properly set up CLAUDE.md, settings, Skills, model routing, permissions, and hooks, Opus 4.7 ceases to be "a bigger model" and becomes a rather serious development co-pilotIt allows you to delegate heavy lifting without constantly checking the token meter, provided you properly balance effort, task budgets, the sandbox, and the choice of model for each task. If you're coming from version 4.6, the leap is noticeable in agent reasoning, vision, and reliability; if you're starting from scratch, it makes sense to start directly with version 4.7, but plan your configuration and costs from day one to avoid surprises at the end of the month.