TLDR
Commander deck A B testing proxies works best when you compare one small card package against a fixed baseline. Give the package one job, keep the commander and the rest of the deck unchanged, alternate between Versions A and B, and record whether the cards actually performed that job. Do not crown a winner from one explosive game. End with a written keep, cut, or retest decision.
The point of Commander deck A B testing proxies is not to make Commander behave like a laboratory experiment. Multiplayer games are too political, variable, and pod-dependent for that. The point is to stop making ten changes at once and then guessing which change helped. A controlled test gives you directional evidence you can use before buying cards or committing to a polished proxy revision.
What A/B testing means in a Commander deck
Version A is your baseline deck. Version B is the same deck with one defined package changed. That package might contain four removal spells, six lands, eight token payoffs, or ten cards from the top end of the mana curve. Everything outside that package stays fixed.
That fixed shell matters even more in Commander because the format generally uses a commander plus 99 cards, follows color identity, and permits only one copy of each nonbasic card. Those singleton rules already create substantial draw variance. The official Commander format page provides the current deck-construction and format guidance.
This is deck testing, not a comparison of printing services and not a test of whether one card stock feels nicer. During the first stage, a basic paper insert in an opaque sleeve is enough. If Version B survives testing, you can turn the final list into a more cohesive set through custom MTG proxy printing rather than polishing ten speculative cards before you know whether they belong.
Start with one narrow question
A useful test begins with a sentence you can answer. “Make the deck better” is too vague. “Give this three-color deck reliable access to all three colors by the early turns without adding more tapped lands” is testable. So is “Increase the number of useful token payoffs without making the deck helpless after a board wipe.”
Write the question before selecting cards. Then define what improvement should look like when you play. Depending on the package, you might watch for fewer color problems, fewer stranded reactive cards, smoother early development, stronger recovery after disruption, or more chances to advance the commander’s plan.
Wins can be recorded, but they should not be the only verdict. You can lose after Version B fixes your mana perfectly, and you can win after keeping a terrible hand because another player became the table’s immediate problem. The better question is whether the changed package repeatedly did its assigned job.
A good test statement
Use this format: “I am replacing these specific cards because I expect the new package to improve this observable part of the deck without causing this unacceptable downside.”
For example: “I am replacing six lands to improve early access to blue and black without increasing the number of lands that routinely enter tapped.” That gives you a job, a package, and a failure condition.
Build Version A and Version B
Keep the package between roughly four and ten cards. That is an editorial rule of thumb, not a mathematical threshold. A smaller package is easier to interpret, while a ten-card package can be appropriate when the cards depend on one another. A reanimation package, for example, may need discard outlets, targets, and reanimation effects to function as a unit.
- Export or photograph the current list and label it Version A.
- Choose the single problem the test is meant to address.
- Mark the cards leaving Version A with matching numbers from A1 to A10.
- Mark their Version B replacements from B1 to B10.
- Keep the commander, unaffected mana sources, ramp, interaction, and finishers unchanged.
- Set a checkpoint for reviewing the notes rather than changing cards after every game.
Avoid testing a new commander, mana base, ramp suite, and finisher package together. If that version starts faster but folds to interaction, you will not know which change caused either result. You have built a different deck, not a useful comparison.
Make the playtest cards easy to use
A test card should communicate its name, mana cost, card type, core rules text, power and toughness when applicable, and any information needed to make decisions. It should also be clearly identifiable as a playtest card. Decorative treatments can wait until the card earns a permanent slot.
Put every test card in the same opaque sleeves as the rest of the deck. The back and thickness should not reveal whether the next draw is from Version A or B. If an ordinary paper insert feels thinner, place it in front of a spare card so the sleeve handles consistently.
Prepare any associated tokens, counters, or double-faced references before the game. A token payoff cannot be evaluated fairly if you spend every trigger looking for scraps of paper. If you test over webcam, readability becomes even more important; the same practical standards covered in making MTG proxies readable on SpellTable apply here.
Personal testing and sanctioned play are different
Wizards has distinguished personal, non-commercial playtest cards from counterfeit reproductions in its published policy discussion. That distinction is not blanket permission to bring player-made proxies into sanctioned competition. The supplied Magic Tournament Rules state that players may not create their own proxies for sanctioned tournaments, while judge-issued proxies are allowed only in limited authorized circumstances. Read the current Magic Tournament Rules before relying on a playtest card at an event.
For casual Commander, ask the organizer or playgroup what they allow. A regular kitchen-table group, an unsanctioned Commander night, and a sanctioned tournament can have different expectations.
Use a two-stage testing process
Stage one: screen opening hands and early turns
Start with solo draws for both versions. Take sample opening hands, make normal mulligan decisions, and play through the first several turns as though opponents could interact. This catches basic construction problems quickly: missing colors, overloaded mana values, awkward tapped-land sequences, or cards that demand resources the deck cannot reliably produce.
Goldfishing does not tell you whether an answer will match the threats in your pod. It does tell you whether the deck can cast its spells and sequence its setup. Community playtesting discussions similarly treat solo testing as useful for early mana and sequencing checks, while games against a regular group expose interaction and metagame concerns. That experience is anecdotal, but the division of labor is sensible.
If Version B clearly fails this basic screen, fix the package before taking it to a pod. There is little value in spending an evening confirming that your three-color deck cannot cast its spells.
Stage two: alternate real games
Once both versions function, alternate them in real games where practical: A, B, A, B. Use the same regular pod when possible, but do not pretend the games are identical. Note meaningful changes in opponents, deck strength, seating, and game texture.
A six-game checkpoint—three games with each version—is a reasonable way to force yourself to stop and review, but it is only a practical heuristic. It is not enough to prove that one version is statistically superior. If the package was barely drawn or two games ended unusually early, the honest verdict may be “retest.”
Track evidence that explains the result
| What to record | Question to answer | Why it matters |
|---|---|---|
| Mulligan | Did the package contribute to keeps or force more mulligans? | Opening-hand quality affects whether the deck gets to play its intended game. |
| Early development | Could you cast setup spells and access the colors you needed? | A package that creates early stumbles may erase its later upside. |
| Cards stranded | Were test cards stuck in hand because of cost, timing, or missing support? | Repeatedly uncastable cards expose structural problems. |
| Meaningful impact | When drawn, did the package advance its assigned job? | This is more informative than whether the card merely resolved. |
| Recovery | Did the package help after removal, a board wipe, or a failed push? | Commander decks need to function after opponents participate. |
| Threat response | Did the package attract substantially different attention from the table? | Perceived threat can change how a deck plays even before it wins. |
| Enjoyment | Did the new lines create better decisions or tedious repetition? | A technically stronger package can still be wrong for your deck or group. |
| Game result | Did you win, lose, or draw? | Useful context, but too noisy to serve as the sole verdict. |
Keep notes short enough that you will actually write them. “B3 fixed black on turn three; B5 entered tapped and delayed interaction” is more useful than a paragraph recounting the entire game. Also record when a test card never appeared. Absence is not evidence that the card failed.
Worked example: testing six lands
Suppose a three-color Commander deck regularly has green mana but struggles to produce blue and black at the right time. Version A is the current list. Version B swaps six lands while leaving the other 93 cards and the commander unchanged.
Before playing, define success: Version B should produce the required colors earlier while avoiding a noticeable increase in forced tapped-land turns. Then track opening colors, mulligans caused by mana, turns when a spell was stranded, and whether the revised lands interfered with utility-land synergies.
Do not also replace the deck’s signets, lower the curve, and add three draw spells during this test. Those may be good changes, but they would make the result muddy. If the land package wins, you can test the ramp package next. For ideas about which land categories may address a specific bottleneck, see the guide to upgrading lands in Commander.
After the checkpoint, Version B might show cleaner color access but too many tapped openings. That is not necessarily a full rejection. It could mean keeping four of the six changes and retesting the two weakest slots. A/B testing should sharpen the next decision, not force an all-or-nothing answer when the evidence points to a hybrid.
Account for Commander’s noisy variables
Commander results are shaped by pod composition, threat perception, politics, unusual draws, and which player happens to have an answer. A package can also change how opponents evaluate your deck. Adding efficient tutors or explosive mana may make the list function more consistently while pushing it away from the experience your group expected.
Wizards presents Commander brackets as optional matchmaking guidance, and the supplied official material describes the framework as beta. If your revision changes the deck’s speed, consistency, or social profile, revisit the pregame conversation rather than treating improved performance as the only goal. The site’s guide to proxies and Commander brackets offers more context for matching a build to the intended table.
Treat a small set of games as directional evidence, not proof. If Version B only looked strong because one opponent missed land drops, note that. If Version A faced graveyard hate in every game while Version B did not, note that too. You cannot remove every confounder, but you can avoid lying to yourself about them.
Make a keep, cut, or retest decision
At the checkpoint, return to the original test statement and choose one of three outcomes.
- Keep: Version B repeatedly improved the intended job, did not introduce an unacceptable downside, and still fits the table where the deck will be played.
- Cut: Version B failed its assigned job, created a worse recurring problem, or made the deck less enjoyable for its intended games.
- Retest: The package barely appeared, the games were unusually lopsided, outside variables dominated the results, or the notes suggest a smaller hybrid package.
Write one sentence explaining the decision. For example: “Keep four of the six B lands because they improved blue access; cut the two tapped options and retest those slots.” That sentence becomes the starting point for the next revision and stops you from repeating the same experiment three months later.
The practical next step
Choose one frustration from your last few Commander games and turn it into a narrow test question. Build a four-to-ten-card Version B package, label the replacements, run the opening-hand screen, and schedule an alternating set of pod games. Change nothing else until the checkpoint.
The best result is not always Version B winning more games. It is reaching a defensible decision about why those cards belong—or do not belong—in this specific deck. Keep the package only when it performs its intended job repeatedly enough to justify another round of play and still produces the kind of Commander game your table wants.