**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.Made with @claudeai Opus 5.5 pic.twitter.com/jaXJ7H4vAH
— DreW (@devteamdrew) September 22, 2026
View Addy Osmani's Claude Opus 5.5 Three.js demo on XThis 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.
View Jake Eaton's Opus 5.5 programmatic painting examples on XThis 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.
View Ethan Mollick's Opus 5.5 shader example on XShader 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.
View the Vals AI Opus 5.5 multi-agent research experiment on XThis 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: ```text 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:
View Boris Cherny's post about the HAProxy C-to-Rust test on XA 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.
View Aaron Levie's Opus 5.5 enterprise testing results on XThis 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: ```text 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: ```text developer → model → code ``` It is increasingly: ```text 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: ```text 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: ```text 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: ```text 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.