How to Use OKX Demo Trading: Smooth Out Your Strategy with Play Money First

You've written a strategy script, finger hovering over the Enter key—should you let it run on a real account? That hesitation is correct. The most expensive tuition in beginner quant trading is usually lost not to the market but to a flipped condition or a missing decimal point—mistakes that would have surfaced in the demo in five minutes.

In this piece we (the MeowQuant desk) cover the OKX demo account thoroughly: what it is, why you must run it before real money, how to open it, how ccxt connects (the key is one line), and where it quietly fools you. By the end you should be able to switch your script into the demo to fiddle with safely and repeatedly, confirm everything works, then switch back to real money at the cost of changing one line of code.

What Demo Trading is

OKX's demo is called Demo Trading. Simply put, it's a parallel account running on virtual funds: the market, interface, and order flow are all identical to live, except what you spend placing orders isn't real money but a batch of fake USDT the system gives you. Buy, sell, set up grids, run scripts in it—gains and losses have nothing to do with your real balance.

For quant people there's one thing to get straight up front: the demo uses its own API Key. You have to create a separate Demo Trading API Key inside the demo environment—the route OKX's own docs give you is to create one there, so don't count on flipping a switch on your live Key. The good news is that the code side barely changes: swap in the demo credentials, flip the demo toggle, and the script you wrote for live can be carried into the demo for a verification run almost untouched.

Why you must run it before real money

The logic is plain: a program doesn't hesitate. Placing an order by hand, you can still glance at the direction and size before hitting confirm; a script won't—it faithfully executes the logic you got wrong, continuously. A flipped buy/sell direction, an exit condition missing from a loop—on live, that's real money pouring out continuously.

The demo cuts the cost of this class of error to zero. You can let your script slam into walls without worry—wrong orders, wrong cancels, writing the price near market so it fills instantly—all of which in the demo merely burns virtual USDT, and each "slam" catches a bug ahead of time that would have cost you dearly live. In our experience, a new strategy run for its first few rounds on the demo will, nine times out of ten, surface at least one problem you didn't anticipate.

Beyond catching bugs, the demo also confirms two more basic things: whether auth works (did you enter the three credentials correctly), and whether the callbacks are right (are the fields returned after an order, the cancel status, and the balance changes what you assumed). None of this has to do with real money—it's pure flow-level verification, and the demo is the cheapest place to do it.

How to open a demo account

Opening the demo is far simpler than opening an API—no extra approval needed. Here's the rough path, per the current OKX interface (the entry point gets tweaked occasionally):

1. Log in to OKX, find the "Demo Trading" entry in the account/trading area on the app or web, usually at the account switcher on the trading page, or in your profile center.
2. Click in to switch to the demo environment. After switching, the interface has a clear marker (like a "Demo" label at the top) reminding you you're now spending play money.
3. The system gives you a batch of virtual funds. When the balance runs out, you can usually reset it manually on the demo interface and keep practicing.
4. If you only want to try grid, copy trading, and other built-in bots by clicking around on web/app, this is far enough—just set the parameters and run in the demo environment.
5. If you want a script to connect to the demo, first create a separate Demo Trading API Key inside the demo environment (the key-creation flow is in our API quant intro), then switch to the demo via the toggle in code.

How ccxt connects to the demo

This section is what script writers care about most. Connecting ccxt to the demo differs from connecting to live in two ways: one extra line, and credentials that come from the demo Key rather than the live one. Structurally they are still the same three: apiKey, secret, and password (the Passphrase you set when creating the Key—in ccxt this field is called password, the one beginners most often miss).

import ccxt

# Note: these three must be your demo (Demo Trading) Key, not the live one
okx = ccxt.okx({
    'apiKey':   'YOUR_DEMO_apiKey',
    'secret':   'YOUR_DEMO_secret',
    'password': 'YOUR_DEMO_Passphrase',   # OKX-specific, called password in ccxt
})

# The key line: make ccxt attach the demo header to every later request
okx.set_sandbox_mode(True)

# Self-check: this line must print 1, otherwise you are still on live
print(okx.headers.get('x-simulated-trading'))

# After this, all requests carry the demo flag and use virtual funds
balance = okx.fetch_balance()
print('Demo USDT free:', balance['USDT']['free'])

What set_sandbox_mode(True) does is make ccxt attach the demo header x-simulated-trading: 1 to every subsequent request. OKX's demo and live sit on the same REST host, and which environment a request lands in depends entirely on that header—so don't expect to tell them apart by URL. With the line in, your balance checks, orders, and cancels all run on play money; remove it (or set it to False) and the same code returns to real money.

You may have seen the variant that writes sandboxMode into options at init. That one does not get you onto the demo: in ccxt the demo header is added by the set_sandbox_mode() method itself, and writing options in the constructor never calls it—no header, no flag, and the request goes out exactly like a live one. So don't let a config value stand in for the line above: call okx.set_sandbox_mode(True), then use that print as your self-check.

There's a more dangerous point on top of that: the demo API Key must be created separately. The path in OKX's own docs is log in to OKX → Trade → Demo Trading → Personal Center → Demo Trading API, where you create a Demo Trading API Key inside the demo environment; that is the route the docs give you, not a switch you flip on your live Key. And since demo and live share one REST host and are separated only by that x-simulated-trading: 1 header, the consequence is blunt: if the Key you filled in is the live one and the header isn't attached, the orders you think are simulated land on the live book. If the toggle is on and you still get auth errors, the credentials themselves are usually wrong (most often the live set pasted into a demo script), and you can go back and check against the API errors checklist.

Once connected, take the place/cancel script you wrote (see the example in the intro piece), carry it over whole, add this sandbox toggle, and you can run it over and over without worry: even if you fat-finger a limit near the market and it actually fills, what you spend is just virtual USDT.

Where the demo fools you

The demo is great, but it has a ceiling, and that ceiling can create an illusion. The items below are things you must be clear-eyed about:

Slippage and fill prices are sugar-coated

On live, your orders have to match against real counterparties in the market, and the price often isn't as ideal as you placed it—this is slippage. The demo's matching tends to be more "obedient," with fill prices closer to your ideal. The result: the same parameters often produce a prettier equity curve on the demo than live. Don't treat the demo's returns as your live expectation.

Depth and liquidity aren't real

In a real market, a large order "eats through" the order book and moves the price; a thin pair may not match your order at all. The demo often simplifies this away, filling you smoothly no matter how big the order. On live—especially with thin-liquidity coins—that smoothness vanishes.

Your emotions are fake too

This one is most overlooked yet most lethal. A demo loss doesn't sting, so you can strictly follow your stop-loss and not fiddle with parameters. The moment real money is in, the floating-loss numbers are real, and your hands start itching—taking profit early, holding a loser past the stop, adding to a position on a whim. The demo can never teach you these emotional moves. However pretty a strategy runs on the demo, the first lesson live is often a fight with your own emotions.

Extreme conditions don't play out

Wicks, flash crashes, the occasional exchange congestion and latency—these extreme moments are where a strategy and its risk control are truly tested, and the demo's day-to-day running can hardly reproduce them. So running steadily on the demo doesn't mean your strategy will hold up in extreme conditions.

The order for switching from demo to live

Putting all the above together, here's a fixed order worth following every time you put up a new strategy:

• Run on the demo continuously for a stretch. Not just one successful run—let it run for enough time, covering a few up-and-down cycles, and confirm ordering, cancelling, callbacks, and balance changes all match expectations.
• Going live: one toggle plus one set of credentials. Remove set_sandbox_mode(True) or change it to False, and swap the credentials back to your live Key (the Demo Trading Key doesn't work on live). This is exactly the value of verifying on the demo first—the cost of switching is squeezed down to almost nothing.
• Use only a tiny amount on your first live run. An amount you wouldn't mind losing entirely; treat it as tuition. The slippage and depth the demo can't reproduce only surface now.
• Watch it for the first few days. Don't actually walk away; confirm live behavior matches what you saw on the demo, then scale up gradually.

This order isn't complicated, but it keeps "the deadliest mistakes most easily made in the beginner phase" out of real money. Demo first, then small-size live, survive first, talk returns later—the line we keep stressing.

FAQ

Once you're comfortable with the demo, you've got a zero-cost test ground—any new strategy, any changed code, gets dropped in there to run smoothly first. Next you can read how to write risk control into the script, or use the grid estimator to work out the parameters first. Whichever road you take, remember the order from today's piece: demo first, then small-size live.