DepotDownloader is slow

First, scope this page: it's about throughput — downloads that complete but slowly. If your download is throwing timeouts, "failed to find any server with chunk," or SSL errors, that's the error side, covered in network & CDN errors. If it hangs at 0% after "Pre-allocating," that's a stall, not slowness. This page is for the steady-but-crawling case.

01Why it's slower than the client

The numbers people report are real and consistent: the Steam client saturates a 100 Mbit line; DepotDownloader on the same machine often sits at 10–15 Mbit. That isn't a bug so much as a design difference. The Steam client is a heavily optimized downloader that fans out across many CDN servers and many simultaneous connections at once; DepotDownloader is a focused command-line tool with more conservative defaults — fewer concurrent chunk downloads, fewer content servers in play. The good news is that two of those defaults are knobs you can turn.

02The two flags that matter

Throughput in DepotDownloader is governed mainly by how much it does in parallel:

• -max-downloads — how many file chunks it downloads concurrently. Raising this is the single most effective speed lever; it's what lets the tool saturate a fast line instead of trickling one chunk at a time. The default is conservative (see cli-reference for your version's exact value); try doubling or quadrupling it.
• -max-servers — how many Steam content servers it spreads requests across. More servers means more parallel sources, which helps when any single CDN edge is slow or rate-limiting you.

Those numbers are a starting point, not a magic value — push them up while watching your actual throughput and CPU/disk. There's a point of diminishing (then negative) returns: too many concurrent downloads can overwhelm a slow disk or a flaky connection and make things worse. Increase gradually and keep what helps.

03The region trick: -cellid

Steam serves content from regional CDN "cells." Normally the tool picks a cell for you based on the account's location, but that choice isn't always the fastest edge for your actual network route — a misassigned or distant cell is a classic cause of mysterious slowness. -cellid overrides it, telling DepotDownloader to pull from a specific region's content servers.

This is experimental tuning: there's no universal "best" cell, and the right one depends on your ISP's peering. The practical method is what I do myself: try a cell near you (and a couple of well-connected neighbours), compare speeds over a minute each, and keep the winner. It's most worth doing when speeds are oddly low despite a fast connection and raised concurrency — a sign you're routed to a poor edge. If you run a Lancache, the cell choice matters less; DepotDownloader can route through a cache with -use-lancache, though for actually pre-filling a cache the purpose-built tools do it better — the Lancache reference covers the flag and that division of labour.

04Old builds are slow by nature

Here's a cause no flag fully fixes: downloading an old version is inherently slower than downloading the current one. Steam's CDN caches are kept warm with the chunks people actually download — overwhelmingly the latest build. When you request an old manifest, many of its chunks aren't sitting in the fast edge caches and have to be fetched from deeper, slower origins. So a downgrade can crawl even when your connection and settings are fine, simply because you're asking for cold data. Raising -max-downloads helps you grab whatever is available in parallel, but some floor of slowness is baked into pulling unpopular old chunks. This is expected, not broken.

05ISP throttling & the network

If DepotDownloader is slow but the Steam client is fast on the same machine, the network itself usually isn't throttling Steam content (the client proves the pipe is open) — look to the flags above. But if both are slow, or speed swings wildly by time of day, suspect the path between you and Steam's CDN:

• Time-of-day congestion — test the same download at an off-peak hour; a big difference points at upstream congestion, not the tool.
• ISP shaping of bulk/CDN traffic — a quick A/B with a VPN (faster with VPN = your ISP is shaping the direct route; slower = the VPN is just overhead) tells you which.
• Wi-Fi / local — a wired test removes a surprising amount of "DepotDownloader is slow" that turns out to be the access point.

For the firewall/SSL/timeout side of network problems, the network & CDN errors page has the decoder.

06Disk & pre-allocation

DepotDownloader pre-allocates files before filling them, and writes many chunks in parallel — which can make the disk, not the network, your bottleneck. Symptoms: a slow external HDD or USB drive, a nearly-full SSD, or a network share as the -dir target, all paired with high concurrency. If raising -max-downloads stops helping (or hurts), the disk is likely the limit — download to a fast local SSD first and move the files afterward, and make sure the destination has room (pre-allocation needs the full final size up front). When that pre-allocation step doesn't just slow things but appears to freeze outright on a USB stick or network share, it's crossed from slow into a stuck or corrupt download territory.

07When it just can't match the client

The honest ceiling: after tuning concurrency, picking a good cell, and ruling out disk and ISP, DepotDownloader may still land below the Steam client's peak — because the client's downloader is simply more aggressive and more optimized than a general-purpose tool needs to be. That's a known, accepted trade: you use DepotDownloader for what the client can't do (specific old versions, depots, side-by-side installs), and accept that for raw speed on the current build the client wins. If you only need the latest version fast, the client is the right tool; if you need a specific build, a somewhat slower download is the price, and the tuning here gets you most of the way back. Honestly, when I'm pulling an old build I just start the download and walk away rather than babysit the throughput — I've stopped expecting it to match the client and I'm happier for it. When the slowness is a stall rather than a crawl — stuck at 0%, "Pre-allocating" then silence — that's a different problem entirely: that's a stuck or corrupt download, where the freeze is your disk's filesystem, not your throughput.