Run Strategies

Run is the part of Studio that moves an approved strategy from a draft into live execution. Studio keeps the experience simple, but the deployment model is designed to be permissionless and user-controlled.

Turbine partnered with Locus (YCF25) so every user gets one private runner per venue family that hosts their Bots. A Bot is one running instance of a strategy, live or paper; the runner executes it with the user's credentials and limits. Turbine helps build, test, and deploy the strategy, but the runner is the live execution environment. See Locus deployments for how Bots, runners, and caps fit together.

When to run

Only run a strategy after:

• the strategy matches the user's intent,
• the risk limits are explicit,
• the strategy has been backtested where data is available,
• the user understands the backtest assumptions,
• live credentials are ready,
• monitoring and pause behavior are understood.

If the backtest is inconclusive, use smaller limits or keep the strategy in review.

Deployment flow

1. Approve the strategy

   Review the strategy type, market selector, edge data, entries, exits, and risk limits.

2. Review backtest

   Make sure the result is strong enough to justify a small live test.

3. Prepare credentials

   Connect the venue credentials required for the strategy. Credentials are intended for the user's runner, not for a shared Turbine trading account.

4. Deploy to Locus

   Studio provisions the venue's private runner through Locus if it does not exist yet, then deploys the strategy onto it as a Bot.

5. Start execution

   The Bot begins evaluating the strategy on its configured loop, as its own process beside any sibling Bots already on that runner.

6. Monitor

   Watch status, logs, fills, exposure, and any pause conditions.

7. Revise or stop

   If live behavior diverges from the thesis, stop that Bot or deploy an updated strategy to it. Its siblings on the same runner keep running, as long as that runner is healthy and current.

Permissionless by design

The run experience should feel like a normal Studio deployment, but the execution path is not a custodial black box.

Key properties:

• each user gets a private runner per venue family, which hosts that family's Bots — Kalshi events, Kalshi Perps, Polymarket US, Turbine, and Kalshi + Polymarket US arbitrage share one runner, while Polymarket has its own because it executes from a different region,
• the runner belongs to the user, not to any one Bot,
• credentials are scoped to that runner,
• strategy limits travel with the deployment,
• the user can stop or revise any Bot they are running,
• the approved strategy remains the readable source of truth.

This model lets Studio stay easy to use while preserving a user-controlled execution boundary.

The browser is optional. See Run a strategy programmatically to export your wallet, compile a public library strategy by slug, and send wallet-signed code directly to your Locus runner without Turbine's deploy API.

What goes live

Live deployment should preserve the same behavior tested in the backtest:

• market selector,
• strategy rules,
• loop cadence,
• risk limits,
• edge data requirements,
• stale-data handling,
• stop conditions,
• credential scope.

If any of these change, run another backtest when possible and make the difference explicit.

Good live defaults

For a first deployment:

• start with smaller exposure than the maximum you would tolerate,
• avoid wide spreads,
• avoid final-minute entries unless the strategy is specifically designed for close behavior,
• pause on stale data,
• keep logs enabled,
• monitor early fills,
• avoid scaling until live behavior matches the thesis.

Updating a running strategy

When you revise a strategy that already has a Bot running:

1. keep the running Bot bounded, or stop it,
2. update the strategy,
3. backtest the changed behavior if supported,
4. deploy the new version — the Run button reads Update Bot 2 for the selected Bot and pushes the new code to it in place, keeping its Bot label, while Deploy as new Bot starts a second, independent Bot from the same strategy,
5. confirm the Bot is running the expected version,
6. monitor the first live actions.

Avoid stacking multiple untested changes into one deployment. How many Bots you may run at once is a plan entitlement — Starter 1, Basic 3, Pro 5 — counted across every venue and including paper Bots. That cap only blocks starting a new Bot; updating a Bot you already run is never refused for being at the cap.

AI agent guidance

AI agents should not deploy casually. A good deployment response should include:

• the exact strategy version or summary,
• the risk limits that will be live,
• the backtest result that justified deployment,
• the target Bot and its runner, and whether the deploy updates that Bot or starts a new one,
• the pause or stop condition,
• the statement that live trading can lose money.

If the user says "run it" before a backtest, the agent should confirm whether they want to skip testing. The safer default is to backtest first.