AvsB Copilot

AvsB Copilot is an AI copilot built into the visual editor. Instead of clicking through the side panel control by control, you describe the change you want in plain English (for example, "make the hero heading bolder and turn the CTA green", or "add a countdown banner above the fold") and the copilot builds it as ordinary editable changes right on the page. It matches your site's own colours, fonts, and spacing, and you keep talking to it to refine: "make it darker", "swap the second and third card". Nothing is applied automatically and nothing is a separate, locked "AI layer": every change lands in the changes list exactly as if you had made it by hand.

Open it from the sparkle button in the editor's top bar. The copilot lives in its own panel alongside the changes list and the element editor, so you can prompt, watch the change build on the page, and keep editing without leaving the workbench.

Availability

The copilot is available once your organization has billing details on file. Add them and the sparkle button is ready the first time you open the editor. There's no per-project on/off switch: access is set once at the organization level, so every project a teammate opens has the copilot ready. Nothing about your pages is ever sent to an AI provider until you actually submit a prompt (see What leaves your browser).

Without billing details on file, the sparkle button is still there, but it shows a short notice with a button that takes you to the Billing page to add them. Every other part of the visual editor works exactly the same either way.

AI actions are billed per action, at the rate shown on the Billing page, with no monthly allowance to run out and no packs to buy ahead of time. One ordinary request to the copilot, or to the Assistant in your dashboard, uses one action. A large request uses more than one, because a whole-page redesign asks far more of the model than a headline tweak. Your project's Configuration tab shows your usage so far: see Configuration → AvsB Copilot.

Every reply also has a size limit. If the copilot reaches it partway through a big build, it says so and offers Continue, so you keep what it made and pick up where it stopped rather than losing the work.

What leaves your browser

When the copilot is on, nothing is sent until you submit a prompt. When you do submit, the editor sends the following via OpenRouter (our model-routing service) to the AI model serving the request. Our OpenRouter account is configured for zero data retention: prompts and page data are not logged by the routing service and are never used to train models. What is sent:

• The real markup of the area being edited: the section you're working on, its neighbouring sections, and the site header, cleaned of scripts and trimmed to a hard size cap. Not the whole page: just enough real HTML for the copilot to build something that genuinely belongs on your site.
• The page's measured design DNA: colours, fonts, spacing, corner rounding, and shadows read from what's actually rendered on screen (so it works even when your stylesheets load from another domain), plus the exact styles of a few exemplar components (your primary button, a card, a badge) for the copilot to copy. Also the page title, address, section outline, and viewport size.
• The prompt you typed.
• The changes currently staged in the editor, so the copilot refines what you already have rather than starting from scratch.
• Any images you attached or pasted, and any markdown or long text you pasted in as context for that prompt (see Give it context).
• Screenshots of the page: a high-quality shot of the page and a close-up of the section being edited, only when you launch the editor from the browser extension. Editor sessions launched by the on-page snippet work from the real markup and measured design tokens alone, and the panel says so. During the self-check, close-ups of the copilot's own applied changes are sent back to it the same way.

Just ask: the copilot routes your request

There's no mode to pick. You type what you want, and the copilot works out what kind of request it is:

• A change to the page: an edit ("make the hero punchier", "turn the CTA green") or something new to build (a whole styled section, an interactive component). Both go down the same "make the change" path.
• A request for ideas: asking for options routes to the proposal flow, which returns up to three complete variation ideas as cards.

The decision is instant and rule-based (made on the server from the words you typed, not by another AI call), so there's no extra wait and the same prompt always routes the same way. A few examples:

• "Make the headline shorter and bolder" → a direct change.
• "Add a countdown banner above the fold" → a direct change (a new section).
• "Give me three ideas to test on this page" → variant proposals.

The first line of every reply says what the copilot decided, whether "Updating Hero directly on the page…" or "Proposing up to 3 whole-variation ideas…", so the choice is never a mystery. And if it guessed wrong, recovery is just your next message: "no, just apply that change" or "actually, give me a few ideas to choose from": it re-routes every prompt fresh. When a request could go either way, the copilot leans toward making the direct change: a staged change is easy to refine or undo, while a wall of proposal cards you didn't ask for is just noise.

Everything else (how you type, attach images, and follow up) works the same whatever the request.

It works in steps, and shows you each one

For page changes, the copilot runs as a multi-step assistant by default: it can read your page, plan, build, and check its own result inside one reply, and the chat shows each step as it happens instead of a long silent wait. When it edits the page this way, the built changes arrive as a preview you apply or reject in one tap, so bigger multi-part work never lands without your say-so.

This depends on the configured AI model being verified for multi-step work. When it is not (or an operator has turned the multi-step path off), the copilot says so in the reply and completes your request in a single pass instead: same request, same safety checks, an honest note about the difference. A request is never refused just because the multi-step path was unavailable.

Ask for a change

Type what you want and send. The copilot streams a short plan and then builds the changes right on the page: you watch the variation change in real time, and each change also appears as a card in the panel (a coloured type badge, the element it touched, and a one-line rationale). Because the copilot builds one candidate, there's no options list to wade through: if it's not what you meant, you just tell it what to adjust and it refines the same work (see Keep talking).

• One reply is one undo step. Every completed reply that changed the page carries an Undo this reply button: one tap reverts everything that reply did, together. When a reply redesigned something (a new block added, your original hidden), undoing it removes the new block and brings your original back in the same tap. Each change card is still individually removable with its revert control if you only want to drop one.
• Regenerate re-runs the last prompt and replaces only that response's changes: any manual tweaks you made in between are left alone.
• Every change is verified on the page before it turns green. After applying, the copilot checks each change actually rendered: the element exists, is visible, and has real size on screen. While that check runs you'll see a small checking… spinner on the card. A change that didn't render is automatically removed and its card turns failed with the plain-English reason ("the new block never landed on the page"), so the variation never silently keeps an invisible change. A change that rendered but may look off (say, a new section whose styling didn't take) stays applied with an amber warning explaining what to check. A green check always means "you can see this on the page".
• If the check itself can't run, the card stays honest. When the page navigates away or the connection to the editor's canvas drops before verification finishes, a change is not promoted to a confident green. Its card reads applied, but couldn't confirm it rendered in amber instead, so a green tick never claims more than was actually seen on screen.
• Honest failure, never a silent miss. When a change can't be applied cleanly (a selector that no longer resolves, a value that isn't safe, a spot on the page that moved), the card shows a dropped or failed note with the reason and a repair action, instead of failing the whole request or pretending it worked. You always get the changes that did land, and the turn's summary line reports the true count ("2 of 3 changes are live. 1 didn't render and was removed.").
• The copilot checks its own work. After a built block is applied and verified, the copilot takes a screenshot of the result and reviews it against your request (and your reference image, if you attached one): wrong colours, broken layout, or missing pieces get corrected automatically, for up to a couple of quick rounds. You'll see a quiet "Checking the result…" line while it looks. The self-check can only improve a result: if it times out or fails for any reason, you simply keep what already applied and verified. Corrections may only touch the copilot's own changes from that response, never anything else on the page, and each correction goes through the same safety filter and render verification as the original. If result screenshots aren't available (for example outside the browser extension), the check is skipped with a visible note, never silently.

Every emitted change is checked against the same validation and sanitisation as a manual save before it reaches the page, so a copilot edit is never less safe than one you typed yourself. That safety filter is loud: when it has to remove something unsafe (an inline event handler, a form that would post somewhere it shouldn't, a tag the editor doesn't allow), it keeps the change and pins a plain caption to the card naming exactly what went, like removed for safety: onclick, embed. If it meets a tag it can't keep, it unwraps that tag and keeps the words inside: "an unsupported tag was unwrapped, content kept in a plain wrapper", rather than throwing the whole block away. Only a block that safety-cleaning would reduce to literally nothing is dropped, and even then with a clear reason. You never have to wonder what the filter quietly changed.

Confirm which element

For an edit, the copilot first shows you which element it thinks you mean: it highlights the element on the page and offers three quick choices: Looks right, Pick another, or Just try it. This keeps "make the button bigger" from quietly editing the wrong button on a busy page. If you'd already selected an element before prompting, or your prompt is asking for variant ideas, this step is skipped: there's nothing ambiguous to confirm.

When you name a spot in a Build request, the copilot confirms the placement too. Ask for "add a reviews section below the pricing section" and it names the spot back to you, asking "Add it after the Pricing section?", with three choices: Yes, add it here, I meant a different section, or No thanks. If it can't match the section you named by its words, the copilot reads the page itself and places the block where you meant: it also recognises meaning, not just labels (a section showing "$29/mo" reads as pricing). Only when the spot truly can't be found does the built block's card offer Pick a spot / Add at the end. A whole-page build with no named location skips straight to building.

This works on any website's markup, not just pages built with semantic <section> elements: the copilot maps your page's visible sections (a block with a heading, a container with a naming id like #pricing) even when they're plain divs, and it matches word variants, so "the price section" finds a block labelled Pricing.

And a misplaced block is never a dead end. In the rare case a built block still can't be anchored, the work is kept and you get a "where should this go?" card: a live preview of the finished block plus one-tap ways to place it, no regeneration and no re-prompting. See Where should this go? below.

When the copilot needs to ask

Sometimes your request has a genuine fork in it: two readings that would each lead somewhere different, where guessing would just waste a turn. Instead of guessing, the copilot asks you a short question right in the chat and waits. The question comes with tappable answers: pick the one you mean and it carries straight on with that choice, no retyping. When the answer is open-ended, it leaves a plain text box instead of buttons so you can say it in your own words.

This only happens when it genuinely helps: a clear request never gets a question in the way. And because the question is just part of the conversation, you're free to ignore the buttons and reply with something else entirely; the copilot re-reads your whole message and continues.

Your page is never rewritten in place

The copilot is built so you can ask for anything, including big redesigns, without ever putting your existing page at risk. These protections are built in and always on, working invisibly on every change:

• Text and styling adjust in place. "Reword the headline" or "make the buttons rounder" edits the element right where it stands, exactly like a change you'd make by hand.
• Redesigns add a new block and hide the original. Ask it to "redesign the hero" and the copilot builds its new version as a fresh block at the same spot, then hides your original. The original is still on the page, just not visible, so Undo this reply removes the new block and brings your original back in one tap. The reply tells you this happened, so you always know both versions exist.
• Nothing of yours is ever deleted. Even "remove the banner" hides the element rather than destroying it, and only when your own words asked for a removal. If a removal looks like it landed on the wrong element (you said "remove the promo banner" but the change targeted your hero), the copilot holds it back and tells you, instead of hiding something you did not name.
• The copilot iterates freely on its own work. Blocks it built are its to rebuild: "make that section darker, with three cards instead of two" replaces its earlier block in place, without stacking hidden copies behind it.
• "Add X below Y" adds X below Y, and never touches Y. An addition only ever brings new content; everything already around it stays exactly as it was, and the reply says so when it kept something you might have expected to change.

Build anything: HTML creates, CSS styles, JavaScript behaves

Ask for something new (such as "add a testimonial band", "build a pricing table", or "add a popup that appears on exit") and the copilot writes it the way a front-end developer would: real markup for the structure, a real stylesheet for the look, and, when the ask needs behaviour, real JavaScript, then applies all of it as ordinary editable changes:

• Sections: multi-element blocks (a hero, a feature row, a testimonial band) that carry their own scoped styling and any animations they were built with, so the block looks designed rather than being a pile of default, static elements. When you name where it should go ("below the pricing section"), the section lands exactly there, not wherever the page happens to end.
• Interactive builds: popups, tab switchers, countdowns, accordions, carousels, anything that moves or reacts is built to your exact description (any fields, any count, any look) with its behaviour written as JavaScript that runs live in the editor preview immediately and ships only when you save. The code itself stays editable: open the change in the list and it appears in a real code editor. See AI-written JavaScript for the honesty checks that code goes through.

Everything lands in the changes list as ordinary edits you can tweak, reorder, or remove, and a built section is edited exactly like anything else: click any part of it on the canvas to select and hand-edit it.

You can keep iterating on what the copilot built. Follow up in chat (for example, "re-design the reviews section and make it look modern", "make the cards darker", "remove the banner") and the copilot rebuilds its own earlier block in place, without stacking hidden copies. Clicking the built block first and then prompting works the same way. This also works on elements you've tagged with your own data-avsb-target attributes.

While a section is being built you see its progress, not a blank wait: a short line steps through Reading your page → Planning → Building (counting the blocks as they land) so you always know what the copilot is doing.

Images, generated to match

When a section the copilot builds needs a picture (a hero background, a product shot, a small illustration in a feature card), you don't have to go and find one. Describe what you want in your prompt ("a hero with a photo of a sunlit workshop", "cards each with a little icon-style illustration") and the copilot marks those image slots as it builds. The pictures are then generated for you automatically and dropped into place once the section has landed: you'll see a quiet "generating imagery…" note on the card while that happens. Once a picture is ready, it also shows right there on the card in the chat, alongside the change it belongs to, so you can see the finished image without having to scroll to find it on the page.

• No made-up links. The copilot never invents an image web address that 404s. It either asks for a real generated picture, or it leaves the slot for you to fill.
• A failure is tidy, not broken, and never a dead end. If a picture can't be generated (the service is busy, or the request tripped a safety filter), the slot shows a styled placeholder block (a branded panel with a short label), never a broken-image icon, and a note explains what happened. Right on that same card you can upload your own image or paste an image URL to use instead, so a failed generation never leaves you stuck waiting or hunting through your own edits to fill the gap. The rest of the section is unaffected.
• Stand-in faces are always labelled. If a generated picture includes a person's face as a placeholder, it's marked as illustrative on the image, so a placeholder is never mistaken for a photo of a real person.
• Big sections don't stall on artwork. A few images per turn are generated straight away; any beyond that wait until you click generate this image on the slot.

A generated image is an ordinary image in the change: swap it for your own, resize it, or replace it later exactly like any other.

Your existing images and videos

When the copilot rebuilds part of your page (restyling a hero, redesigning a whole section), your existing pictures, videos, and embeds come back with it automatically. While it works, the copilot only ever sees shortened stand-ins for your media addresses; the real addresses are restored behind the scenes before the change lands. A rebuilt section shows the same photos and clips as the original, never a broken-image icon where your product shot used to be.

• Images return exactly as they were: including responsive images that load a different size for each screen.
• Embedded videos are preserved. A YouTube or Vimeo player in the section you're rebuilding stays a working player in the result.
• If something can't be restored, the card says so. In the rare case an original address can't be recovered, the change card carries a plain note telling you which media to check, and an image that fails to load on the page turns the card's check amber with the reason. A missing picture is never a silent surprise.

This is separate from generated images: reuse keeps what your page already has; generation creates something new when you ask for it.

Forms that really work

Ask for something with a form (for example, "add an email sign-up" or "put a short contact form in the footer") and the copilot builds a real, working form, not a picture of one. It's assembled from a safe, structured description (the fields and their types, the submit button, the thank-you message), so the field names and the address the form submits to are checked before anything reaches your page. That address has to be your own site (or an origin you've added to Allowed origins), so a copilot form can never quietly post your visitors' details somewhere you didn't approve.

AI-written JavaScript: staged live, flagged if it phones home

Some asks need behaviour, not just markup: "make the FAQ items expand on click", "scroll to the form when the button is pressed". When the copilot writes that JavaScript, it runs live in the editor preview immediately, so you see the behaviour working on the page rather than a promise that it will. And like every other change in the workbench, Save is the consent step: AI-written code reaches your visitors only when you save, exactly the same bar as an edit you made by hand. Undo the turn, or remove its card, and the code is gone with it.

The code stays yours to read and change. Every piece of behaviour the copilot writes appears in the changes list as its own entry. Open it and the code shows in a full code editor, right in the workbench: read it, tweak a timing, change a label, or rewrite it entirely. Your edited version runs in the preview straight away and goes through the same checks below when you save. See Editing JavaScript the copilot wrote.

Because it's real code, it's reviewed twice before it can reach your visitors:

• A fast scan reads every line. A deterministic scanner reads the code itself and finds the network calls it makes and any places where it would rewrite or remove content that was already on your page. It runs every time, and the server re-runs it on the exact code being saved. One honest boundary note: this review exists to protect you from the AI; it checks the code the copilot wrote. Your own custom code keeps its existing full-trust path, exactly as before.
• A deeper review looks for what a scan can miss. A second, smarter review reads the code the way a developer would, looking for outside addresses that are assembled or disguised rather than written out plainly, and for large-scale changes to your existing content. If this deeper review is ever unavailable, the fast scan still stands and a quiet note in the chat says the deep review didn't run: never a silent skip.

What you see depends on what the reviews find:

• Your own site: silent. Code that only talks to first-party addresses needs no extra step. First-party means your page's own domain plus the domains in your project's Allowed origins (the "my sites" list you already maintain), including their subdomains.
• Anywhere else: a review card, once. If the code reaches a third-party service, a review card appears right in the chat as soon as the code is built, naming each outside address and what the code uses it for. Acknowledge it there, or leave it: Save will ask with a single click either way (see the next section). Your answer is recorded on the variation, so you're not re-asked for the same code on every save.

Two more honesty helpers ride along with AI-written code:

• Behaviour never gets silently eaten. If the model writes its behaviour inline inside the markup (a <script> tag in the middle of a section), the editor moves that code into the reviewed behaviour channel automatically and tells you it did, so the behaviour still works and still goes through every check above instead of being stripped by the safety filter.
• Save warns you about code that will not work. When you save, the editor gives the shipping code a quick once-over and warns you in the chat, in plain English, about anything that looks broken: a lookup for an element id that does not exist on the page, or a timer or click handler written in a way that can keep running after the variation stops. These are warnings, never blocks: the save still goes through, and you decide whether to ask the copilot to fix it.

Save asks before AI-written code reaches out or rewrites your page

Most AI-written behaviour just works on your page and ships the moment you save, with no extra step. Two kinds of behaviour are worth a closer look first, so you're shown plainly before either one reaches your visitors:

• Code that connects to another website. If the AI-written JavaScript would send or fetch data from a site that isn't yours (or build a web address that can't be read ahead of time), you're shown exactly which sites are involved before it ships. Calls to your own site, and to the domains in your Allowed origins, never trigger this. It is the same review described under AI-written JavaScript.
• Code that rewrites or removes your existing content. If the AI-written JavaScript would change or take away content that was already on your page, rather than content the copilot added itself, you're shown what it would replace. Visitors in this variation would see the replacement in place of your original, so the choice stays yours. Content the copilot's own code creates never triggers this.

In the chat, this arrives as a review card the moment the code is built: the addresses or content involved, in plain English, with an acknowledge control right on the card. If you've already acknowledged it, Save just goes through. If not, the Save button shows a short inline confirm, for example "Calls apps.shopify.com. Save anyway?": one click and the save proceeds; step back instead and nothing ships. Saves made outside the chat flow keep the fuller dialog with its Save with this code, Remove the code and save, and Cancel choices. Either way your answer is remembered for that variation, so the same code is not flagged again on every save. You are asked again only when the code's behaviour changes: a new site it contacts, new content it would rewrite, or an edit you made to the code itself.

Where should this go?

Most built blocks land exactly where you asked. Once in a while the copilot builds something good but genuinely can't work out where it belongs: you didn't name a spot, or the place you named isn't on the page any more. The work is never thrown away. Instead of a dead end, you get a "where should this go?" card with:

• A live preview of the finished block, styled exactly as it will appear, so you can see what you're about to place.
• Suggested spots: up to three one-tap buttons like Above "Hero headline" or Below "Pricing", worked out from your wording and the page's own sections. Hover a suggestion and that spot lights up on the page, so you can check before you commit.
• Pick a spot: click it and then click any element on the page and choose Before · After · Inside at the start · Inside at the end, with a live preview of the slot; the already-built block drops in exactly there. The Add to the bottom of the page button is always available too.
• Add at the end: put it at the bottom of the page in a single click.
• Discard: don't want the block after all? Dismiss it for good. A discarded block stays discarded: it won't come back the next time you open the editor.

Whichever you choose, the block is placed and then verified on the page just like any other change. The card's Details still note why it couldn't be placed on its own, softened to the honest "built, but couldn't find where it goes": a missing home, never a lost block.

Unplaced blocks survive closing the editor. Reopen the same variation later and any block you haven't placed or discarded is waiting in the conversation, preview and placement buttons intact.

And Save won't quietly leave them behind. If you hit Save while unplaced blocks are still waiting, the editor stops and asks first: Review them (jump straight to the card), Discard and save, or Save without them (they stay parked in the panel for later). Cancel backs out without saving. Nothing the copilot built for you can vanish from a save without your say-so.

When a reply can't finish

The copilot tells you the truth about every ending, not only the happy one. When a turn doesn't produce what you asked, you get a plain card that says what happened and always offers a next step, never a silent, empty reply:

• Nothing came back. If the model returned no changes at all, the card says so and offers Try again. An empty turn is never dressed up as a success.
• The reply was cut off. Very long builds can hit the model's output limit part-way through. The copilot keeps every change that made it and tells you, for example "3 changes applied" followed by "the reply was cut off before it finished", with a one-tap Continue where it stopped that picks up exactly where it stopped (without repeating what's already staged), plus Regenerate to start the turn over.
• Built, but nothing could be attached. If the copilot produced changes but none could be anchored to the page, it says exactly that: "the AI produced 3 changes but none could be attached to the page", and hands you the where-should-this-go tools rather than a green tick over nothing.
• The reply ended early. If the connection drops before the copilot finishes, the card reads "the reply ended before any changes arrived, nothing was changed." with Try again, so a dropped connection is never mistaken for "done".

Design match and the match report

The copilot doesn't guess at your brand: it reads your page's real design tokens and component samples before it builds, and then a deterministic checker verifies every value it produced against those tokens. The result is shown as a match report on each reply:

• Every reply keeps its noise low: the match report lives inside the reply's collapsed Details row (together with the copilot's plan and any dropped-change reasons). Open Details to see it.
• Expanded, it breaks down token by token: a headline like "✓ Matched 12/12 tokens", values that were snapped to your nearest token (near-misses are snapped for you automatically), values that are new to your design, and any off-palette by request rows.

New colours and sizes are offered, not silently dropped. When the copilot reaches for a value that isn't one of your existing tokens (a colour or a spacing genuinely new to the page), it now keeps it and flags it instead of throwing it away. The change card shows a small pill like "2 values are new to this design", and each one carries a one-tap Snap to token that swaps it for your nearest existing brand value if you'd rather stay strictly on-palette. Keep the new value or snap it: your call, every time.

Keep talking (the follow-up loop)

Working with the copilot is a conversation, not one-shot commands. After any change (one the copilot made or one you made by hand), you keep talking: "make it darker", "swap the second and third card", "actually, undo the button change". The copilot understands what "it" refers to, and it can restyle its own earlier insertions as readily as it edits your manual work. Each change card shows where a follow-up landed ("↑ referenced" when it built on the copilot's own earlier node, "↑ your edit" when it changed something you made), so the chain of edits stays legible.

The conversation is per variation and it restores when you reopen the editor: each variation you open from the dashboard has its own thread; come back later and your history is right where you left it, including everything the copilot said, not just what it changed. The copilot also remembers the dialogue on every follow-up, so "do the same to the pricing section" works even after you close and reopen the editor: it re-reads the recent back-and-forth (your prompts and its own replies and changes), not just the page's current state.

Older conversations never get lost either. Start fresh (in the thread bar and the ⋯ menu) clears the visible chat into a brand-new thread, and the History button next to it lists every past conversation for this variation: each with its opening prompt, turn count, and date. Pick one and it loads back into the panel, ready to continue where it left off.

Compare before and after

Whenever your variation has changes, a Compare button appears in the editor's top bar (it's also in the copilot's ⋯ menu and on a completed build's card). Click it and two live copies of your page layer over each other, perfectly aligned, at the full width of whichever device type you've selected: a vertical divider with a round drag handle sweeps between them, revealing the original to the left of the line and your changes to the right. Because the two versions sit pixel-for-pixel on top of each other, differences jump out as you drag. Both layers are the real page (not screenshots) and scrolling is synced: scroll either side of the line and both layers follow, so you're always comparing the same spot.

Drag the handle with the mouse, or focus it and use the arrow keys (hold Shift for bigger steps, Home/End for all-original / all-changes); double-click the handle to recenter it. The device picker keeps working while you compare: switch between desktop, tablet, and mobile and the divider stays where you left it.

It's a look, not an edit: entering compare clears any selected element so nothing overlays the page, nothing is saved or changed while you compare, and your staged changes stay exactly as they were. Links and buttons inside the original layer are disabled so a stray click can't knock the two versions out of step. Leave compare with Exit compare (top bar or the banner), the Escape key, or just by typing your next prompt, then keep editing.

Whole-variant proposals

When you want the copilot to think bigger (several complete takes on a section or page rather than one edit), just ask for ideas: "give me three ideas to test on this page", "propose a few versions of the hero". This is the one place the copilot returns more than a single candidate: it proposes up to three complete variation ideas, each as its own card with a name, a short rationale, a summary of what it would change (for example "3 style, 1 text"), and its own match report.

Each card gives you two choices:

• Apply to this variation: stage the proposal's changes onto the variation you're editing right now. They land as normal changes you can tweak or remove, and count as a single undo step.
• Create as new variation: save the proposal as a brand-new variation of the experiment without touching the one you're on. A toast confirms the new variation by name; open it from the dashboard's Variations step when you're ready to work on it; your current session stays on the variation you're editing.

Give it context: images and text

You can hand the copilot more than a sentence. Right in the composer you can:

• Attach or paste images: a rough sketch, a competitor's screenshot, a mockup. Add up to three (JPEG, PNG, or WebP, up to 1.5 MB each); anything else is turned away with a short note. The size cap keeps requests fast and affordable: if a screenshot is over it, resizing it smaller or saving it as JPEG almost always brings it under.
• Paste markdown or long text: a content brief, product copy, a spec. Pasted long text drops in as a context block you can expand to review; if it's very long it's trimmed to fit with a "Trimmed to fit" tag, and a notice shows if you go over the total limit.

Every image is sent to the model with an explicit label saying what it is: your attachments are marked as the reference to replicate: "match this layout and structure, restyled with this site's own colours and fonts", so a reference is treated as the brief, never as decoration. Ask to copy the reference's colours if that's what you want instead.

While an attachment is still uploading, Send waits: the composer shows "Waiting for image upload…" and enables the moment the upload finishes, so a reference can never be silently left out of a prompt.

Your reference image stays on your message. Once you send, the attached image doesn't disappear back into the composer: it stays visible right on your message in the chat, so scrolling back through the conversation always shows exactly what each request was based on.

The copilot uses everything you attach, alongside the page, to build exactly what you meant. Attachments and context are for that one prompt and are cleared once you submit.

Daily budget

Two limits stop a runaway prompt loop from running up a bill, and they work alongside the per-action billing described in Availability above.

Every organization has a daily spending limit in real dollars: $5 a day by default, and support can raise or lower it for your organization. It is separate from what you are billed per action, and resets at midnight UTC. If your organization reaches it, the copilot pauses with a clear message ("Your organization reached its daily AI spending limit. The limit resets at midnight UTC.") and the reset time, and the rest of the editor keeps working normally.

Requests are also rate-limited per user, 10 a minute by default, so usage stays predictable minute to minute.

Provider-agnostic by design

The copilot runs through the same shared, provider-agnostic AI layer as the rest of the editor's AI. The model vendor and model are a configuration choice on the server, not wired into the product, so the underlying providers can be switched or mixed as price and quality change with no effect on how the copilot works for you. Routing between models is instant and rule-based: proposals, anything with an attachment or pasted context, and structural prompts run on the stronger build model; only a quick wording tweak on an element you've picked stays on the fast, cheap one. Requests are made server-side; your API keys are never exposed to the browser.

The output format adapts to the model the same way: where the served model verifiably supports enforced structured output, the server switches it on so responses arrive format-guaranteed; where it doesn't (or a provider unexpectedly rejects the request), the copilot automatically falls back to its tolerant parsing path in the same run. A model switch can change response quality, never turn into a broken run.

The server also verifies the configured models at startup: each one gets a tiny health check (cached for an hour, reported at GET /api/health/ai). If a configured model id turns out to be unavailable or misconfigured, the copilot says so immediately when you send (before generating) instead of failing halfway through a response.

The copilot works inside your editing session: your lock, your presence, your audit identity. A copilot edit is recorded the same way a manual edit is; the "made by AI" marker on a change is for your own reference, not a separate actor.

Related

• Ideas & explain: get test ideas for the current page, and explain any change in plain English.
• Match brand from screenshot: image-based colour and font suggestions for the selected element.
• Selectors: how resilient selector chains keep copilot edits anchored to the right element.
• Configuration → AvsB Copilot: whether the copilot is available, and this month's AI actions.