Claude Opus 5.5 Examples: 8 Real-World Demos That Show What Changed

Key Takeaways

• Claude Opus 5.5 launched on September 22, 2026 as the first model in Anthropic's 5.5 family. Anthropic says it reaches roughly Claude Fable 5.1-level performance on most work while costing about 40% less per typical workload than Opus 5.
• The most interesting Opus 5.5 examples are not short coding snippets. They involve long-running agent work, code-generated visual media, multi-agent research, large migrations, and cross-repository engineering.
• Public X demos are useful evidence of what skilled users can coax from the model, but they are not controlled benchmarks. Prompts, iteration counts, scaffolding, tools, and human intervention can vary.
• Anthropic's own early-access results strengthen the case for long-horizon coding: a 680,000-line migration reportedly finished in under a day, while another 200,000-line audit and repair finished in under three hours.
• A recurring pattern across the examples is that Opus 5.5 is being used as an agent that creates and verifies artifacts, not simply as a chatbot that returns text.

Claude Opus 5.5 arrived with eye-catching benchmark numbers, but benchmarks alone do not explain why developers are paying attention.

The more useful question is: what are people actually building with it?

The first wave of public examples points to a broader shift in Claude's role. Opus 5.5 is being used to generate animations from code, build visual scenes, emulate painting styles programmatically, coordinate other agents, migrate large codebases, and perform multi-hour engineering work with relatively little supervision.

That distinction matters. A model that can answer a difficult coding question is useful. A model that can maintain a goal, edit many files, run tools, inspect the result, recover from mistakes, and keep working for hours is useful in a different way.

Claude Opus 5.5 at a Glance

Anthropic positions Opus 5.5 around agentic coding, computer use, and professional knowledge work. The standard API price is $4 per million input tokens and $20 per million output tokens, with cache reads at $0.20 per million tokens. Anthropic also says output generation is more than 30% faster than Opus 5.

Selected Anthropic-reported results include:

Anthropic itself cautions that benchmark margins at this capability level do not always translate cleanly into equally large real-world differences.

That is why the following examples are more revealing than a leaderboard alone.

Example 1: A Code-Built Stop-Motion Animation

Developer DreW shared a visual piece with the simple caption "Made with @claudeai Opus 5.5." In adjacent posts and replies, DreW described using Claude Code for the project, said the work was made in code, and noted that some back-and-forth was used for sound design and visual flow.

Why this matters: the model is being used as a visual-production agent through code. Instead of producing a static answer, it can participate in a loop where code becomes the medium for composition, motion, timing, and revision.

The important caveat is that this is a showcase, not a one-shot benchmark. The creator explicitly referenced iterative cleanup. That makes the example more useful, not less: it resembles how production work is actually done.

Example 2: Three.js as a Generative Visual Medium

Addy Osmani highlighted another visual-coding test: a pelican riding a bicycle built in Three.js with Opus 5.5. The point is not the pelican itself. The interesting part is that a language model can use a programmable graphics stack to turn a visual concept into geometry, materials, camera choices, layout, and rendered composition.

This is a useful pattern for developers because code-generated visuals are editable and inspectable. A generated image is usually the end product. A Three.js scene can be changed, animated, parameterized, connected to user input, or shipped as part of a web application.

In practical terms, Opus 5.5 can be treated less like an image generator and more like a visual software engineer when the desired output can be represented in HTML, CSS, SVG, Canvas, WebGL, Three.js, or another programmable medium.

Example 3: Pixel-by-Pixel Painting Without an Image Model

Anthropic researcher Jake Eaton shared one of the more technically unusual demonstrations. Eaton said the images in his experiment were generated pixel by pixel by Python programs, without an image model or off-the-shelf art software. The programs used standard libraries and roughly 7,500 lines of code to emulate different painting styles.

This is a stronger test of procedural representation than ordinary text-to-image generation.

The model must translate concepts such as brush texture, palette, spatial composition, and stylistic cues into executable rules. That requires several capabilities at once:

• decomposing a visual style into programmable primitives;
• maintaining global composition while generating local detail;
• using code as a compressed representation of visual intent;
• iterating on the rendered result rather than merely describing it.

For developers building design tools, educational software, generative art systems, or browser-native creative applications, this is a more transferable capability than simply producing a pretty image.

Example 4: Shader Generation and Visual Reasoning

Wharton professor Ethan Mollick also tested Opus 5.5 on a shader task and published the model's version of the same visual prompt he had used for comparison. His early impression was positive overall, while he still noted that Claude's language could remain dense in some contexts.

Shader work is a useful stress test because visual quality often emerges from compact mathematical code. The model has to reason about coordinates, transformations, color functions, repetition, lighting-like effects, and the relationship between small code changes and large visual changes.

This suggests an important practical use case: rapid exploration of visual systems where the output is generated by deterministic code.

Example 5: Ten Opus 5.5 Agents Working on a Shortest-Path Algorithm

Vals AI ran a substantially different experiment. It spawned 10 Claude Opus 5.5 agents at maximum effort, gave them a shared message board, and asked them to search for a theoretical improvement to exact shortest-path algorithms while producing a complete Lean proof.

Vals reports that within 15 hours the agents produced a result called C-HD, along with Lean sources, an informal paper, and verification records. The agents were instructed to share discoveries, challenge one another, preserve failed approaches, and require reproducible verification before declaring success.

This example is significant for a reason that has little to do with chat quality: it shows a workflow in which the model is a member of a research organization composed of other model instances.

The architecture is roughly:

research objective
      ↓
coordinator / shared workspace
      ↓
multiple Opus 5.5 agents
  ├─ algorithm exploration
  ├─ literature comparison
  ├─ proof construction
  ├─ adversarial review
  └─ Lean verification
      ↓
reproducible artifact

The strongest part of this workflow is not parallelism by itself. It is the use of independent criticism and machine-checkable verification to reduce the chance that several agents merely reinforce the same mistake.

The result should still be treated as a research claim rather than a universally replicated benchmark, but the published proof package makes it much more inspectable than a screenshot-only demo.

Example 6: Rewriting HAProxy From C to Rust

Anthropic ran an internal test in which Opus 5.5 and Claude Fable 5.1 were asked to translate HAProxy from C to Rust.

According to Anthropic, both rewrites passed nearly all of HAProxy's regression tests. Opus 5.5 finished in 9.5 hours, compared with 12 hours for Fable 5.1, and cost 51% less.

Boris Cherny also highlighted the test publicly:

A language migration of this type is fundamentally different from generating a new toy project. It requires the agent to preserve behavior across a large existing system, understand interfaces and tests, keep track of many dependent changes, and repeatedly validate that the translated implementation still works.

That makes this a much more meaningful signal for teams considering AI-assisted modernization of mature repositories.

Example 7: Enterprise Knowledge Work With Fewer Tokens

Box CEO Aaron Levie shared results from Box's testing of Opus 5.5 on complex enterprise knowledge-work tasks involving unstructured data. He reported materially lower token usage, reduced verbosity, and faster execution relative to Opus 5.

This is important because the economics of an agent are not determined only by the API price printed on a pricing page.

A more useful model is:

total task cost
= token price
× tokens per turn
× number of turns
+ retries
+ tool calls
+ human rework

A model with a higher nominal token price can be cheaper for a real workflow if it needs fewer retries, fewer tool calls, and less human correction.

Anthropic makes this same argument in its Opus 5.5 launch materials: the model is cheaper per token than Opus 5, but the larger savings come from completing tasks with fewer tokens and fewer steps.

Example 8: One Claude Session Coordinating a 40-PR Rebase

One of the strongest early-access engineering stories came from Stripe.

Anthropic quotes Stripe staff engineer Cristian Rivera describing a multi-day rebase of 40 stacked pull requests in which one Opus 5.5 session directed roughly a dozen additional sessions. The model surfaced conflicts clearly enough for the engineer to return after hours away and make decisions quickly; all 40 pull requests passed CI the following afternoon.

This example points toward a different future for coding agents.

The basic pattern is no longer:

developer → model → code

It is increasingly:

developer
   ↓
orchestrator agent
   ├─ migration agent
   ├─ test agent
   ├─ debugging agent
   ├─ review agent
   └─ documentation agent

Once a model begins coordinating other agents, delegation quality, state management, concise reporting, and self-verification become as important as raw coding ability.

That is one reason Opus 5.5's communication improvements matter. Long-running systems become difficult to supervise when the model produces excessive narration or fails to surface the decisions that actually require human input.

What the Best Opus 5.5 Examples Have in Common

Across these cases, several patterns repeat.

1. The output is an artifact, not an answer.

The strongest examples end with something inspectable: code, an animation, a rendered scene, a proof, a migrated repository, a passing test suite, or a structured work product.

2. Verification is part of the workflow.

Regression tests, CI, Lean, visual rendering, and independent agent review all provide feedback that is harder to fake than a persuasive paragraph.

3. Long-horizon work is becoming a differentiator.

Anthropic says an early tester completed a 680,000-line migration in under a day, while a separate 200,000-line audit-and-fix job finished in under three hours; Opus 5 reportedly needed more than 20 hours for the latter and used 2.5 times as many tokens.

4. Code is becoming a general-purpose creative medium for models.

Several of the most striking demos are technically coding tasks even though the user experiences them as art, motion graphics, interactive scenes, or games.

5. Better orchestration can matter more than a better one-shot answer.

The multi-agent research experiment and Stripe rebase both point toward models that organize work, delegate, verify, and report rather than simply generate a single response.

How to Reproduce the Workflow Instead of Copying the Demo

Copying the exact prompt from a viral example is rarely the best way to evaluate a model.

A better test is to recreate the structure of the task.

For a large codebase task:

Inspect the repository before editing.

Goal:
Migrate [subsystem] from [old architecture] to [new architecture] without changing user-visible behavior.

Requirements:
- Build a dependency map first.
- Define measurable acceptance criteria.
- Make changes in small, testable stages.
- Run the relevant test suite after each stage.
- Investigate failures instead of bypassing them.
- Keep a decision log for ambiguous cases.
- Before finishing, run a full regression pass and summarize any remaining risk.

For a creative coding task:

Build an interactive visual scene using [Three.js / SVG / Canvas / WebGL].

Do not stop after producing code.
Render the result, inspect it visually, identify the three weakest aspects, and iterate.

Requirements:
- Keep the project self-contained.
- Prefer procedural assets where practical.
- Make composition, motion, typography, and interaction intentional.
- Test at desktop and mobile sizes.
- Finish only when there are no obvious broken states.

For a multi-agent research task:

Create multiple independent workstreams for this problem.

Roles:
- proposer
- skeptical reviewer
- literature checker
- implementation/proof builder
- verification lead

Agents must share findings but should not converge merely because another agent is confident.
A claim is complete only when it has a reproducible artifact and an independent verification pass.
Preserve failed approaches and explain why they failed.

The key principle is to give the model a closed feedback loop. The agent should be able to observe whether its work succeeded.

Where Opus 5.5 Still Needs Caution

The launch-day examples are impressive, but they should not be interpreted as evidence that every Opus 5.5 session will perform at the same level.

There are several reasons:

• Public demos are selected examples. Failed attempts are less likely to be posted.
• Scaffolding matters. Claude Code, custom tools, browser access, subagents, tests, and project-specific instructions can materially change results.
• Iteration counts are often unclear. A polished output may have required several rounds of feedback.
• Model effort changes cost and behavior. Maximum-effort results should not automatically be treated as representative of default usage.
• Verification remains essential. A model can produce convincing but incorrect code, analysis, or research if the environment provides no reliable way to check the result.

Anthropic makes a related point in its own launch post: benchmark gaps at the frontier are becoming less reliable as predictors of practical differences.

For serious evaluation, teams should therefore measure task completion rate, elapsed time, token consumption, tool calls, retries, human interventions, regression failures, and rework on their own workloads.

Conclusion

The most important Claude Opus 5.5 examples are not impressive because the model can produce more text. They are impressive because they show a model increasingly able to turn intent into a verified artifact over a long sequence of actions.

The early evidence clusters around four areas:

• long-running software engineering, including migrations, audits, and multi-repository work;
• creative coding, where JavaScript, Python, shaders, and Three.js become visual media;
• multi-agent orchestration, where Claude instances divide work and critique one another;
• professional knowledge work, where efficiency depends on finishing correctly with fewer turns and less rework.

That makes the best way to evaluate Opus 5.5 straightforward: do not ask it only a harder question. Give it a real task with tools, constraints, and a way to verify success.

The difference between a strong chatbot and a useful autonomous agent becomes much easier to see when the output has to compile, render, pass tests, survive review, or prove itself.