AI Assistant (Code Chat)

ContentBuilder includes a Code Chat panel that lets users build and edit content using AI. Users can describe what they want, ask questions, and attach a screenshot or document to work from.

Code Chat needs a server-side endpoint to talk to an AI provider. ContentBuilder.js is a client-side library and works with any server platform — examples are provided in Node.js, PHP and Next.js, and you can implement the endpoint in any language.

Requirements

An API key from one of these:

• OpenRouter – https://openrouter.ai (access to models from several providers)
• OpenAI – https://openai.com

Store your API key

Node.js / Next.js (.env):

OPENROUTER_API_KEY=YOUR_API_KEY
OPENAI_API_KEY=YOUR_API_KEY

PHP (config.php):

$OPENROUTER_API_KEY = 'YOUR_API_KEY';
$OPENAI_API_KEY = 'YOUR_API_KEY';

Configure ContentBuilder

Using OpenRouter:

const builder = new ContentBuilder({
    container: '.container',

    chatEngine: 'v2',
    chatAttachments: true,          // let users attach images, PDFs and documents

    sendCommandUrl: '/openrouter',  // your endpoint

    codeModels: [                   // models offered in Chat Settings
        { id: '~anthropic/claude-opus-latest', label: 'Claude Opus (Latest)' },
        { id: '~anthropic/claude-sonnet-latest', label: 'Claude Sonnet (Latest)' },
        { id: '~google/gemini-pro-latest', label: 'Gemini Pro (Latest)' },
        { id: '~openai/gpt-latest', label: 'GPT (Latest)' },
    ],

    defaultChatSettings: {
        codeModel: '~anthropic/claude-opus-latest',
        imageModel: 'fal-ai/nano-banana',
        imageSize: '',
    },
});

Using OpenAI:

const builder = new ContentBuilder({
    container: '.container',

    chatEngine: 'v2',
    chatAttachments: true,

    sendCommandUrl: '/sendcommand',

    codeModels: [
        { id: 'gpt-5.6-sol', label: 'GPT-5.6 Sol' },
        { id: 'gpt-5.6-terra', label: 'GPT-5.6 Terra' },
        { id: 'gpt-5.5', label: 'GPT-5.5' },
        { id: 'gpt-5.4-mini', label: 'GPT-5.4 Mini' },
    ],

    defaultChatSettings: {
        codeModel: 'gpt-5.6-terra',
        imageModel: 'fal-ai/nano-banana',
        imageSize: '',
    },
});

One model does the work, and users pick it from codeModels in Chat Settings. The first entry is also the fallback if a saved choice is no longer in the list, so put a dependable model there.

Image generation is configured separately — see AI Image Generation below.

Server-Side Implementation

Your endpoint receives requests from Code Chat and forwards them to the AI provider. Working examples for Node.js, PHP and Next.js are included in this package, pre-configured — add your API key and Code Chat works immediately.

Writing your own endpoint, or adding Code Chat to a server you already have? The code to paste is in Enabling Chat Engine v2 on your server.

What users get

• Precise edits. Asking to change one thing changes that row only — the rest of the content is left exactly as it was.
• Questions are answered in the chat, without touching the content.
• Attachments. Users can attach a screenshot to match, a photo to place, or a document to build from — see File Attachments below.
• Progress as it works — "Looking at the page", "Reading row 3", "Updating row 3" — and answers stream in as they are written.

File Attachments

Set chatAttachments: true and users can attach files to a message. It works without further configuration:

• Images on any model that reads images.
• Text files — .txt, .md, .csv, .js and similar — on every model. They are read in the browser and sent as part of the message, so they do not depend on the model accepting file uploads.
• PDFs on models that read them directly: Anthropic, Google, OpenAI and Grok.

A file type that is not offered for the selected model is refused in the browser, before any request is sent.

Choosing what a model accepts

Add accepts to a model entry to change what may be attached for it:

codeModels: [
    { id: 'vendor/some-model', label: 'Some Model', accepts: ['image'] },
],

The categories are 'image', 'pdf', 'text' and 'office'.

accepts is a policy, not a description of the model. You can allow less than a model supports — to keep users on file types you have tested, or to hold down the size of requests — and you never need to know a model's full capability to use it. Declare what you are sure of; leave it out and the defaults above apply.

To offer PDFs on a model that is not one of the four above, add 'pdf' yourself:

    { id: 'vendor/some-model', label: 'Some Model', accepts: ['image', 'text', 'pdf'] },

A model with no file input has two sensible declarations, and they mean different things:

    { id: 'vendor/text-only-model', label: 'Text Only', accepts: [] },        // no attachments at all
    { id: 'vendor/text-only-model', label: 'Text Only', accepts: ['text'] },  // text files still work

accepts: [] turns the attach button off for that model.

Office documents

Word, Excel and PowerPoint files are off by default. Turn them on with:

    convertAttachments: true,

They are then read in the browser and sent as text, which works on any model. Only the text comes through — tables, layout and images inside the document do not — which is why it is opt-in rather than the default.

An accepts you have declared still applies: a model declared as accepts: ['image'] takes images only, whether or not this option is on.

If the model reads Office files itself, declare 'office' instead of turning conversion on. The file is then sent as it is, for the model to read directly, and nothing is flattened:

    { id: 'vendor/some-model', label: 'Some Model', accepts: ['image', 'text', 'office'] },

Use conversion when you want Office files to work everywhere; declare 'office' when you know the model reads them and want the full document.

What users see

When a file is not accepted, the user is told in the chat panel:

notes.md: file type not accepted. Please attach images or PDF files instead.

The suggestion at the end names what is enabled for the model they have selected, so it changes with the model.

Already using the previous engine?

Code Chat's original engine is still there, and setting chatEngine: 'v1' (or omitting the option) keeps it. It uses two extra options that 'v2' ignores:

    systemModel: 'openai/gpt-4o-mini',   // v1 only — analyses each request
    chatModels: [ /* ... */ ],           // v1 only — model for answering questions

'v2' produces better results and costs less, and it is the engine to use for anything new. Switching needs one update to your endpoint — see the link above. Until you make that change, keep 'v1' and everything works as before; if you switch without it, Code Chat tells you so on the first message.

Canvas mode stays on 'v1'. A freeform layout has no rows for v2's row-based editing to work with, so chatEngine: 'v2' is ignored when canvas: true.