Commander is the only format where a simple spell can trigger a four-person “response chain,” a side conversation about snacks, and a philosophical debate about whether you’re allowed to be happy.
And the reason it gets messy isn’t because the rules are unclear. It’s because multiplayer priority is polite, orderly… and absolutely relentless. Priority doesn’t “go to whoever shouts ‘IN RESPONSE’ the loudest.” It goes in turn order, every time, forever, until everyone passes.
This is the practical guide to multiplayer priority: APNAP, how priority actually moves in a 4-player game, why “holding priority” matters, and how to avoid the classic Commander moment where someone tries to respond from two seats away like they’re cutting in line at Costco.
And the “stop arguing, start phrasing” companion:
The one rule that explains 80% of Commander timing
In multiplayer, priority passes to the next player in turn order when someone passes. That’s it. That’s the engine. It’s not “active player vs one opponent.” It’s active player vs everyone, one at a time.
So if the turn order is:
A (active) → B → C → D → back to A
then priority moves exactly like that: A, then B, then C, then D, then A again.
And here’s the important part: a spell/ability doesn’t resolve until all players pass in succession.
Which means in a 4-player game, the stack needs four consecutive passes before anything resolves.
That’s why Commander takes forever. The rules are doing cardio.
APNAP, translated into human language
You’ll hear judges and rules nerds say APNAP: Active Player, Non-Active Player order.
In Commander, “NAP” is not one player. It’s each other player in turn order.
So APNAP means:
- The active player (the person whose turn it is) goes first,
- then each other player goes in turn order.
This shows up in two big places:
- Priority passing
- Trigger ordering when multiple players have triggers
Multiplayer priority: what actually happens when someone casts a spell
Let’s do the most Commander thing imaginable:
Player A casts a big spell. Everyone suddenly has opinions.
Here’s the exact flow:
1) A casts a spell
The spell goes on the stack.
2) A gets priority again (yes, immediately)
This is the part a lot of people miss. After you cast a spell while you had priority, you receive priority again. This is why “holding priority” is a real thing.
3) A passes (or does more stuff)
If A passes, priority goes to B.
4) B gets priority
B can respond or pass. If B passes, it goes to C, then D.
5) If D passes, priority returns to A
Now A has a choice:
- Pass (and if everyone has passed in a row, the top thing resolves)
- Act (add something to the stack, and now everyone has to pass again)
This is the core truth of multiplayer stack wars:
Nobody gets to “skip” the line.
You get your chance when priority reaches you.
“Can I respond before blockers?” but for Commander
Here’s the Commander version of the classic timing question:
“Can I respond to that before anyone else does?”
Sometimes: yes, if you hold priority.
Holding priority (why it matters)
Because you get priority after casting your own spell, you can do this:
- Cast Spell 1
- Hold priority
- Cast Spell 2 / activate ability
- Then pass
This is how players set up sequences without giving the table a window between the pieces.
If you don’t explicitly retain priority, most tables (and tournament shortcut assumptions) will treat you as having passed after you add something to the stack. In Commander, that’s basically inviting three people to interrupt your combo while you’re still explaining it.
Practical phrasing:
- “Cast X, retain priority, cast Y.”
- “Activate this, hold priority, activate again.”
Short, clear, and it prevents the “wait, I thought I could respond in the middle” drama.
Who gets the “last chance” before something resolves?
In a 4-player pod, people love saying things like:
“Seat D always gets the last word.”
That’s… not exactly right. Here’s the real answer:
- The last player to act is whoever adds the final object to the stack before everyone passes.
- The last player to be asked before a spell resolves is typically the active player, because priority comes back to the active player after the last non-active player passes.
So if the stack is sitting there and D says “pass,” priority returns to A. If A also passes, then the top object resolves.
Meaning: the active player often has the final “do I let this resolve?” checkpoint.
But that doesn’t mean the active player gets to override responses. It means the active player has the final opportunity to add something before resolution happens.
Trigger order in multiplayer: why your upkeep triggers feel “backwards”
Now let’s talk about the other APNAP headache: trigger placement.
When multiple triggered abilities have triggered since the last time a player got priority, they’re put on the stack in APNAP order. Each player orders their own triggers, but the players add them in turn order.
The weird consequence
Triggers placed later go on top of the stack… and resolve first.
So on Player A’s turn, if several “at the beginning of upkeep” triggers happen for multiple players:
- A puts their triggers on the stack (in any order they choose)
- B puts their triggers on top
- C puts their triggers on top of that
- D puts theirs on top
And because the stack resolves top-first, D’s triggers resolve first, then C’s, then B’s, then A’s.
That’s why in Commander it can feel like “the active player’s triggers resolve last.” Often, they do.
DraftSim-style takeaway
If you’re trying to plan around a trigger war, remember:
Active player stacks first, but resolves last.
Priority loops: why one response turns into three more
Here’s why interaction feels endless in Commander:
- Someone puts something on the stack
- Priority goes around the table
- Someone responds
- Priority goes around the table again
- Another response happens
- Repeat until everyone runs out of mana, patience, or social grace
Also: after any spell or ability resolves, the active player gets priority again. That means on the active player’s turn, after something resolves, they’re first to continue the action.
This is why the active player often “drives” the game forward, even when the table is fighting on the stack.
The most common multiplayer priority mistakes
Mistake #1: “I respond!” from the wrong seat
If B has priority and casts something, C does not get to respond until B passes (or finishes holding priority). And D definitely doesn’t get to jump ahead of C.
If your pod is casual, people do this out of habit. If your pod is competitive, they do it to pressure you. Either way, it’s cleaner to just enforce: turn order priority.
Mistake #2: Assuming “pass” means “pass around the table”
In 1v1, “pass” is basically “okay, you.” In Commander, “pass” might mean:
- “I pass priority to the next player,” or
- “I’m passing on this whole stack, don’t ask me again,” or
- “I have no responses, can we move on,” which is emotionally understandable
If you want clarity, use:
- “Pass to you” (to the next player)
- “No response” (for this object)
- “I’m passing priority for the rest of this stack” (if your table accepts that shortcut)
Mistake #3: Not tracking whose turn order matters
In Commander, seat position is power. Not because of politics (okay, also politics), but because priority order changes who gets to act when.
If you routinely forget turn order, you’ll mis-sequence responses and get confused about why something resolved “too early.”
A clean Commander stack example (that won’t melt your brain)
Turn order: A → B → C → D
A casts Board Wipe. Here’s the stack dance:
- A casts Board Wipe (stack: Board Wipe)
- A passes
- B casts Counterspell targeting Board Wipe (stack: Counterspell, Board Wipe)
- B passes
- C casts Counterspell targeting Counterspell (stack: Counterspell₂, Counterspell, Board Wipe)
- C passes
- D passes
- A responds with a protection spell (stack: Protection, Counterspell₂, Counterspell, Board Wipe)
- A passes
- B passes
- C passes
- D passes
→ Top resolves (Protection), then priority returns to A, and the loop continues
Notice the pattern: every time something is added, everyone gets asked again.
Commander isn’t “who has the counter.” It’s “who has the counter and can navigate the order without punting.”
How to communicate priority like a functional adult
Here are the phrases that save games:
- “Cast X. Responses?” (implies you’re passing priority around)
- “Cast X, hold priority, cast Y.”
- “I pass to B.” (explicit)
- “Before that resolves…” (useful, but only if you actually mean “while it’s on the stack”)
- “On your end step…” (if you mean end step; don’t say “end of turn” and hope)
And if a stack is getting complicated, do the simplest thing that works:
Point at the stack top and name it.
“Okay, top is Counterspell₂ targeting Counterspell.”
Suddenly everyone’s playing the same game again.
Multiplayer APNAP cheat sheet
Priority order (Commander):
Active player → next player in turn order → … → last player → back to active player
A spell/ability resolves when:
All players pass in succession.
Holding priority means:
You take additional actions before passing, because you get priority after your own cast/activation.
Triggers in multiplayer (APNAP placement):
Active player puts triggers on the stack first, then each other player in turn order.
Because stack resolves top-first, the last player’s triggers usually resolve first.
Wrap-up: Commander isn’t slower because players are slow (mostly)
Commander takes time because the rules give everyone a chance to interact at each meaningful moment, in order, every time. If you understand APNAP and priority loops, you stop getting blindsided by:
- “Wait, I thought I could respond there”
- “Why did your trigger resolve before mine?”
- “How did you cast two things before anyone could answer?”
And once you can communicate those windows cleanly, your pod stops turning every stack interaction into a courtroom scene.
Which is great—because you already have enough politics without having to litigate priority too.
Magic: The Gathering Comprehensive Rules (June 6, 2025): APNAP definition and order (rule 101.4); priority passing to next player in turn order and resolution after all players pass (rules 117.3d–117.4); triggered abilities placed on the stack in APNAP order (rule 603.3b).
