The CS2 Peeker's Advantage
Why the player swinging the corner sees you first — and the honest answer on what sub-tick did and did not change
Peeker's advantage is the head start the moving player gets when swinging an angle: they see the holder before the holder sees them. It is caused by network latency, client-side interpolation and lag compensation working together — not by tick rate. CS2's sub-tick updates removed tick quantisation, which is a real improvement, but it did not eliminate peeker's advantage, because the three causes are all still present in CS2.
You are holding an angle. Your crosshair is on the corner, you have not moved, and someone swings out and kills you before your screen has finished drawing them. It feels like a bug, or like the other player is cheating, and it is neither. It is the single most fundamental consequence of playing a fast shooter over a network.
This page explains the mechanism from first principles, then deals carefully with the question everyone actually arrives with — whether CS2's sub-tick architecture made it better, worse, or neither. That last part is where most articles on this subject invent numbers, so this one will not.
What peeker's advantage is
In any duel around a corner there are two roles. The peeker is moving out from cover. The holder is stationary, watching the angle. Peeker's advantage is the fact that the peeker has the target on screen and can begin shooting beforethe holder's screen shows anyone to shoot at.
It is not a reaction-time gap. Both players might have identical reflexes and the peeker still wins, because the two clients are not looking at the same instant of the same world.
Note also that part of what people call peeker's advantage is not networking at all — it is intent. The peeker chose the moment, is already at full strafe speed, and knows exactly where they are about to look. The holder is reacting. Even in a hypothetical zero-latency game the peeker would keep that portion of the edge. The network layer is what turns a modest advantage into an unfair-feeling one.
The three ingredients
- Latency.Your inputs take time to reach the server, and the server's picture of the world takes time to reach you. Neither player is ever seeing "now" — both are seeing a slightly stale copy of everyone else, with the staleness proportional to their own connection.
- Interpolation. Your client does not receive a continuous stream of enemy positions, it receives updates. To make other players move smoothly rather than teleport between updates, the client deliberately renders them slightly behind the newest data it holds. That is a small extra delay applied specifically to other people's positions — which is exactly the thing the holder is waiting to see. In CS2 this buffering is exposed as the
cl_net_buffer_tickssetting, and the game is upfront that adding buffer reduces missed ticks at the cost of increasing your effective ping. - Lag compensation. When the peeker fires, the server does not judge the shot against the present. It rewinds the world back to the state the shooter was looking at and checks the shot there. CS2 still does this:
sv_maxunlagexists — engine default1second, but CS2 overrides it to0.2ingameinfo.gi, so 0.2s is the actual rewind cap — and is described in the engine as the maximum lag compensation in seconds, with a companionsv_maxunlag_playerthat can further limit it for other human players.
Put together: the peeker steps out, sees the holder immediately (the holder has been standing still, so a stale position of a stationary player is a correct position), and fires. The holder's client is still a beat behind on the peeker's position, because the peeker is the one who moved. The server then rewinds and validates the peeker's shot. The holder dies to someone who, on their own screen, had barely appeared.
This is also why the effect is asymmetric rather than cancelling out. Staleness only hurts you when the other player's position is changing. The holder's position is not changing. The peeker's is.
You can see the client/server split yourself
CS2 ships a debug view that makes the divergence visible. sv_showimpacts draws two sets of bullet impact markers, and its in-engine description spells out which is which: client impacts in red, server impacts in blue, with modes for both, client-only or server-only. sv_showimpacts_time controls how long they linger.
Fire at a moving target with it on and you are looking directly at the thing that causes peeker's advantage — your client's idea of the world and the server's idea of the world are not identical, and the gap grows with movement and latency.
What CS2's sub-tick updates actually changed
Valve describes sub-tick updates as the heart of CS2. The old model evaluated the world only in discrete intervals called ticks; the sub-tick architecture means servers know the exact moment an action starts, a shot is fired, or a grenade is thrown. Valve's stated consequence is that "regardless of the tick rate, your movements and shots will be equally responsive".
That is a genuine and significant fix, and it is worth being precise about which problem it solved:
| Problem | Cause | Fixed by sub-tick? |
|---|---|---|
| Tick quantisation — inputs snapping to the next tick boundary | Discrete server evaluation | Yes. This is exactly what sub-tick addresses. |
| 64-tick vs 128-tick responsiveness debate | Same | Largely yes, per Valve's own framing. |
| Round-trip network latency | Physics and your ISP | No. Nothing in a game engine can remove this. |
| Interpolation delay on other players | Smoothing between snapshots | No. CS2 still buffers, and still trades ping for stability. |
| Lag compensation rewinding to the shooter | Deliberate design choice | No. sv_maxunlag is still there doing the same job. |
| Peeker's advantage | The bottom three rows | No. |
So sub-tick removed a source of inconsistency that sat on top ofpeeker's advantage. It did not remove peeker's advantage, and Valve has never claimed it did.
Whether the felt magnitude went up or down relative to CS:GO is a question we are not going to answer with a number. There is no authoritative public measurement, the honest inputs vary per player and per server, and the internet is full of confident millisecond figures with no source behind them. What is verifiable is the mechanism, and the mechanism is intact.
Playing as the holder
You cannot out-react a network delay, so stop trying. Everything useful here is about not being in the situation where the peeker's advantage decides the duel.
- Pre-aim the exact pixel. The gap the peeker has to beat is your reaction plus your correction. You cannot shrink the reaction, so shrink the correction to zero — see our crosshair placement guide.
- Hold off-angles. A peeker swinging wide has pre-aimed the common spot. Standing somewhere slightly unexpected costs them the one thing they had that is not network-related: knowing where you are.
- Prefer angles with a long exposure. Some positions force the peeker to be visible for a while before they can shoot you. Those are the angles worth holding solo. A position where they appear at full strafe speed already on target is not.
- Do not hold the same angle twice. After one contact, reposition. You are cheap to pre-aim otherwise.
- Crossfires.Peeker's advantage is per-duel. It does not help against two angles at once.
- Deny the swing with utility. A smoke or a molotov removes the peek entirely, which beats every mechanical answer.
Playing as the peeker
- Commit to wide swings when you have the information. A wide, fast swing is where the advantage is largest. A hesitant half-peek gives most of it back.
- Use jiggle and shoulder peeks for information, not for kills. Their value is baiting a shot or an AWP, and every re-entry after one is a fresh peek where the holder is now expecting you.
- Remember it does not exempt you from the accuracy rules. You still have to stop moving to shoot straight — the movement inaccuracy penalty is unchanged by any of this, as covered in how to aim in CS2 and our movement guide.
- Do not confuse it with invincibility. Against a pre-aimed holder on an off-angle, the peek is still a coin flip you initiated.
Settings: what is worth doing and what is not
You cannot configure peeker's advantage away. You can avoid making your own side of it worse:
- Play on the nearest server region. This is by far the biggest lever available to you, and it is free.
- Fix real packet loss and jitter rather than compensating for it in-game. Buffering hides instability by adding effective ping — a real trade, not a free win.
- Do not paste CS:GO netcode configs. Most of those commands no longer exist or no longer do what they did. Our CS2 interp settings page goes through them one at a time.
- Measure before you change anything using CS2's built-in telemetry rather than guessing from feel.
The honest summary
Peeker's advantage is not a CS2 problem, a Valve problem or a cheating problem. It is what happens when two people in different places have to agree on who shot first, and the engine resolves it by trusting the shooter's view. Every networked shooter has some version of it.
Sub-tick updates were aimed at a real and separate defect — actions being snapped to tick boundaries — and by Valve's account they addressed it. Peeker's advantage survived, because latency, interpolation and lag compensation survived. Play accordingly: hold angles that do not depend on winning a reaction race, and take the free advantage when you are the one swinging. More of the same territory is in our advanced mechanics guide and how to get better at CS2.
Frequently Asked Questions
- What is peeker's advantage in CS2?
- It is the head start the moving player gets when swinging around a corner. The peeker sees the holder on their screen before the holder sees the peeker on theirs, so the peeker can already be firing at a target who has not yet been drawn as visible. It is a networking artefact, not a game setting.
- Why does peeker's advantage happen?
- Three things stack. Network latency means every player is acting on a slightly old picture of everyone else. Interpolation means your client deliberately renders other players a little behind the newest data it has, so movement looks smooth. And lag compensation means the server rewinds the world to what the shooter saw when judging the shot — so the peeker's shot counts even though the holder had not seen them yet.
- Did CS2 sub-tick updates remove peeker's advantage?
- No. Sub-tick removed tick quantisation — Valve's description is that servers now know the exact moment an action starts, a shot is fired or a grenade is thrown, so tick rate no longer influences movement, shots or grenades. That is a different problem. Latency, interpolation and lag compensation all still exist in CS2, and those are what produce peeker's advantage.
- Does lag compensation still exist in CS2?
- Yes. The console variable sv_maxunlag is present in CS2. Its engine default is 1 second, but CS2 ships an override of 0.2 in gameinfo.gi, so 0.2s is the real cap; it is described in the engine as the maximum lag compensation in seconds, and there is a companion sv_maxunlag_player for limiting it against other human players. Rewinding the world to the shooter's view is still how hit registration works.
- Can I reduce peeker's advantage with settings?
- You can reduce your own contribution to it, not the mechanic. Play on the closest server region, fix genuine packet loss and jitter, and understand that CS2's buffering setting explicitly buys stability with extra effective ping. There is no config value that turns peeker's advantage off, and any guide claiming otherwise is selling CS:GO-era myths.
- How do I play against peeker's advantage?
- Stop presenting yourself as a stationary target on someone else's terms. Hold off-angles rather than the obvious one, pre-aim the exact pixel so your correction is zero, hold angles that force a long exposure rather than a fast swing, use utility to deny the swing, and set up crossfires so the peeker cannot win both duels with one advantage.