Execution modes
One account per item or several at once, what happens after a payment is refused, the four separate pools that decide which accounts each kind of purchase may use, and how one folder can run more cautiously than the rest of your workspace.
Settings → Purchase Preferences → Execution. Everything on this page saves as you change it.
The two modes
Sequential
One purchase attempt per product, using a single account from the rotation queue.
The account chosen is the least recently used one that is eligible, and where two are equally idle, the one with fewer failures behind it. One attempt is fired. If it fails, the item is not retried with another account — Kops moves on.
Rotation is fair by construction: each fire takes the next account in line, so no account carries the whole load over time.
Parallel
Several purchase attempts at once, with different accounts.
You set how many — between 1 and 10, default 2. The field only appears once you have picked this mode. If you have five eligible accounts and you set three, three of them race the same item and the first payment to complete wins it.
That is the whole argument for parallel, and it is not speed: each account is a separate ticket in the same race. Two accounts is roughly two chances at the item, not one attempt that runs faster.
Choosing between them
Sequential is right when
- you have one or two accounts,
- your filters are on low-competition items,
- you want the calmest possible footprint per account,
- you would rather lose an item than spend three accounts on it.
Parallel is right when
- you have several genuinely independent accounts,
- your filters are on items that sell within seconds,
- you have set a real ceiling, so a lost race costs you nothing,
- one account's failure should not decide the item.
Parallel needs accounts that do not look alike. Accounts Vinted can link to each other are not separate tickets — see Creating a Vinted account safely. Racing six linked accounts is worse than racing one clean one.
Payment failover
A switch of its own, off by default, marked Beta, and it applies to both modes — a sequential winner can die at payment too.
The case it covers is the specific one where you won the race and lost the item anyway: the winning attempt reached payment and payment was refused — blocked or declined. Without failover that is the end of the attempt, and the item goes back on sale for somebody else.
With failover on, Kops immediately retries the same item with other accounts, one after another, excluding every account that already failed on it.
Turning the switch on reveals two things:
| Control | Range | What it does |
|---|---|---|
| Failover accounts | 0–10, seeded at 2 | How many accounts the retry chain may spend |
| Failover groups | any account groups | Which accounts it may spend them on. Only shown once the count is above zero |
Failover groups narrow the retry chain. Leave it empty and the retries obey whatever restriction the original purchase obeyed. Set it and only those groups retry — useful when you keep a couple of accounts specifically as a safety net.
The number is a budget, not a second switch, but a budget of zero buys nothing. Set it to 0 with the feature switched on and the hint under the field says so in as many words — Failover is off — a payment failure ends the attempt.
You will not land there by accident: turning the switch on with no budget seeds it at 2 precisely so that "on" works out of the box. It is reachable only by typing 0 yourself, which is a slower way of switching the feature off.
Failover retries appear on the Attempts page with a Failover retry badge, they can be filtered on alone, and each one names the attempt it is retrying.
The four account pools
Four different kinds of purchase can each be restricted to their own account groups, and they are separate on purpose: the accounts you want a bot rotating through are not always the accounts you want speaking to a seller under your name.
| Pool | Where | Restricts |
|---|---|---|
| Manual Purchase Groups | Manual purchases | Buying, starting a conversation or making an offer by hand |
| Failover groups | Execution → Payment Failover | The retry chain above |
| Pre-order groups | Pre-orders | Pre-order purchases — see Pre-orders |
| Auto-offers | Auto-offers | Which accounts send automatic offers |
Every one of them means the same thing when empty: no restriction, the whole eligible pool. None of them can widen the pool — an account still has to be ready and in the seller's zone.
Autocop itself has no pool on this screen. Its restriction comes from the folder the filter lives in, through that folder's account group — see Account groups.
Quarantine on manual purchases sits in the same section as the first of them. It decides whether a failed manual purchase counts toward that account's cooldown, the same way an automatic one does — the same seven errors, the same tally, and the same three in a row for the fraud-detection pair. See What counts, and how many. On by default. It is subordinate to automatic quarantine: with that master switch off, nothing quarantines anything, from any source, and this row greys out and says so.
Overriding it for one folder
A folder can run its own execution settings, so one niche can be cautious while the rest of the workspace is aggressive. Open the folder's menu and pick its autocop preferences.
A folder may narrow exactly three things:
- the mode — sequential or parallel,
- the number of parallel accounts, which only appears once you pick parallel,
- the failover accounts count, which appears either way.
Each is inherited until you override it, and each says so in its own way: the mode you fall back to carries a Global default tag, and a number field carries Global: … underneath. Only the fields you actually changed are stored, so a field you set back to its inherited value simply stops being an override.
Unlike the settings tab, this window does not save as you type — it has a Save Changes button, and Reset to global defaults appears beside it only once the folder actually has an override to clear.
A folder can set a failover budget but cannot switch failover on. That switch is workspace-wide. A folder that raises the count while the switch is off has changed a number nothing reads.
Global autocop and automatic quarantine are not overridable per folder.
The first because the folder already has its own on/off switch, and a second master switch inside a subordinate scope is how an emergency stop stops being one. The second because quarantine is about account health, which is workspace-wide — a folder that could disable it would be disabling it for accounts it shares with every other folder.
The two repost settings and the four account pools are workspace-wide for the same reason: the repost guard is about a seller and a listing, not about which folder happened to match first, and a pool is about which accounts may act at all.
Both modes obey the same limits
Whichever mode you run, an attempt still needs an account that is ready, in the seller's zone, and inside whatever group applies to that kind of purchase. Parallel with three accounts and only one of them eligible is sequential with extra steps.
The rest of this screen belongs to other pages: Safety (quarantine and repost protection) is covered in Autocop, and the Preferences block at the bottom — which account the inbox picks for you, how much of a running purchase you want to watch, and the four messages to sellers — is not about execution at all.
See Cop Faster for which of these levers is actually worth your afternoon.