By Zahi Raifer
When people imagine an AI editing a website, they picture the model "looking at" the site and rewriting it. In practice, the most important design decisions sit before the model says anything: what goes into its context, in what order, and how much it is allowed to say back. At Orivox, where small-business owners edit their sites by chatting in Hebrew or English, that context is assembled the same way on every turn. This post walks through it, piece by piece, and explains why a predictable input matters more than a clever prompt.
Every edit turn sends the planner, a Gemini model, roughly 42,000 input tokens. Measured with Gemini's own token counter, it breaks down like this:
| Part of the request | Tokens |
|---|---|
| System prompt: the editing rules | 22,893 |
| 11 tool definitions | 3,538 |
| The page, header and footer inlined (median of 15 real pages) | 16,273 (range 6,302 to 17,767) |
| Last five turns of conversation (median) | about 1,100 |
| The owner's request | about 180 |
Two things stand out. First, the owner's actual words are the smallest line in the table. Second, more than half the budget is spent on rules and tools that never change between turns. Both are deliberate.
About 26,000 tokens of every request are identical: the editing rules and the definitions of the planner's 11 tools. The rules describe how pages are structured, how to address elements, what must never be removed, and how to answer when a request is ambiguous. The tools cover the main edit call plus helpers such as reading another page, viewing a screenshot of the rendered page, extracting a palette from an image, creating a page, rewriting a page, and restoring an earlier version.
Because this block is stable, it is cached. The fixed part of each request is therefore fast and cheap, and we can afford to make the rules thorough instead of terse. A long, precise rulebook that costs almost nothing per turn beats a short prompt that leaves the model guessing.
Stability also helps debugging. When the prefix never changes, a difference in behaviour between two turns comes from the page, the history, or the request, not from a prompt that drifted.
The page goes in as raw HTML, with the shared header and footer inlined so the model sees what a visitor sees. Every element carries a short, unique data-ai-id attribute, which is how the model will refer to it later.
We did not start out sure that raw HTML was the right choice. An obvious alternative is a compact JSON summary of the page: section names, headings, text snippets, ids. We benchmarked both on real edit requests. Raw HTML gave the same understanding at about half the tokens of the summary we had built, and it had an advantage the summary could not match: the planner sees every element, class and attribute, so it never has to guess at structure that was summarised away.
The summary still exists. Very large pages switch to it automatically, so a long landing page cannot push the request past a sensible size. But for the typical small-business page, somewhere between 6,000 and 18,000 tokens, the raw markup is both cheaper and more faithful.
Only the last five turns of conversation go into the request, around 1,100 tokens at the median. The editing service keeps the full transcript; the web app sends only the latest message, so there is one authoritative copy of the conversation.
Why so little history? Because the page is the real memory. Every previous edit is already reflected in the HTML the model is reading, and every turn is a Git commit. Long chat history mostly adds stale descriptions of a page that has since changed. Five turns is enough to resolve "make it a bit darker" or "undo that last thing" without dragging old context along.
Here is the number that surprises people. Across 24 benchmark runs, the planner's output had a median of 141 tokens.
That is not a rewritten page. It is a short list of operations drawn from a 14-verb grammar: set_text, replace_html, insert_before, insert_after, append_html, prepend_html, remove, set_attr, remove_attr, add_class, remove_class, move_before, move_after and move_to_page. Each one targets an element by id, such as [data-ai-id='a0f0']. "Make the FAQ cards dark" becomes a few add_class and remove_class operations on the cards. Nothing else on the page is touched, because nothing else was mentioned.
A large input and a tiny output is the ratio we want. The model reads everything so it can decide precisely, then says as little as possible so the change is easy to check.
The model never writes files. Python receives the operation list, applies it with BeautifulSoup, and runs deterministic checks before saving: a live page may never be emptied, moved text must be preserved, the business logo and the contact form's privacy notice are protected, image addresses are re-validated, and a claim of success requires a real change. Only then is the page saved and committed to the project's Git repository.
The planner can also call helper tools before it edits, within a fixed budget of six model calls per turn. Each helper feeds its result back into the context, so a turn that needs a screenshot or another page grows slightly, but never without bound.
A few lessons from tuning this context:
The result is an editor whose behaviour is predictable turn after turn, which is what a business owner editing a live site needs most.
About the author: Zahi Raifer builds Orivox, an AI website builder and editor for small businesses, with Hebrew-first, right-to-left support and an MCP server that lets owners edit their sites from their own AI assistant.
AI disclosure: This article was drafted with the help of an AI writing assistant from Orivox's internal engineering write-up, then reviewed and edited by the author. All figures come from Orivox's own measurements.