browser · idea · research

Imagine with Claude

A five-day research preview in which Claude generated software on the fly on a virtual desktop, with each click producing the next piece of interface.

inspireevidence: thinby Anthropicwww.anthropic.com/news/claude-sonnet-4-5 ↗

Imagine with Claude

  • Maker: Anthropic
  • URL: https://www.anthropic.com/news/claude-sonnet-4-5 (the announcement; the preview itself ran inside the Claude app)
  • Status (10 October 2026): ended. A “temporary research preview” released with Claude Sonnet 4.5 on 29 September 2025, “available to Max subscribers for the next five days.” No successor product has been announced under that name. Closed, no code or paper published.

What it is

A demo of software with no codebase: a virtual desktop where windows, apps and their contents were generated by the model as the person clicked. Each interaction asked Claude to produce the next piece of interface on the fly, rather than running code written in advance.

The problem it’s solving

It wasn’t solving a user problem so much as testing a thesis: if a model is fast and good enough, does software need to be written ahead of time at all? The UI becomes a continuous generation conditioned on what the person just did.

Its path / bet

The far end of the spectrum: every screen is ephemeral and generated per interaction. No durable app, no fixed component set, no stored program.

How it works

Publicly described only at a high level: the person starts with a prompt, Claude generates an interface, and each click or input is sent back to the model, which generates the next state of the interface. We found no primary technical description (representation, latency, caching), so the mechanics beyond that are unverified. Coverage is third-party tutorials written during or after the five-day window.

Strengths

  • The cleanest statement of the “UI is no longer costly” idea: the interface is as disposable as a sentence.
  • Shows the model as the runtime, not just the author, which clarifies by contrast what a separate runtime buys.

Weaknesses / limits

  • Every interaction waits on the model. That is exactly the latency fictty’s architecture exists to remove: the person should never wait on a model to move a cursor.
  • No persistence, no determinism, no read-back worth the name, no shared data.
  • Gone after five days; we can’t evaluate it now.

Relation to fictty

Inspire, by contrast. It is the strongest argument for fictty’s split: the agent decides what the screen is; a runtime makes it behave. Imagine with Claude put the model in the per-keystroke loop and that is why it stayed a demo.

Could fictty adopt it instead of building?

No. It no longer exists and was never available as a component.

What fictty should take from it

  • A clear framing for the blog post and the teaching angle: generating an interface per question is now plausible, so the question becomes where behaviour lives. Put generation at the level of the screen, behaviour at the level of the runtime.
  • A useful benchmark scenario: “an agent that generates the next screen” should be fast in fictty because only the changed node is patched and everything in between is local.

Sources