On October 3, 2026, Anthropic's Claude account shared a thread of favorites from recent weeks of Opus 5.5 creations: a working watermill, embossed cards, a 3D site that flies you from outside the Milky Way down to Jupiter's moons, and water simulated in the browser. The thread had about 228,800 views when captured.
Showcase threads are marketing, and they are also a useful signal of what a model can do in practice. This post collects the highlights, embeds nine community clips, and — more usefully — explains how to build this kind of browser demo yourself, including how to check the output instead of trusting a good-looking clip.
TL;DR — what people are asking
| Question | Answer |
|---|---|
| What did Anthropic share? | A watermill, embossed cards, a Milky Way-to-Jupiter 3D site, browser-simulated water |
| Which model? | Claude Opus 5.5 |
| When? | October 3, 2026 |
| Is code available? | Not stated in the posts |
| Single prompt? | Not stated; assume iteration |
| Tech used? | Not stated; browser 3D demos typically use Three.js or WebGL |
| Can I make my own? | Yes; see the build guide below |
| Community clips? | Nine embedded below |
The four highlights
Anthropic's posts are short captions on videos, so the details come from what the clips show and from how similar demos are typically built.
- A working watermill. A mechanical scene with a rotating wheel, which implies a physical model of motion and likely water or flow. "Working" suggests the parts move in a believable way rather than a static render.
- Embossed cards. Cards with a raised, tactile look. This kind of effect is usually done with lighting, normal or bump maps, and careful shading rather than real geometry.
- A 3D site from outside the Milky Way to Jupiter's moons. A scroll or camera-driven journey across enormous scale differences, which is a classic hard problem in 3D graphics because of precision and level-of-detail.
- Water simulated in the browser. Real-time water in a page, which usually means a shader-based surface with ripples, reflection and refraction.
None of these require a new class of technology. They are within reach of browser graphics APIs. What is notable is that a language model can write the code, and that the code runs on ordinary hardware.
Nine community videos
These are independent posts from X, embedded as shared. I could not load their contents when preparing this post, so I am not describing each one; watch them for yourself.
How to build a demo like this
The approach is the same one that produced earlier Opus 5.5 browser work, such as the vibe-coded browser games and the code-drawn viral videos.
1. Set up the environment
Use Claude Code or another coding agent with Opus 5.5, in an empty folder. Ask for a single HTML file with no build step. That keeps the loop fast and makes the result easy to share. For setup, see our loop engineering guide.
2. Write the prompt like a brief
A good prompt names the scene, the behavior, the constraints and the check. For example:
Build a single index.html using Three.js from a CDN. Scene: a wooden watermill
beside a stream. Requirements: the wheel rotates at a speed tied to water flow;
the water surface has ripples and reflects the sky; a slow orbiting camera;
60 fps on a mid-range laptop. Add a small control panel to change flow speed.
Do not use external image assets; generate textures procedurally.
Name the library, the visible behavior, a performance target and an asset rule. Vague prompts produce generic scenes.
3. Make the agent look at its own work
The most important step. Ask the agent to open the page in a headless browser, take screenshots at a few camera positions, and critique them against your brief. A model that never sees its output will confidently ship a black canvas. Our guide to how Opus 5.5 task cost behaves in Claude Code covers keeping these loops affordable.
4. Iterate on one thing at a time
Change the water, then the lighting, then the camera. Large rewrites invite regressions. Keep each change small enough to check by eye.
5. Set a frame budget
Ask the agent to measure frame time and reduce cost if it exceeds a target. Typical levers are fewer particles, lower shadow resolution, and simpler shaders. A demo that runs at 20 fps on your laptop will stutter on a phone.
6. Handle scale carefully
For the Milky Way-to-Jupiter case, huge scale ranges break naive 3D scenes because floating-point precision degrades far from the origin. Ask for techniques such as logarithmic depth buffers, moving the world instead of the camera, or switching between separate scenes at different scales. You do not need to implement these yourself; naming the problem helps the model choose.
7. Verify before you share
Check the page on a second device, in a different browser, with a throttled CPU. Confirm no console errors. Read the code for anything that loads external resources, and replace placeholders. Our guide to avoiding vibe coding mistakes lists common failure modes.
Prompts to try in your first hour
If you want to learn by doing, use small, checkable briefs. Each of these maps to one of Anthropic's highlights and can be finished in a single sitting.
- Embossed card. "Build a single HTML file with one trading-card-style panel. Use CSS and a canvas to fake an embossed, raised look with a light source that follows the cursor. No external images." This teaches lighting and pointer input without 3D.
- Water surface. "Using WebGL in one HTML file, render a rectangular water surface with ripples that start where I click, a sky reflection, and a frame-time readout in the corner." This teaches shaders and a measurable performance target.
- Spinning mechanism. "Build a simple watermill in Three.js with a wheel that rotates at a speed set by a slider. Add soft shadows and a ground plane." This teaches a scene graph, animation and shadows.
- Scale journey. "Build a camera path that starts far from a star field and descends to a planet with four moons, switching between scenes at different scales to avoid precision problems. Add a progress bar." Start here only after the others, because scale handling is the hard part.
For each brief, ask the agent to screenshot the result, list three visual problems, and fix the worst one. Repeat twice. That loop teaches more than the first output does.
What to look for when you review the code
- Resource loading. Are textures and libraries loaded from places you trust, and do they still work offline?
- Animation loops. Does the page keep rendering when the tab is hidden, burning battery? Look for a visibility check.
- Resize handling. Does the canvas resize correctly on a phone rotation?
- Hard-coded numbers. Magic constants for speed and size are a sign the model guessed. Move them into a settings object so you can tune them.
- Error paths. If WebGL is not available, does the page say so, or does it show a blank screen?
What the showcase does and does not tell you
It shows that Opus 5.5 can produce impressive visual output in the browser, in the hands of people who iterate and curate. It does not show:
- Success rate. Showcases are selected from many attempts.
- Prompt effort. The number of iterations is usually hidden.
- Robustness. A great clip can hide bugs outside the filmed path.
- Cost. Heavy iteration with a top-tier model has a price; see Epoch's ranking of Opus 5.5 and the launch pricing guide.
For a more grounded look at what people built in the model's first day, including formally verified code and a model-comparison benchmark, see 10 things builders made with Opus 5.5. For the drift question — whether outputs degrade after launch — see LiveNeRF and post-launch drift.
What people are asking
Did Opus 5.5 make these in one shot?
Unknown. Anthropic's posts do not say. Plan on iteration.
Is this just Three.js?
The posts do not name the technology. Browser 3D is most often Three.js or raw WebGL, but check the creators' posts if you want specifics.
Can I get the code?
Not from Anthropic's thread, as far as I could see. Some creators share repositories; check the individual posts.
Will it run on my phone?
It depends on how heavy the scene is. Ask for a mobile-friendly mode and test on a real device.
How is this different from image or video generation?
These are programs that run in your browser and respond to input, not rendered clips. You can inspect, edit and extend the code.
Honest limitations
- I could not load the nine community posts and have not described their contents.
- The details of Anthropic's four highlights are inferred from short captions.
- Showcase results are curated and do not measure typical success rates.
- I did not reproduce any of these builds.
Bottom line
Anthropic's thread highlights what Opus 5.5 can produce in the browser, and nine community clips add to the picture. The reusable lesson is the workflow: a single-file brief, a visual check loop, small iterations and a frame budget. Build one scene end to end before judging the model by someone else's best take.
Related on explainx.ai
- 10 things builders made with Opus 5.5
- Browser games built with Opus 5.5
- How Opus 5.5 viral videos are made
- Opus 5.5 task cost in Claude Code
- Claude Opus 5.5 launch guide
- Loop engineering with coding agents
- Vibe coding nightmares and how to avoid them
Details reflect Anthropic's October 3, 2026 thread and community posts; contents of embedded posts were not independently reviewed.
