CS2 mechanicVERIFIED (algorithm RE'd + constants)Updated 2026-07-27

CS2 air acceleration: sv_airaccelerate 12, capped by a 30 u/s wish speed

CS2's air acceleration is sv_airaccelerate 12, capped by sv_air_max_wishspeed 30 units per second, and the classic Source AirAccelerate function is intact in CS2. The asymmetry between those two numbers is the whole mechanic: the speed-difference test uses the capped 30 u/s wish speed, while the acceleration magnitude uses the full uncapped one. That is what leaves headroom for a strafing player to keep gaining speed sideways, and it is why air-strafing exists at all.

Algorithm transcribed from the current CS2 server binary; the constants confirmed from the live convar list, and the ground-acceleration figure re-derived on the IEM Cologne Major 2026 usercmd corpus (network protocol 14165) in July 2026.

sv_airaccelerate
12
sv_air_max_wishspeed
30 u/s
sv_accelerate (ground)
5.5
sv_maxspeed (engine cap)
320 u/s
sv_maxvelocity
3500 u/s
Acceleration is applied
per user command, not per tick
Measured ground speed plateau
250.00 u/s
Watch a real pro CS2 match in 3D

Plays in your browser · no download · no account

How it was measured

Air acceleration is one of the few CS2 mechanics with no demo oracle worth using: a demo records where a player went, not the branch the server took, and any curve fitted to airborne positions will reproduce the trajectory without recovering the rule. So this one was taken from the binary, and the constants confirmed from the running game's own convar list.

The function is unchanged from classic Source. Compute the desired speed, clamp it to sv_air_max_wishspeed, subtract the component of current velocity already along the wish direction, and if anything is left, add acceleration along that direction — but limited by the smaller of the remaining difference and sv_airaccelerate × the FULL wish speed × surface friction × frame time.

The exploit is in that last sentence. addSpeed uses the capped wish speed, accelSpeed uses the uncapped one. Point the wish direction almost perpendicular to your velocity and the projection stays small, so addSpeed stays positive even at high speed, while the acceleration term remains large. Air-strafing is not a bug in the physics; it is the direct consequence of two different wish speeds appearing in two adjacent lines.

One structural detail matters for anyone porting this: CS2 applies acceleration per user command in its subtick pipeline, not once per tick. The air function reads its frame time from the subtick interval and maintains per-subtick base-velocity accumulators, and one-step replay errors on the ground quantize at exactly accelerate × maxspeed × dt = 21.48 u/s, which is the signature of the same structure.

AirAccelerate, transcribed from the current CS2 server binary

wishSpd  = min(wishSpeed, sv_air_max_wishspeed)   // 30
addSpeed = wishSpd - dot(velocity, wishdir)
if addSpeed > 0:
    accelSpeed = min(sv_airaccelerate * wishSpeed * surfaceFriction * frametime,
                     addSpeed)                     // note: FULL wishSpeed here
    velocity += accelSpeed * wishdir

Every fact on this page, with its tier

Air movement = classic Source AirAccelerate, intact in CS2, with the addSpeed-uses-capped / accelSpeed-uses-full asymmetry that enables air-strafing

Value
sv_airaccelerate 12, sv_air_max_wishspeed 30
Confidence tier
VERIFIED (algorithm RE'd + constants)
How it was derived
Algorithm transcribed from the current server binary; the two constants read from the running game's convar list rather than assumed from CS:GO.
Evidence
Both values confirmed via cvarlist; the transcription is ported into the project's float32 movement core.

sv_accelerate = 5.5 (ground acceleration)

Value
5.5
Confidence tier
MEASURED, CURRENT-BUILD CONFIRMED
How it was derived
Friction-pinned spin-up clustering on recorded movement — an estimator that does not need to know which frames were "accelerating".
Evidence
Dominant cluster 5.485 × 24 on the 2026 tournament usercmd corpus, with a speed plateau at 250.00; earlier corpora gave 5.490 × 29. The low tail is partial-tick subtick presses.

CS2 applies acceleration PER USER COMMAND (subtick pipeline), not per tick

Value
per usercmd
Confidence tier
EVIDENCE
How it was derived
One-step replay errors were examined for structure rather than magnitude, and the air function's own frame-time source was read in the binary.
Evidence
Replay velocity errors quantize at exactly accelerate × maxspeed × dt = 21.48 u/s; AirAccelerate takes frametime from the subtick interval and keeps per-subtick base-velocity accumulators.

Other movement convars: sv_maxspeed 320 (engine cap; per-weapon values are lower), sv_maxvelocity 3500, sv_ladder_scale_speed 0.78, sv_walkable/standable_normal 0.7 (about a 45.6° maximum slope)

Value
320 / 3500 / 0.78 / 0.7
Confidence tier
VERIFIED (cvarlist)
How it was derived
Read literally from the current build's convar list.
Evidence
Captured into the project's convar corpus alongside the movement constants.

Open questions — what is not known

How many client commands feed one tick is still unknown.

Tournament demos carry the ONE command the server executed per tick per player — enough for input replay at the 1/32 u quantization floor — but not how many commands the client sent. Intra-tick command batching, and therefore true bit-parity on acceleration, needs a client-recorded current-build demo or more binary work.

Other CS2 mechanics

Last updated 2026-07-27 — the date of the measurement, not of this page's rendering. What the confidence tiers mean. Memorin is not affiliated with or endorsed by Valve; Counter-Strike 2 is a trademark of Valve Corporation.