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 can deploy to an independent server. The runner executes the strategy with the user's credentials and limits. Turbine helps build, test, and deploy the strategy, but the runner is the live execution environment.

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 or updates the user's independent runner through Locus.

  5. Start execution

    The runner begins evaluating the strategy on its configured loop.

  6. Monitor

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

  7. Revise or stop

    If live behavior diverges from the thesis, pause the runner or update the strategy.

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 an independent server,
  • the runner belongs to the user's deployment,
  • credentials are scoped to that runner,
  • strategy limits travel with the deployment,
  • the user can stop or revise the strategy,
  • the approved strategy remains the readable source of truth.

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

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 live strategy:

  1. pause or keep the current strategy bounded,
  2. update the strategy,
  3. backtest the changed behavior if supported,
  4. deploy the new version,
  5. confirm the runner is using the expected version,
  6. monitor the first live actions.

Avoid stacking multiple untested changes into one deployment.

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 runner target,
  • 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.