thevibeworks concept
Try Claude thevibeworks/opus-5-5-for-everyoneGitHub

ConceptUnofficial

Opus 5.5 and interactive answers for everyone

Some answers are better used than read. A training plan wants a calendar. A job offer wants a side-by-side. Consistent hashing wants a ring you can poke at.

This page is a working sketch of that idea with Claude Opus 5.5: answers composed from text, visuals and small tools, shaped to fit the question. It borrows its structure from OpenAI’s “GPT‑6 and Intelligent UI for everyone” post and rebuilds every demo from scratch. Every interactive below was written by Opus 5.5 in a single session, as plain HTML, CSS and JavaScript, and runs entirely in your browser.

break down how a mechanical keyboard is built

Mechanical keyboard

A mechanical keyboard is a stack of five layers. Keycaps are the part you touch. Under each one sits a switch, a small spring-loaded mechanism that closes a circuit when pressed. A metal or plastic plate holds the switches in a rigid grid. The printed circuit board wires every switch to a microcontroller, which scans for presses and reports them over USB. The case holds the stack and shapes much of how the board sounds and feels.

Mechanical keyboard

Introducing interactive answers

An interactive answer is still an answer. It starts with what you need to read, then adds what you need to touch: a diagram you can take apart, a table that recalculates when the numbers change, a checklist that keeps your place.

The format follows the question. Two options want to sit side by side. A mechanism wants an exploded view. A plan wants a timeline. And when one clear sentence is the best answer, that is what you get.

Everyday questions, made visual

Plans are easier to follow when you can see how the pieces fit. A training plan can show the weeks building toward race day, two offers can sit side by side with the trade-offs priced in, and a weekend away can show up as a route instead of a wall of text.

Text-only answer

I want to run my first 10K in about 10 weeks. I can run 3 km without stopping right now. Plan?

Ten weeks is a comfortable runway from 3 km. The rule that matters most: build slowly, with an easier week every third or fourth week.

Weekly structure: three runs. One easy, one with short faster segments, one long run.

Long run: start around 3.5 km and add up to 1 km a week, peaking near 9 km two weeks before race day.

Pace: most of your running should be conversational. If you can’t speak in full sentences, slow down.

Taper: cut back in the final two weeks so you arrive fresh. Keep a couple of short, easy runs.

Goal time: for a first 10K, finishing comfortably is the goal. Sixty to seventy minutes is a common first-time range, but run your own race.

If you want, I can turn this into a week-by-week schedule.

Interactive answer

I want to run my first 10K in about 10 weeks. I can run 3 km without stopping right now. Plan?

Ten weeks works well from 3 km. Here’s a plan that adjusts if your timeline or starting point changes. Tick off weeks as you go.

Learn hard ideas by touching them

Some ideas only click once you can change an input and watch what happens. Instead of describing a concept, an answer can hand you a small working model of it.

Help me understand the central limit theorem intuitively

Take any population, even a lopsided one. Draw a sample, average it, and write the average down. Do that many times and the averages pile up into a bell shape, getting narrower as each sample gets bigger. Try it: pick a population, set the sample size, and draw.

Build a tool just by asking

Sometimes the most useful answer is a tool you can keep using: a bill splitter for tonight’s dinner, a calculator to see how savings could grow, or a small game to play right in the conversation.

Split dinner for four. We shared the dumplings, three of us had wine, everything else was individual. 8.875% tax, add a tip. Make it look like a receipt.

How interactive answers work

Behind the idea are three pieces. A shared set of components (tables, sliders, steppers, charts, maps, checklists) gives every answer a familiar look and accessible controls. A streaming renderer lets the interface appear piece by piece while the model is still writing, the same way text does. And a model with the judgment to choose what to show, what to let you change, and when plain text is better.

The last piece is the hard one. Drawing a slider is easy; knowing whether a slider earns its place is not. Most questions should still get text. An interface is worth it when it lets you do something a paragraph can’t: compare, adjust, explore, or keep track.

This page skips the first two pieces on purpose. There is no component library and no special runtime here, only a few files of plain HTML, CSS and JavaScript that Opus 5.5 wrote in one working session after reading the original post. If a model can build these by hand, the remaining product work is making it fast, consistent and safe at scale.

Answers that start sooner

Hard questions deserve real thinking, but waiting in silence for it is a poor experience. A better pattern is to start with what is already settled (the short answer, the frame, the first steps) and keep working on the rest while you read.

Illustration. Timings are simulated, not measured.

Think, then answer

Should our team move internal services from REST to gRPC?

Answer while thinking

Should our team move internal services from REST to gRPC?

The catch is deciding what is safe to commit early. A confident first sentence that later turns out wrong is worse than a short wait, so the early parts of an answer should be the parts least likely to change.

Keeping generated UI safe

Interfaces a model writes on the fly need a tighter box than ordinary web pages. Generated UI should run sandboxed, with no access to your cookies, your accounts or the page around it, and no network access unless you allow it. Anything that acts on your behalf (sending, buying, booking) should ask for a clear confirmation, not hide behind a button in a generated form.

Honesty matters as much in an interface as in prose. A calculator should show its assumptions, a chart should label what is estimated, and a tool shouldn’t look more certain than the reasoning behind it. That is why the savings calculator states what it assumes, and the speed illustration says its timings are simulated.

This page holds itself to the same rule. It ships with a strict Content Security Policy, loads no third-party scripts or fonts, sets no cookies, and makes no network requests after it loads.

About this page

This is an unofficial concept demo, not an Anthropic announcement. It makes no claims about availability, pricing, user numbers or benchmarks. Its layout follows OpenAI’s “GPT‑6 and Intelligent UI for everyone” (October 7, 2026); all text, illustrations and interactives here are original.

Built by Claude Opus 5.5 (claude-opus-5-5) in Claude Code, running inside a deva container, with a human collaborator at thevibeworks. The source is on GitHub; the page is served from GitHub Pages.

What comes next

For decades, using a computer has meant learning someone else’s interface: where the menus are, which screen hides the setting, what the button is called.

Answers that arrive as interfaces turn that around a little. You describe what you are trying to do, and what comes back is something you can use, shaped around your numbers, your plan and your question.

The goal isn’t more UI. It is less distance between understanding something and acting on it.

More from thevibeworks

All projects

Small, sharp tools for people who live with coding agents.

Star it on GitHubthevibeworks/opus-5-5-for-everyone