Claude 4.7 Stopped Reading Between the Lines

What You'll Learn

• What Anthropic actually says changed between Opus 4.6 and Opus 4.7
• Why old prompts can fail when scope and formatting were left implicit
• How to retune prompts and agent harnesses without adding random verbosity
• Which migration tests reveal real regressions in your own workload

Claude 4.7 stopped reading between the lines is the headline developers use when an old prompt no longer produces the same helpful interpretation. Anthropic’s official explanation is more precise. The company says Opus 4.7 is substantially better at following instructions and can therefore behave unexpectedly when a prompt was written for an earlier model. Where an earlier model interpreted an instruction loosely or skipped part of it, Opus 4.7 may take the wording literally.

That difference can feel like a regression. A prompt that once filled in a missing assumption may now ask for clarification, apply a rule only to the item named, or preserve a format that the developer thought was obvious. The model has not necessarily lost the ability to understand the request. The contract has become more visible.

Anthropic advises users to retune prompts and harnesses. Its migration material also tells teams to check behavior after a model change and measure cost and latency on real workloads. That advice is more useful than a broad claim that Opus 4.7 became “literal mode” or that every developer must rewrite every prompt.

This article treats the change as a prompt-engineering and testing problem. It focuses on the failure patterns that appear when a team relies on unstated scope, hidden formatting rules, or assumptions that live only in a developer’s head. The fixes are small. They are also easier to verify than a vague request for the model to be more intuitive.

What Anthropic Actually Changed

Anthropic’s official announcement for Claude Opus 4.7 is dated April 16, 2026. It describes Opus 4.7 as a direct upgrade to Opus 4.6 and highlights instruction following as a meaningful behavior change. Anthropic says prompts written for earlier models can produce unexpected results because the new model takes instructions more literally.

That wording supports a narrow conclusion. The change concerns how the model interprets and executes instructions. It does not establish that Opus 4.7 is worse at every task, that the model cannot infer anything, or that Anthropic confirmed a public “literal mode” switch. The phrase is an informal label for a real migration issue.

Anthropic also says Opus 4.7 improves on difficult software engineering work and complex reasoning. The same announcement discusses multimodal understanding, agentic settings, safety evaluations, and token use. Anthropic’s Opus 4.7 system card provides the safety-evaluation context. These claims come from Anthropic’s product announcement and should be read as the company’s description of its model, not as an independent benchmark of every developer workflow.

The Anthropic migration guide adds a practical instruction. After changing the model, teams should check behavior rather than assume that a prompt that worked before will work in exactly the same way. That is the difference between a version upgrade and a copy-paste substitution.

For a narrower explanation of the same model behavior, see our .. This article adds the migration and testing angle rather than repeating a release summary.

Why “Stopped Reading Between the Lines” Is a Useful Shorthand

Developers often write prompts as if they were messages to a colleague who already knows the project. They say “clean this up,” “do the same for the rest,” or “return the result in the usual format.” Humans fill in the missing context from habit. A model version may not apply the same assumptions, especially when instruction following becomes more exact.

“Reading between the lines” is therefore a metaphor for implicit scope and unstated intent. It is not a technical description of a hidden switch inside Claude. The official evidence says Opus 4.7 follows instructions more literally. It does not say that the model stopped understanding language or lost all contextual reasoning.

The distinction matters because the wrong diagnosis produces the wrong fix. If a team calls every unexpected output a model regression, it may lower quality settings, change models, or add long paragraphs of defensive prose. If the actual problem is an ambiguous prompt, a short sentence that defines scope may fix it.

The same principle applies to agentic tools. A coding agent may need to know whether “update the examples” means one file, one directory, or every example in the repository. An automation harness may need to know whether a formatting instruction applies to each item or only to the final response. Literal following makes those boundaries visible.

The Prompt Failure Patterns Literal Following Exposes

The most common failures are not mysterious. They are ordinary ambiguities that an earlier model happened to resolve in a convenient way. The new behavior exposes them because the prompt is treated as a more exact contract.

One pattern is scope drift. A prompt names one record and assumes the model will apply the same operation to a list. Another is format drift. A developer wants JSON, but the prompt says only “give me the answer.” A third is hidden policy. The writer expects a friendly tone, a short answer, or a specific omission but never states the rule.

There is also the missing-example problem. A transformation may be obvious to the person who wrote it and unclear to a fresh model or a new engineer. One input and one desired output can remove more uncertainty than a page of abstract instructions.

Scope Ambiguity: One Item or Every Item

Scope is the first thing to repair. A phrase such as “apply this rule to the examples” can refer to the examples in the current paragraph, the current file, or the entire input. A human reader may infer the intended range from context. A literal instruction follower may choose the smallest defensible range.

Write the scope as a direct command. Say “apply this transformation to every item in the input list” or “change only the paragraph under the heading named X.” If the task concerns a repository, identify the directory, file pattern, or function boundary. If the task concerns a document, say whether headings, captions, tables, and footnotes are included.

Do not solve scope ambiguity by saying “be detailed.” That word does not tell the model what to include. A useful prompt names the set, the exclusions, and the stopping condition. It also says what to do when an item does not match.

For teams comparing agent surfaces, our Cursor, GitHub Copilot, and Claude Code comparison provides a useful reminder that tool permissions and workflow design matter as much as model labels.

Implicit Formatting Does Not Survive a Model Upgrade

Formatting instructions are often treated as decoration. In an automated workflow, they are part of the interface. If the next system expects valid JSON, a Markdown explanation before the object is not harmless. If a parser expects one line per item, an attractive table can break the handoff.

State the output format, required keys, value types, ordering rules, and what the model must do when it cannot comply. A prompt can say “Return only JSON matching this schema” and show a small example. It can also say “Do not add commentary outside the JSON object.” These instructions reduce the room for a helpful but incompatible answer.

For natural-language output, name the tone and length in operational terms. “Write a concise answer” is weaker than “write three paragraphs with no headings and no list.” The more important the format, the less useful it is to rely on a team’s shared memory.

Do not overreact by specifying every punctuation mark in every task. The goal is a stable contract, not a prompt that nobody can maintain. Start with the fields and constraints that the downstream system actually checks.

Missing Assumptions Become User Work

A prompt can fail because the model does not know which assumption to make. Should a missing date be inferred from the filename, left blank, or treated as an error? Should a conflicting instruction be resolved by recency, priority, or a human review step? If the prompt does not say, the model must choose a path or ask a question.

List the assumptions that change the result. State the time zone when dates matter. State the unit when numbers matter. State the source hierarchy when documents conflict. State whether the model may use outside knowledge. These are not signs that the model has become less capable. They are ordinary interface design.

An assumption register is especially useful in agentic workflows. A coding agent can record the repository state, the test command, the files in scope, and the definition of done. A document agent can record the source set, the audience, the required citations, and the unresolved questions.

When the assumption is uncertain, make uncertainty visible. A field such as `needs_review` is safer than a polished guess that enters a database. Literal behavior can help here because it exposes the point at which the prompt stopped specifying what should happen next.

Why Agentic Harnesses Need Explicit Boundaries

Agentic systems amplify prompt ambiguity because one instruction can trigger a chain of tool calls. If the model misreads the target directory, the error may spread across files. If it misunderstands the stopping condition, it may continue after the useful work is finished. If it interprets “clean up” as permission to change behavior, review becomes difficult.

Use explicit tool boundaries. Name allowed actions, protected paths, approval points, and rollback steps. Say whether the agent can create new files, modify dependencies, run network commands, or commit changes. Keep the first run read-only when the task is exploratory.

Then test the harness with negative cases. Give it a file outside the intended directory and confirm that it leaves it alone. Include an input with a missing field and confirm that it follows the stated exception path. Add a contradictory instruction and confirm that the priority rule works.

Our MCP server security checklist covers permission and connector risks that become more important when a model can act through tools. More literal instruction following does not remove the need for access controls. It makes the prompt and the control plane easier to examine separately.

Tokenizer, Effort, and Cost Changes

Anthropic’s Opus 4.7 announcement discusses two changes that can affect usage. The updated tokenizer means the same input can map to roughly 1.0 to 1.35 times as many tokens depending on content type. Anthropic also says Opus 4.7 thinks more at higher effort levels, especially on later turns in agentic settings, which can produce more output tokens.

These figures do not predict the cost of every application. Token counts depend on the content, the prompt wrapper, the number of turns, tool results, and the effort setting. Anthropic recommends measuring the difference on real traffic. A short prompt with long tool output can cost more than a longer prompt with no tools.

Track input tokens, output tokens, latency, retry rate, tool calls, and task success together. If the model becomes more literal but fewer retries are needed, raw token growth may not equal higher total cost. If the model asks for clarification more often, that interaction may improve correctness while adding a turn.

For a wider comparison of model selection, read our GPT, Claude, and Gemini model guide. The same measurement discipline applies when comparing providers or switching within one provider.

How to Migrate an Old Prompt Safely

Start by collecting prompts that produce user complaints or parser failures after the model change. Do not rewrite everything at once. Sort the failures by scope, format, missing assumptions, tool permissions, and output quality. This creates a small migration queue rather than a vague mandate to make the system more intuitive.

For each prompt, save the old input, the old output, the new output, and the expected result. Mark which behavior was intentional and which behavior was an accidental convenience. Then edit the prompt to state the intended rule. Keep the edit small enough that the effect can be explained.

Run the old and new prompt through a fixed test set. Include normal cases, boundary cases, missing information, contradictory instructions, long inputs, and repeated items. If a prompt feeds an agent, include tool errors and permission denials. The goal is not to make outputs identical. The goal is to preserve the behavior the product actually needs.

Anthropic’s migration guidance also points developers toward model-specific configuration and real-workload measurement. A migration is complete only when the task passes its acceptance tests and the team understands its cost and latency profile.

How to Write Better Instructions for Opus 4.7

Put the task first. State the target, scope, constraints, output format, and completion condition in a visible order. Anthropic’s prompting guidance is another reference for structuring instructions. If the prompt contains background context, separate it from the command. A model can then distinguish information from an instruction instead of treating every sentence as an equal request.

Use explicit repetition when the operation must apply to every item. Give a positive example and a negative example when the boundary is easy to miss. Name the fields that must not change. If the task includes a tool, describe what the tool is for and when it must not be used.

Say what to do with uncertainty. “Ask one question if the source is missing” is more useful than “be careful.” “Return `unknown` when the evidence is insufficient” is more useful than “do not hallucinate.” The prompt should turn a quality goal into an observable output.

Keep the instruction set maintainable. Long prompts can still be ambiguous when they repeat goals without defining decisions. Remove rules that no longer apply. Store reusable constraints in one place so a model upgrade does not produce five slightly different versions of the same contract.

Our AI coding agents guide is useful for comparing the surrounding tools, but a model comparison cannot replace a prompt contract. The same agent can behave differently when its scope, tools, and acceptance tests change.

How to Test Prompts in Production

A migration test should mirror the work users actually send. Synthetic examples are useful for edge cases, but they can miss long context, internal jargon, noisy documents, and tool results. Sample real tasks after removing sensitive data or run the tests inside an approved environment.

Use a fixed evaluation set for every model change. Record the prompt version, model ID, effort level, tool configuration, input size, output size, latency, and reviewer result. If the prompt is used for a high-impact decision, add a human review path and a clear rollback plan.

Watch for silent failures. A response can look polished while applying a rule to only one item. A JSON object can contain the right keys with the wrong values. An agent can report success after editing the wrong file. Assertions, schema validation, file diffs, and task-level tests catch problems that prose review may miss.

Do not grade only on whether the new output resembles the old output. If the old prompt depended on an unstated assumption, the new model may expose a requirement that the old workflow never documented. Evaluate against the desired behavior, not against accidental history.

For a broader workflow comparison, see our AI workflows versus pure agents analysis. The key question is always operational: what did the system do, what evidence supports it, and where can a human intervene?

What Developers Should Take Away

Claude 4.7 did not literally lose the ability to read between the lines. Anthropic documented a stronger tendency to follow instructions literally and explicitly, especially when prompts were written for an earlier model. That change can expose hidden assumptions in prompts, parsers, and agent harnesses.

The fix is not to add noise. Define the scope. State the format. Name the assumptions. Show an example. Describe the exception path. Set the tool boundary. Then run the task through a test set that measures the behavior the product needs.

Anthropic’s own advice is to retune prompts and harnesses and measure real traffic. That is the sound response to a model upgrade. Some workloads may become more reliable. Others may reveal ambiguity, use more tokens, or need a different effort setting. The result has to be measured rather than predicted from a social-media label.

The old “Claude-lash” narrative is less useful than the engineering lesson. When a helpful interpretation was never written down, a model change can expose the missing contract. Write that contract, test it, and keep the migration evidence. The prompt will be easier for both the model and the next developer to understand.