Paste this into your userconfig.cfg or run it in console. The server auto-corrects the locked values; the rest are the best choices inside the allowed ranges.
If you run a frame cap above 100, raise cl_cmdrate to match it (fps_max 240 pairs with cl_cmdrate 250).
cl_filterstuffcmd must be 0 so the server can correct your cvars. Locked values like rate are enforced by KTPCvarChecker; fighting them in your config just causes correction churn.Maximum bytes/sec the server may send you. KTP locks this to exactly 100000 for every player (sv_minrate = sv_maxrate = 100000). Peak match traffic at our update rates is ~96 KB/s, so 100 KB/s never chokes, and identical bandwidth budgets remove rate variance as a hit-registration variable. The engine itself supports up to 1 MB/s (KTP-ReHLDS raised the 2004-era cap), kept as headroom for HLTV and future updaterate increases.
How many entity updates per second you request from the server. The game's client DLL hard-caps processing at 102 and no workaround exists, so 103-120 passes the check but does nothing. At 102 you receive a fresh snapshot every ~9.8 ms, the physical maximum your client can use.
How many command packets (your movement, aim, and button presses) you send per second. This is a ceiling, not a scheduler: the client sends at most one packet per rendered frame, so your real send rate is always min(your fps, cl_cmdrate). Below your frame rate it throttles input; above it, the excess does nothing. The floor of 100 keeps input latency at ≤10 ms per packet; engine research indicates the Steam client caps effective cmdrate near ~100 anyway, so 101 covers most players.
Why "a bit above" and not exactly equal? The frame limiter's off-by-one (see the fps_max card) means a cap of 240 actually renders ~241 fps — so cl_cmdrate 240 would sit one below your true frame rate, the single worst value, quietly throttling about one packet a second. Since overshoot is free, round up with margin: fps_max 100 → 101, fps_max 240 → 250. Nothing is magic about the exact number — 242, 250, or 300 behave identically at a 240 cap; anything comfortably above your real frame rate is correct.
How far in the past (seconds) your client renders other players, so it always has two snapshots to interpolate between. At updaterate 102 a snapshot arrives every ~9.8 ms, and 0.01 is the smallest buffer that covers a full interval: you see enemies as close to their true position as possible, and lag compensation rewinds the minimum amount. The stock default of 0.1 shows you players 100 ms in the past, ten times more than needed here. The 0.05 cap blocks exploitative high-interp values.
Only for loss or jitter on your own connection; check net_graph 1. Each +0.01 buys one more update interval of cushion at the cost of seeing everything ~10 ms later. That costs you reaction time, not hit registration: the server rewinds by ping + interp, so you still hit what you see.
| Your connection | ex_interp |
|---|---|
| Clean (0% loss, stable ping) | 0.01 |
| Loss ~1%+ or enemies stutter at 0.01 | 0.02 (rides through a single lost packet invisibly) |
| Chronically jittery route (e.g. SA/EU long-haul) | 0.02-0.03 (covers uneven packet arrival) |
| Above 0.03 | No legitimate case. The 0.05 cap is a ceiling, not a target. |
Ping alone, yours or your opponents', is not a reason. Latency delays the update stream uniformly (a stable 160 ms connection still gets a snapshot every ~9.8 ms) and lag compensation accounts for it. High-ping players often do need 0.02, but that's because long routes tend to be jittery, not because of the ping number. Raising interp also does nothing against high-ping opponents: their staleness is baked in server-side before your packet is ever sent, the buffer applies to every entity equally, and a choppy opponent's warpy movement just plays back the same, only later. The "shot me behind cover" effect is the shooter's rewind window (their ping plus their interp, capped server-side), and no setting of yours changes it.
Client frame cap. GoldSrc's internal physics processing tops out around ~100 fps; frames above that buy rendering smoothness on high-refresh monitors, not physics fidelity, and the server's 1000 Hz lag compensation is authoritative regardless. 100 is full competitive fidelity. On a 144/240 Hz display, match your refresh and raise cl_cmdrate with it.
Why not 99.5? The old convention comes from an off-by-one in GoldSrc's frame limiter: it gates frames at 1/(fps_max + 1), so asking for 100 actually runs about 101. Back when leagues required staying at or under 100 fps, players set 99.5 so the overshoot landed on a true 100. Neither reason survives on KTP servers: the allowed range goes to 750, and nothing in the game cares whether your client renders 100 or 101 when the server simulates at 1000 Hz and its lag compensation decides what hits. A plain 100 is fine.
One exception — automatic-weapon stutter: separately from the 99.5 history, round fps caps are reported to interact badly with automatic-weapon fire timing on some setups. If your autos stutter, try a non-round cap (143.5 instead of 144) together with the cl_fixtimerate guidance below.
cl_lc 1 enables server-side lag compensation: when you fire, the server rewinds opponents to where they were on your screen. With 0 you must lead targets by your full ping. cl_lw 1 enables client-side weapon prediction (instant fire feedback); setting it to 0 also disables lag compensation. Both became optional in 2026 after an engine audit confirmed that 0 only handicaps you. There is almost never a reason to change them.
How aggressively your client corrects its local clock toward the server's timestamp, in ms of correction per frame. This has no competitive impact: clock sync happens either way. A mismatched client/server clock is, however, a known cause of weapon fire stutter in GoldSrc — shots firing, skipping, then firing again, most noticeable on automatics like the BAR — and the correction jumps themselves can make the viewmodel animation skip. This cvar used to be locked to 7.5 by the cvar checker; it's now unlocked so players can tune it.
If (and only if) you get weapon skipping: try scaling it to your frame cap — cl_fixtimerate = fps_max / 10:
Some players instead report smoother viewmodels lowering it toward 0 (gentler corrections). Honest status: this one is player-report territory, not settled engine science — treat it as an experiment, keep whichever value is smooth for you, and tell Nein_ what worked so this section improves. If you have no skipping, leave it at 7.5.
When the server disagrees with where your client predicted you are (teammate bumps, knockback, edge landings), this is how long in seconds the correction is visually blended. During that window your rendered position lags the server-authoritative one, which creates a small aim discrepancy. 0.01 blends the correction over about one update interval: near-instant accuracy without a single-frame snap. It's the same smallest-honest-buffer logic as ex_interp, and the old league convention. High-ping players (100 ms+) can keep the 0.1 default for comfort, since their corrections are larger and more frequent.
When your shot arrives, the server computes your effective latency (ping + ex_interp), rewinds every opponent to where they were on your screen at that moment (up to 500 ms), and runs the shot against those positions. If your crosshair was on the target on your screen, it hits. That's why the settings above aim for the smallest honest buffers: less rewind, fewer "how did that hit me" moments on both ends.
June 2026 change: lag compensation now uses your single most recent latency sample (sv_unlagsamples 1) instead of averaging a window of samples. The old averaging smeared stale ping history into the rewind, and one ping spike inside the window could silently zero out compensation for that shot. One fresh sample tracks your actual current ping.
You don't set these. They're the fleet-wide server config your client talks to.
| Setting | Value | Purpose |
|---|---|---|
sys_ticrate | 1500 | Requested tick ceiling; achieves ~1000 real fps of physics |
sv_maxupdaterate / sv_minupdaterate | 120 / 100 | Entity update band offered to clients |
sv_maxcmdrate / sv_mincmdrate | 500 / 100 | Command packet band accepted from clients |
sv_maxrate / sv_minrate | 100000 / 100000 | Bandwidth locked: identical budget for every player |
sv_unlag / sv_maxunlag | 1 / 0.5 | Lag compensation on, max 500 ms rewind |
sv_unlagsamples | 1 | Latest latency sample used: tracks your real current ping |
What specific KTP players actually run. The recommended block above is the baseline; these show the personal variations experienced players make inside the allowed ranges — mostly frame caps matched to monitors, with cl_cmdrate raised alongside.
Want your settings featured (and sanity-checked)? DM Nein_ on Discord.
rate is 100000 and cl_updaterate is 102.net_graph 1 for choke; red spikes mean updates are being skipped.ex_interp is 0.01; higher values show everyone further in the past.cl_lc 1 and cl_lw 1; without them you're leading shots by your full ping.ex_interp 0.01; above that you're aiming at older positions than you need to.cl_cmdrate ≥ 100, since low cmdrate delays the server seeing your click.rate 100000. At KTP's update rates, 100 KB/s doesn't choke from bandwidth.ex_interp 0.02 hides single lost packets (see the ex_interp ladder above).cl_fixtimerate = your fps_max / 10 (fps_max 100 → 10, 143.5 → 14.4, 200 → 20). See the cl_fixtimerate card above.fps_max (e.g. 143.5 instead of 144) — round caps are reported to interact badly with automatic-weapon timing.cl_fixtimerate toward 0 (gentler clock corrections).