How MaShop works

Get started

Every message runs the same loop. You describe. MaShop acts. MaShop verifies before anything reaches your repository or your live site.

You describe

Your message goes through three filters before a model reads it.

• Content. Pornographic content, illegal drugs, firearms and dark web goods are refused before any model call and before any credit is reserved.
• Services. If GitHub or Supabase is disconnected, MaShop answers with an explanation instead of generating, and charges nothing. That check runs on every turn.
• Mode. The response mode you picked decides which tools are sent. If you never opened the selector, a classifier decides for you: a question goes to Ask, a request for a plan goes to Plan, everything else goes to Build.

The same classifier picks the model when the selector is on Auto. It reads the blast radius of your request, not its length. A question or a cosmetic touch up goes to the cheapest model, a multi file feature to the middle one, a whole site to the strongest. Attaching an image overrides all of it: images always go to the one model that reads them, and that choice is remembered for your following messages.

MaShop acts

The assistant works in turns. It calls a tool, reads the result, calls another. In Build and Agent it has 29 tools, from writing a file to running a migration or attaching a domain. In Ask it has six, all read only, and the server refuses to execute a writing tool even if the model asks for one.

Three kinds of card can replace the text of an answer: a request for details, a plan, or a proposed automation. Each one ends the turn. The model does not read its own card and does not continue on its own, which is why accepting a plan sends the whole plan back as a new message, billed like any other.

MaShop verifies

A generation runs in a container, on a copy of your code. Before anything is committed, MaShop runs the real build and then type checks each application. Several checks run before the build itself, because they are cheaper there: no UI kit other than the one in the scaffold, no generic default colour palette, no error boundary importing the database.

When a check fails, MaShop opens a repair round and feeds the exact errors back. It gives itself two repair rounds at most. If the same errors come back unchanged, it stops there rather than loop on them.

If the build is still red after those rounds, nothing is committed. Your repository does not move, and the answer carries the tail of the build errors so you can read what broke. A red build never reaches your code.

Two more checks sit at the edges. Before pushing, the files are scanned for hard coded secrets and the commit is refused if any is found. After a deployment, the site is marked live only when Netlify reports the build ready and a request to the address actually answers.

What the model sees

• The last 20 messages of the current thread, never more, and never from the other thread.
• Those messages capped at 12 000 characters, whichever limit bites first. They are passed as written, never summarised.
• The files it opens itself, and your database schema if it reads it.
• The goal you pinned with /goal, re injected on every turn. That command is free and calls no model.
• On an iteration, your real code pulled back from GitHub, so your own edits win over the scaffold.
• The exact list of tools it has this turn, in read only modes, stated as exhaustive.

What the model never sees

• The other thread. Code and Automations keep separate conversation memories.
• Conversations belonging to your collaborators. Everyone sees only their own threads.
• The plan it wrote one turn ago, which is why accepting one resends it whole.
• A fifth attached image. The interface accepts five, the server accepts four, and the extra one is dropped silently.
• Images, fonts, archives and .env files from your repository. They are excluded on purpose, so a secret pushed by mistake is never exposed to the model.
• Everything past 1 200 files when your repository is pulled back for an iteration. The public site is loaded first, the back office last. Heavy manual work in the back office can therefore be invisible, and overwritten.
• Your customers, orders and products. Those live in your Supabase project, which no MaShop route reads.

Where a run stops

Limit	Value
Tool turns per message	20
Token budget per message	200 000
Server time for one generation	300 seconds
Cost of one generation	3 dollars of real cost, or what your balance can pay, whichever is lower
Messages kept in context	20, and 12 000 characters
Rate	10 messages per minute, 100 per hour
Attached images	4 accepted by the server, 5 offered by the interface
Working context lifetime	24 hours of inactivity

The cost ceiling is fixed when the run starts, at the lower of 3 dollars and what your balance can actually pay. A thin balance therefore ends a generation before the 3 dollars ever come into play. When the ceiling is reached the run is cut, and the work already finished still ships.

There is no deadline on the first word of an answer. A generating turn emits tool calls and no text for minutes at a time, so a first token timeout would kill exactly the runs that are working. It existed at 50 seconds and was removed for that reason.

What happens when nothing comes back

If the engine returns nothing, the reservation is cancelled instead of confirmed and you are told that you paid nothing. The same holds when you press Stop or close the tab: the cancellation signal reaches the provider, which stops generating and stops billing.

Past 120 turns in one conversation, a banner suggests starting a new one. It is worth following. Only the last 20 messages ever reach the model, so a long thread costs the same and remembers no more.