If your team uses Claude to draft customer emails, proposals or executive updates, judge the result by what the reader can understand and act on—not how often it uses an em dash. Claude Opus 5.5's reported writing changes make that distinction useful: shorter sentences can coexist with longer answers. A smoother draft still needs the right facts, scope and level of detail.
In its September 26 report, BleepingComputer describes Arena's comparison of high-reasoning Text Arena responses from August–September 2026. Opus 5.5 used about 95% fewer em dashes than Opus 5. Its average answer was nevertheless 481 words, compared with 453. These are reported sample averages, not a promise about your prompts.
What changed in the reported writing analysis
| Measure | Opus 5 | Opus 5.5 |
|---|---|---|
| Em dashes per 1,000 words | 15.2 | 0.8 |
| Semicolons per 1,000 words | 6.10 | 1.64 |
| Average words per sentence | 12.14 | 10.03 |
| Average words per answer | 453 | 481 |
The punctuation figures appear in the original Arena graphic reproduced with the report; BleepingComputer reports the sentence and answer averages. The accessed report and graphic do not provide enough methodology to reproduce the comparison. They should not be treated as a controlled test of your business workload. Sources checked September 27, 2026; ITECS did not run this benchmark.
Anthropic's September 22 Opus 5.5 announcement describes clearer communication and more emphasis on putting important information first. That is the vendor's characterization. It does not independently establish that your staff will spend less time reviewing an email or that an answer is factually correct.
Short sentences and concise answers are different goals
Sentence length measures one unit of writing. Answer length measures the whole deliverable. A model can split a complex sentence into several readable ones, then add examples, caveats and a recap. Each sentence becomes easier to scan while the total answer grows. Whether that is useful depends on the reader's task.
For a customer asking when the next update will arrive, an answer buried under background is a problem. For an engineer following a recovery procedure, deleting prerequisites or verification steps to meet an arbitrary word limit is also a problem. Set the required content first; then choose an appropriate length. Do not equate either brevity or detail with quality.
Treat punctuation as a brand preference, not an accuracy test. Removing an em dash does not verify a date, support a financial claim or turn a draft into human-authored work. Likewise, a polished tone should not earn an exception from your normal approval process. Review the substance even when the prose feels natural.
Give Claude a writing brief, not just a shorter-answer request
Anthropic's prompting guidance recommends explicit output constraints, relevant context and examples. Apply that principle to the deliverable: identify the reader, their decision, approved source material, required facts, format and review boundary. An instruction to be concise leaves most of those choices unresolved.
Here is an ITECS-recommended prompt template for a customer update. It is a proposed instruction, not a tested Opus 5.5 output or a guarantee that every response will comply. Replace the placeholder with approved information and inspect the draft before use.
Task: Draft a customer update using only the approved incident notes below. Audience: A nontechnical customer who needs to know the impact and next step. Format: A subject line and an email of at most 150 words. Lead with the current status. State the known impact, what we are doing, and the approved next-update time if provided. Evidence: Preserve the notes' uncertainty. Do not invent a cause, recovery estimate, commitment or completed action. If a required fact is absent, list it separately under "Questions for the owner"; do not fill the gap. Style: Use plain language and short paragraphs. Follow our supplied brand example. Avoid repeating the same reassurance. Review: Add a separate internal checklist mapping factual statements to the supplied notes. The checklist is not part of the customer email. Draft only; do not send. Approved notes: [Insert only information authorized for this task.]
Separate the customer-facing message from internal review notes. Otherwise, asking the model to explain every choice can produce a long response that is accidentally forwarded in full. Count the intended deliverable, not the combined email and checklist. If it exceeds the target, ask for a revision that preserves required facts; do not cut text mechanically at the word limit.
Example: a clear customer update without invented reassurance
Consider a hypothetical service team drafting an update during a disruption. Its approved notes confirm an affected function and an investigation in progress, but contain no verified root cause or restoration time. The team needs a short customer email and a separate internal record of unanswered questions. This is an illustrative workflow, not an ITECS client incident.
The writer supplies those notes, the intended audience and an approved tone example. The model drafts the message and identifies missing facts separately. A reviewer checks that the draft accurately describes the impact, does not imply resolution, and does not invent a recovery estimate. A pleasant sentence promising service will return shortly fails that check, regardless of its punctuation.
If the draft repeats reassurance in three different paragraphs, the reviewer requests one concise acknowledgment. If the draft omits an important limitation, the reviewer restores it even if that makes the message longer. The authorized owner approves the final text and distribution. The useful outcome is a clear, supportable update—not the shortest possible response.
Evaluate approved work, not just the first draft
Before changing the model or prompt used across a team, collect representative, authorized examples: customer correspondence, internal summaries, proposals and detailed instructions. Include incomplete evidence and conflicting source notes, not only easy requests. Use synthetic or properly approved material; a writing comparison is not permission to upload confidential documents.
Compare the current workflow with the proposed one using the same source material and task requirements. Record the exact model, date, prompt and available settings. Keep settings comparable where possible and document differences rather than calling the test perfectly controlled. Repeat important cases, and have reviewers assess drafts without seeing which model produced them when practical.
Score factual support and required-content coverage separately from readability and tone. Note unsupported commitments, missing qualifications, repeated points and format violations. Measure the time from starting the task to an approved deliverable, including fact-checking and rewriting. A fast first draft that needs extensive repair may not improve the workflow.
Track word count as a diagnostic, not the winner-selection rule. For API workflows, measure actual token usage and cost across drafts, revisions and retries. Word counts alone do not establish token cost or total task efficiency. Compare cost per approved deliverable alongside quality; do not extrapolate a bill from the reported answer-length averages.
Choose acceptance criteria appropriate to each use case. A customer message should have no unsupported commitments and should fit the approved communication format. A procedure must retain required steps and checks. A proposal needs verifiable claims and commercial-owner approval. Our AI agent evaluation guide extends this approach when writing also involves retrieval, tools or external actions.
Make the writing standard reusable across the team
Keep a small set of approved examples and task-specific prompts with named owners and review dates. Explain why each example works: it answers the reader's question, distinguishes known facts from uncertainty, and uses detail where it changes a decision. Avoid a long list of banned punctuation that teaches appearance without teaching judgment.
Recheck important tasks after a model or prompt changes. Preserve the previous approved workflow while the replacement is evaluated. Keep a human responsible for consequential communications; neither a second model's agreement nor a cleaner writing style is proof that a claim is true.
ITECS can help turn these practices into role-specific AI training and a practical AI consulting engagement. Start with one recurring writing task, a clear definition of an acceptable result and a baseline for review effort. Talk with ITECS about making AI-assisted writing useful, consistent and accountable for your business.
