Claude Opus 5.5 builds a real-time image pipeline in the browser, no external libs

Opus 5.5 writes the code, Artifacts runs it instantly: what the duo unlocks

Claude Opus 5.5 is a reasoning model from Anthropic's lineup; on its own, it only returns text and code inside a chat. What turns that code into something that actually runs is Claude Artifacts, the sandbox built into Claude.ai that executes the generated code, like the canvas used in this experiment, directly in the browser. In practice, that removes the need to set up a server or a build process to see the result working.

Simon Willison published on his blog, on October 23, 2026, an experiment called Quick Study: a single prompt for Opus 5.5 in "High" mode asking for an artifact that opens a photo and, within a few seconds, "paints" a version of it using canvas and a simulated paintbrush.

The combination unlocks something specific: going from an idea ("I want a painting filter that runs in the browser") to a working prototype without opening an editor, without npm install, without setting up a bundler. The model writes the computer-vision algorithm (Sobel edge detection) and the brush animation; Artifacts exposes that as a page that already runs right there, inside the chat itself.

Prerequisites: model, plan, and almost zero dependencies

To reproduce the experiment you need access to Claude Opus 5.5 with "High" effort. You also need the Artifacts feature enabled on the account, and a current browser with support for the Canvas API and FileReader, which already covers practically any 2026 browser.

Willison is explicit about the code dependencies: no external library besides Google Fonts. No p5.js, OpenCV.js, or three.js: the Sobel implementation and the painting logic come entirely from what Opus 5.5 wrote on the spot, in plain JavaScript over a <canvas>.

It's worth contrasting this with Willison's own earlier experiment, linked in the post: to simulate a watercolor illustration, he used another model from the family (Claude Fable) built on P5.js, a generative drawing library. This time the bar was set higher: zero drawing libraries, only the browser's native API.

Step by step: from the prompt to the canvas painting itself

The prompt published by Willison is short and direct:

Build an artifact where you open a photo and it rapidly (in a few seconds) paints a version of that photo using a canvas element and simulated paintbrush

Simon Willison, author of Quick Study

To reproduce this flow in a typical project, the path would be:

1. Open a conversation on Claude.ai with the Opus 5.5 model and reasoning effort set to "High"
2. Paste the prompt above, with no additional context (it's the only input Willison recorded)
3. Let Claude generate the artifact: a file with <input type="file"> to load the photo, a <canvas> to draw on, and a script that first applies the Sobel kernel to find the edges and then animates brush strokes following those edges
4. Run the artifact right there, dropping in a photo and watching the result take shape over a few seconds
5. Export the generated HTML and host it as a static page, since there's no dependency on a server or a build step

The post doesn't include the artifact's full source code, only the description and the result, so the snippet below is a reconstruction of the kind of logic Sobel requires, not a transcription of Willison's code:

Editor's note: the code in this section was not run in a real environment. Validate it before using in production.

function sobel(pixels, width, height) {
  const gx = [-1, 0, 1, -2, 0, 2, -1, 0, 1];
  const gy = [-1, -2, -1, 0, 0, 0, 1, 2, 1];
  const edges = new Float32Array(width * height);
  for (let y = 1; y < height - 1; y++) {
    for (let x = 1; x < width - 1; x++) {
      let sx = 0, sy = 0, i = 0;
      for (let dy = -1; dy <= 1; dy++) {
        for (let dx = -1; dx <= 1; dx++) {
          const idx = (y + dy) * width + (x + dx);
          sx += pixels[idx] * gx[i];
          sy += pixels[idx] * gy[i];
          i++;
        }
      }
      edges[y * width + x] = Math.sqrt(sx * sx + sy * sy);
    }
  }
  return edges;
}

On top of that edge map, the "simulated paintbrush" part of the prompt calls for a second layer: a loop that draws small strokes (ctx.lineTo, ctx.stroke) following the regions with the highest gradient, spaced out over time with requestAnimationFrame to give the sense of a painting happening gradually, rather than the image appearing fully formed all at once.

Where the magic hits its limits: what Willison didn't show

Willison's post is a short record: he publishes the prompt, describes the result in one sentence, and names the technique (Sobel) used. There's no link to the live artifact, no published code, and no measurement of actual run time: the promise of "a few seconds" comes from the prompt itself, not from a benchmark he ran and reported.

That matters for anyone looking to reproduce the flow. Sobel in plain JavaScript, pixel by pixel, without WebGL or Web Workers, tends to get heavy on high-resolution photos or weaker phones. There's no guarantee in the source that the artifact scales beyond the original demo, nor that the visual result is consistent across different photos, such as a portrait versus a low-contrast landscape.

Another point left out: the prompt doesn't specify a color palette, stroke style, or output resolution, decisions that Opus 5.5 made on its own and that Willison didn't document. Reproducing the experiment with the same prompt can produce a visually different result each time, because the model fills in those gaps in a new way every run.

Who it's worth it for (and who it isn't)

This kind of combination is worthwhile for rapid prototyping: testing an image filter idea, demonstrating a classic computer-vision algorithm (Sobel itself is covered in introductory image-processing courses), or generating a visual prototype without setting up a project, a bundler, or installing anything.

It's not a path to production, though. Anyone who needs image processing at scale, with predictable performance and guaranteed cross-browser support, will want WebGL via shaders or WebAssembly, not a 2D canvas running pixel-by-pixel Sobel generated by an LLM in a single session. It also doesn't serve anyone who needs to audit the code: without the published source, there's no way to know what implementation decisions Opus 5.5 made, or to review the quality of what Willison only described through the visual result.