Prompting Claude Opus 5.5

來源原標題

Prompting Claude Opus 5.5

作者

Michelangelo11

原始標籤

hackernews

來源訊號

HN points 193　HN 留言 218

原始連結

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5

摘要原文

 Copy page  This guide covers the prompting patterns specific to Claude Opus 5.5. For the model's capabilities and API changes, see What's new in Claude Opus 5.5 . For techniques that apply across all current Claude models, see Prompting best practices . Claude Opus 5.5 generates output tokens more than 30 percent faster than Claude Opus 5 and tends to finish the same task with fewer tokens. Existing Claude Opus 5 prompts should perform well without changes, and the patterns in Prompting Claude Opus 5 remain a reasonable starting point. Start with the section that matches what you observe: Unsure which effort level to run, or turns run longer and cost more than they did on Claude Opus 5: Calibrate effort Your Claude Opus 5 integration ran with thinking disabled: Prompts written for thinking disabled An unattended agent stops partway through a long task after reporting progress: Unattended agentic runs Requests return stop_reason: "refusal" : Safeguard refusals Long agentic turns look silent, or you want updates at predictable points: User-facing progress updates An agent that works across several connected apps misses information the task didn't point to: Explore context in multi-app workflows You run a team of agents and want it to finish sooner: Time signals for multiagent harnesses Replies in a chat application start slowly because the model thinks at length first: Thinking instructions in chat system prompts The model follows instructions that arrived inside text a user pasted: Mark pasted text in user messages Answers about dense charts, diagrams, or screenshots miss detail: Tools for complex visual inputs Frontend output looks generic: Frontend design defaults Capabilities relevant to prompting  The capabilities that matter most for prompting are: Agentic coding and code review: The model is strongest on multistep work in a real repository, such as carrying a change through a large code base until its tests pass. In Anthropic's testing, at its default medium effort the model matched or beat Claude Opus 5 at high effort on such tasks, in fewer steps and with fewer tokens. It also sustains long-running autonomous work better than Claude Opus 5, such as multi-hour audits and migrations of large code bases run end to end with parallel subagents and little oversight. Early testers also reported stronger code review, with more bugs caught than on Claude Opus 5 and fewer false alarms, and it explains its changes in plain language. Knowledge work: The model is much less likely to state an incorrect figure or cite the wrong source. It's better at financial modeling tasks, such as building a financial model and one-page summary for a transaction or finding and fixing errors in a valuation workbook, and it catches details that are easy to miss in large inputs, such as a date in a long planning thread that falls on the wrong weekday or a chart in a slide deck that doesn't match the underlying figures. The spreadsheets, slides, and documents it produces need less editing before you share them. Communication: Its reports on agentic work, both the updates while it works and the summary when it finishes, say plainly what it did, what it found, and what it needs from you. See User-facing progress updates . Charts, diagrams, screenshots, and computer use: The model reads visual material more accurately than Claude Opus 5 without extra tooling: in Anthropic's testing, even at its lowest effort setting it read values off dense charts more accurately than Claude Opus 5 did at its highest, using a small fraction of the output tokens. It is better, too, where meaning depends on position rather than text: which boxes an arrow connects in a flowchart, what changed between two versions of a diagram, or exactly when a meeting starts and ends in a calendar screenshot. It's also more reliable at computer use, where it operates applications from screenshots over many steps: at its default effort it matched the success rate that Claude Opus 5 reached only at a much higher effort setting. See Tools for complex visual inputs . Calibrate effort  Effort is the main control for how much Claude Opus 5.5 thinks, and because thinking is always on, it's the first setting to adjust when trading off intelligence, latency, and cost. Start at medium , the default on Claude Opus 5.5 (Claude Opus 5 defaults to high ), set it explicitly, and test several levels against your own evals rather than carrying over the setting you used on Claude Opus 5. Effort level names don't correspond to the same amount of thinking across models: in Anthropic's testing, Claude Opus 5.5 at medium matches or exceeds Claude Opus 5 at high on coding and knowledge-work evaluations, and on several coding evaluations low comes close to it at much lower cost. See Recommended effort levels for Claude Opus 5.5 . At a given level, Claude Opus 5.5 tends to think more per turn than Claude Opus 5, especially at xhigh and max . If you keep the effort value you set for Claude Opus 5, expect longer turns and more output tokens. Three adjustments help: Set max_tokens high enough to leave room for the model's thinking tokens and the reply. Thinking counts toward max_tokens even when thinking content isn't returned to you, so a limit sized for Claude Opus 5 with thinking off can cut replies off. For the long turns that agentic coding can produce, a max_tokens of 128,000, the model's maximum, has worked well in Anthropic's testing. Reserve xhigh and max for work where you've measured a quality gain. To get less thinking, lower the effort level first. Lowering effort reduces thinking, and with it cost and latency, more reliably than prompt instructions do. Changing the top-level effort value between requests invalidates the prompt cache. To run individual turns at a different level, use a per-message effort change (beta) instead, which keeps the cache. Prompts written for thinking disabled  Claude Opus 5 accepts thinking: {"type": "disabled"} at high effort or below; Claude Opus 5.5 doesn't, and the migration guide covers the request change. If your Claude Opus 5 integration ran with thinking disabled, four changes go with it: Start at low effort and measure. At low the model keeps its thinking short. How often it skips thinking altogether depends on your prompts, so measure latency and quality on your own traffic and move to medium if quality drops. If time to first token still matters after that, a system prompt line such as "Answer directly without deliberating." can reduce thinking further; measure quality when you add it, because less thinking can lower it. Remove instructions that stood in for thinking. If your prompt asked the model to write out its reasoning in the response as a substitute for thinking, remove that instruction and read the reasoning from summarized thinking blocks instead ( display: "summarized" ); a prompt that pushes the model to reproduce its reasoning in the response text can be declined with the reasoning_extraction refusal category . Re-test the thinking-disabled mitigations. Running with thinking disabled recommends a combined instruction (permission to speak before a tool call, what to do when no tool fits, no internal tags) and removing any rule that tells the model not to think. Both address artifacts that appear on Claude Opus 5 only when thinking is disabled. With thinking always on, check whether you still need the instruction, and remove the no-thinking rule either way. Read the response by block type. Check each block's type instead of assuming the first content block is text: a response may or may not begin with a thinking block, whose thinking field is empty under the default display: "omitted" . Unattended agentic runs  On long tasks with several parts, Claude Opus 5.5 keeps the user updated as it works, and some of those updates end the turn with text rather than a tool call ( stop_reason: "end_turn" ). (193 points, 218 comments on Hacker News)