What Is Thesys C1? A Generative UI API

// In plain English

Most AI features today end the same way: the model returns a wall of text, and your app prints it in a chat bubble. That works for a quick answer, but it falls apart the moment the right response is something interactive — a comparison table, a form to confirm a booking, a chart, a set of clickable options, or a card with a button. A paragraph can describe a flight, but it can't be a Select flight button you tap.

Thesys C1 is a commercial, hosted platform that tackles exactly this gap. It exposes an API that looks almost identical to a normal chat completion call — you send messages, you get a response — except the response is not plain text. It is a description of an interactive user interface: which components to show, what they contain, and how they behave. Your app receives that description and renders real, clickable UI. This idea has a name: generative UI.

Think of the difference between ordering at a counter by shouting your whole order versus being handed a menu with checkboxes. Plain-text AI shouts the answer at you. Generative UI hands you the menu — the structure that lets you act, not just read. Thesys C1 is the kitchen that produces that menu on demand, turning each model response into a small, purpose-built screen.

// Why it matters

Generative UI matters because the gap between what a model knows and what a user can do with it is mostly a UI problem. A model can decide that a user needs to pick a date, compare three plans, or approve a payment — but a text response can only talk about those actions. Someone still has to build the date picker, the comparison table, and the approval dialog, and wire the model's intent to them by hand.

Traditionally a developer hard-codes every screen. You anticipate each case — "if the user asks to compare plans, show the PlansTable component" — and write routing logic, prompt parsing, and rendering for all of it. That is slow, brittle, and explodes combinatorially as your product grows. An API that returns the UI flips the work: the model chooses the right interface for the moment, and your app just renders whatever it's told.

• Less bespoke front-end work. You stop writing a custom component-and-routing path for every possible answer shape. The platform emits a layout; you render it.
• Interfaces that fit the answer. A question about numbers can come back as a table or chart; a task can come back as a form or buttons — instead of every answer being forced into a paragraph.
• Actions, not just words. Because the response includes interactive elements, users can click, fill, and confirm inside the AI conversation rather than being told to go do something elsewhere.
• A familiar integration shape. The endpoint is OpenAI-compatible, so teams that already call a chat-completions API can adopt it without learning a brand-new request format.

Who cares? Anyone building an AI app where the best response is do-able, not just readable — internal tools, customer-facing assistants, data dashboards, booking and checkout flows. If you find yourself writing endless if intent == X then render component Y glue, generative UI is the pattern aimed straight at that pain. For the broader design principles, see generative UI patterns.

// How it works

The core idea is a swap at one step of a normal chat pipeline. In an ordinary LLM app, the model returns text and you display it. With a generative-UI API like C1, the model returns a UI specification — a structured description of components — and you hand that to a renderer that turns it into a live interface.

Step 1 — you call it like a chat completion

Your back end sends a request shaped like a standard chat-completions call: a list of messages, optionally some context or tools. Because the endpoint is OpenAI-compatible, you can often point an existing OpenAI client library at C1's base URL and reuse the same request structure. The mental model on the calling side barely changes — what changes is the shape of the answer.

Step 2 — it returns a UI specification, not prose

Instead of a paragraph, the response carries a structured payload describing an interface: a heading here, a table of rows there, a couple of buttons with labels and actions. Conceptually it is a tree of components and props — the same way a front-end framework thinks about a screen — serialized so it can travel over the wire. The model is, in effect, designing the answer, not just writing it.

Step 3 — your app renders the spec

On the client, a renderer (Thesys provides front-end SDK pieces for this) walks that specification and produces real, styled, interactive components. When the user clicks a button or submits a form, that interaction becomes the next message you send back to the API — so the conversation continues, each turn producing a fresh interface tuned to the new state.

// A mental model of the flow

It helps to see the consuming side as ordinary application code. You are not parsing free text and guessing intent — you receive a structured response and render it. The sketch below is illustrative pseudocode for the shape of the integration, not a copy-paste SDK call; treat it as the mental model.

// 1) Call the C1 endpoint like a chat completion.
//    OpenAI-compatible: same client shape, different base URL.
const client = new OpenAI({
  baseURL: THESYS_C1_BASE_URL,   // the hosted C1 endpoint
  apiKey: process.env.C1_API_KEY,
});

const response = await client.chat.completions.create({
  model: "c1-generative-ui",
  messages: conversation,        // your running message history
});

// 2) The response carries a UI SPECIFICATION, not just prose.
//    Hand it to the C1 renderer instead of printing a string.
const uiSpec = response.choices[0].message;

// 3) Render the spec into real, interactive components.
//    User clicks/inputs become the NEXT message you send back.
renderGenerativeUI(uiSpec, {
  onAction: (action) => {
    conversation.push(action.asMessage());
    // ...loop: call the API again with the updated conversation
  },
});

The loop is the important part. Each user action feeds back as a message, the API answers with a new interface, and the app re-renders. That turns a one-shot "answer" into a small, stateful app that the model drives turn by turn — close in spirit to a chatbot UX where every reply can be a different kind of widget.

// Where it fits — and where it doesn't

Generative UI is a strong fit for some apps and overkill for others. The deciding question is simple: does the right answer need to be interactive? If users mostly read, plain text or markdown is fine. If users need to choose, compare, fill, or confirm, generated UI earns its keep.

It also pairs naturally with human-in-the-loop UX: when an AI wants to take an action with real consequences, returning an explicit confirm/cancel control is far safer than asking the user to reply "yes" in free text, which is ambiguous and easy to fake or misparse.

C1 vs. in-app component toolkits

C1 is not the only way to do generative UI. Open-source toolkits (the kind that live inside your own front-end codebase) let your code map model outputs or tool calls to React components you wrote and ship. The honest trade-off is hosting and ownership, not capability.

// Common pitfalls

• Assuming it's open-source. C1 is a hosted, commercial platform with no public repository. If your requirements demand self-hosting or auditing the source, evaluate an in-app toolkit instead.
• Treating generated UI as trusted by default. The interface is produced from model output. Any action a button triggers — a payment, a delete, an email — must still be validated and authorized on your server, exactly as you would for any client request. Never let a generated button bypass your normal permission checks.
• Over-applying it. Not every answer needs a widget. Forcing a form onto a question that only needed one sentence adds latency and friction. Reserve generative UI for genuinely interactive moments.
• Ignoring latency. Generating a richer response can take longer than emitting a token stream. Plan for latency-aware design — loading states, skeletons, and progressive rendering — so the wait feels intentional, not broken.
• Vendor coupling. Because the rendering and the spec format are tied to the platform, switching providers later is a real migration. Weigh that lock-in against the time it saves you up front.

// Going deeper

Once the basic request-render loop clicks, the interesting questions are about control and trust. Generative UI hands a slice of your interface design to a model, and the engineering challenge is keeping that powerful but bounded.

Constraining the component vocabulary. A practical system limits the model to a known set of components and props rather than letting it emit arbitrary markup. This keeps results on-brand, accessible, and safe, and it mirrors how this whole encyclopedia is built — a fixed block vocabulary the author fills in, not freeform HTML. The narrower the palette, the more predictable the output.

State and the conversation loop. Because each user interaction becomes the next message, you need a clear story for state: what gets sent back, how much history you keep, and how you avoid re-rendering work the user already completed. This connects to broader patterns like optimistic UI, where you update the screen before the server confirms to keep things feeling instant.

Grounding and citations. When generated UI presents facts — a table of prices, a summary card — the same honesty rules apply as anywhere else: show where the data came from. Pairing generative UI with source and citation UX keeps a slick interface from quietly laundering an unverified claim into something that looks authoritative.

Where to go next. Generative UI is one expression of a bigger shift: AI products that act through interfaces rather than only talk. Start from the foundations of what makes good AI UX, study the reusable generative UI patterns, and then decide between a hosted API like C1 and an in-app toolkit based on how much control, hosting independence, and customization your product truly needs.