Prompting Claude Opus 5.5
- ID
- 29327
- Status
- summarized
- Published
- 28 Sep 2026, 3:33 PM
- Fetched
- 28 Sep 2026, 10:38 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5-5
- Source URL
- https://hnrss.org/best
Summary
- Score
- 7.0
- Created
- 28 Sep 2026, 10:38 PM
- Tags
- Audience
- developersai_ml_learnersai_agent_usersvibe_coderssaas_founders
What happened
Anthropic's docs page for prompting Claude Opus 5.5 describes behavioral differences from Opus 5 and gives harness patterns for them. The one hard number in the text: Opus 5.5 generates output tokens more than 30 percent faster than Opus 5 and tends to finish the same task with fewer tokens, and existing Opus 5 prompts are said to work unchanged. The page is organized as a symptom index (effort calibration, thinking-disabled prompts, unattended agents that stall after reporting progress, stop_reason "refusal", silent long agentic turns, multi-app context, multiagent time signals, pasted text being followed as instructions, complex visual inputs, generic frontend output) and points to a separate migration guide for four breaking API changes from Opus 5. The excerpt is cut off before the actual capability details and before those four breaking changes are listed.
Why it matters
If you already ship on Claude Opus 5, the two things that force action are the four breaking API changes and the documented failure modes: agents that stop partway after a progress update, silent long agentic turns, and stop_reason "refusal" responses all have named fixes here rather than guesswork. The 30 percent faster output tokens and fewer tokens per task is the only cost/latency claim in the text, so treat it as a reason to re-measure your own token spend after swapping the model ID, not as a reason to swap blindly. Because the excerpt is truncated, you cannot see the four breaking changes or the effort-calibration guidance from this text alone - open the migration guide before changing anything.
Discussion angle
The page is written as a symptom-to-fix index rather than a feature list - is that a better shape for docs than prose, and would your team adopt the same structure for your own internal prompt/harness runbooks? Pair it with a concrete check: which of the listed symptoms (stalled unattended agents, stop_reason "refusal", silent long turns) have you actually hit, and did the prescribed fix match what you did?