XTester 0.0.75: from model to live execution

There is a wide gap between a strategy that looks convincing in an editor and a system that is ready for a real launch. The gap gets wider when the strategy uses a machine-learning model or calls an AI provider.

A demo is easy to build: load an ONNX file, run inference, read a number, send an order. The harder questions arrive later. Which exact model produced the backtest? Were its features passed in the same order? Was it trained on data that belongs to the future of this run? Why does Launcher make a different decision from Tester? Did the launch package carry credentials or network settings? Can the result be reproduced without calling the external service again?

XTester 0.0.75 addresses that transition from a working prototype to a reproducible and auditable execution path. The release adds managed ONNX artifacts, controlled access to local and cloud AI providers, a modern strategy lifecycle, and shared runtime behavior across Tester, Research Lab, headless verification, Paper, and Live Launcher.

This is a substantial platform update. The clearest way to understand it is to follow a strategy from its model artifact to the moment it starts running in Paper or Live.

The model becomes part of the project

Connecting a model to a trading strategy often starts with a local file path. That works on the developer's machine and travels poorly. The file may be moved, replaced, or confused with another revision. A second machine has a different path. A report may preserve the result without preserving reliable proof of the model that produced it.

In XTester 0.0.75, a model is a managed project artifact.

You can import a regular .onnx file or a portable schema-v2 .xtmodel artifact, inspect its feature and output contracts, export it again, or install the bundled synthetic demo model. Strategy code accesses the model through the safe XTester.Models API instead of opening an arbitrary path on disk.

XTester stores the information required to reproduce inference together with the weights:

• the exact order of input features;
• normalization rules;
• output shapes;
• the training-data cutoff in TrainingDataEndUtc;
• a SHA-256 fingerprint.

The contract is validated before OnInit. If the artifact was modified, damaged, or trained on data that lies in the future of the current run, the run fails before trading begins. The problem appears before a persuasive report can hide it.

XTester does not guess whether a strategy and model are compatible. The compatibility contract is explicit and machine-checked.

One ONNX path in Tester and Launcher

Even immutable models can produce small differences when the runtime changes execution providers, thread counts, or graph settings. That may be acceptable in an exploratory notebook. It is a problem when comparing trading runs because it becomes harder to explain why a decision changed.

Version 0.0.75 pins one CPU execution path for Tester, bundle/headless verification, Paper, and Live:

• CPUExecutionProvider;
• sequential execution;
• one intra-op and one inter-op thread;
• extended graph optimization.

Launcher receives the exact model payload and contract validated by the project. Model fingerprints are retained in strategy versions, Research Lab versions, reports, project sync, readiness checks, and restore operations. If the artifact changes, the platform does not pretend it is the same run.

The boundaries of Model SDK v1 are deliberate. This release performs inference. It does not train models, choose a GPU or NPU, or hot-swap active weights. Training and calibration remain separate workflows. Reproducibility comes first; broader execution options can be added on top of a stable contract.

An AI provider without credentials inside the strategy

The second major part of the release is for strategies that need more than local ONNX inference and must call a language model or another AI service.

Passing a URL, token, and network client directly into strategy code is convenient only until the project moves. Then secrets can leak into source, bundles, or logs. It also becomes difficult to control call frequency and cost, disable networking during verification, or prove which response affected a decision.

XTester 0.0.75 introduces the Strategy AI Provider SDK. A strategy talks to a logical slot through XTester.AiProviders. The launch profile binds that slot to a local Ollama or LM Studio instance, or to a configured cloud provider. Strategy code never receives the actual provider ID, model, endpoint, credentials, or transport objects.

Each slot has an explicit policy:

• access mode;
• timeout and rate limits;
• per-run call and token budgets;
• consent tied to the exact remote endpoint.

Three access modes are available:

• ReplayOnly uses previously recorded responses only;
• RecordMissing requests missing responses and records them for later replay;
• LiveNoRecord makes live calls without recording their contents.

Local development, verification, and live operation can therefore use different policies without changing the strategy source.

Why an AI call cannot block a trading callback

A network response may arrive quickly, arrive late, or never arrive. If strategy code waits for it inside OnBar, service latency starts controlling simulated time and can freeze execution.

The new provider calls are non-blocking. A result becomes visible to the strategy only after simulated time advances. Before it can be used, the response must pass strict local JSON and schema validation. The transport layer does not silently follow redirects, switch endpoints, retry at its own discretion, or accept oversized responses.

The strictness is intentional. Strategy code must know whether a valid response exists and decide what to do when it does not. Network behavior is not allowed to rewrite the trading rules behind the scenes.

Record and replay make external AI testable

The same prompt does not guarantee the same answer from an external model. Without a recorded response, two otherwise identical strategy runs may diverge.

XTester now has a bounded record/replay path for this case. Records are encrypted with DPAPI and limited in size. In ReplayOnly, the strategy receives the same stored result without a network call. A research run can be repeated, a bundle can be verified, and execution paths can be compared against the same AI input.

The security boundary is separate and explicit. Bundle and headless verification never call a provider over the network. Bundles do not contain endpoints, keys, prompts, inputs, responses, replay bodies, or transferred remote consent. Bundle schema v3 carries only stable strategy and profile identities plus a non-secret binding snapshot.

On another machine, callable AI modes require a new local binding, validation, consent, and a controlled worker restart. Consent is not carried with the project as a meaningless checkbox.

A modern strategy lifecycle

Models and providers are not enough if Tester and Launcher invoke strategy code differently. The third major line in 0.0.75 is one strategy lifecycle.

The modern contract includes:

• OnInit(StrategyContext) for initialization and dependency declarations;
• OnBar(ISymbolKey, IKline) with the exact source of each event;
• an exactly-once OnFinish(StrategyFinishContext) carrying an explicit finish reason.

A run may finish normally, be stopped by the user, restart, be replaced, stop with the terminal, or fail with an error. Even a partially completed OnInit now finishes predictably once a run instance exists.

Existing strategies continue through the legacy compatibility bridge. Teams do not have to rewrite every project immediately, while new strategies can adopt the clearer contract.

Multiple feeds without future data

The primary instrument is subscribed automatically. A strategy adds more bar streams through SubscribeOnBar. If it needs history for calculations without creating a callback, it uses DeclareDataDependency and specifies the required number of closed bars.

The distinction matters. A subscription declares events the strategy wants to receive. A dependency declares data it needs to read.

During Live execution, the shared watermark advances with the slowest required feed. Catch-up after a pause or restart runs in chronological order at the real boundaries of closed bars. A faster timeframe cannot pull the strategy forward while a required higher-timeframe bar is still open.

The same dispatcher now serves GUI backtests, bundle/headless runs, Research Lab, Paper, and Live. This reduces the chance that a strategy passes verification in one mode but receives a different event sequence after launch.

What changed in Launcher

Launcher can now select a launch profile for each bot. Profile changes are applied through a controlled restart so old bindings, counters, and state do not mix with the new configuration.

The statistics window shows safe diagnostics for local models and AI slots, including state, limits, and counters. It does not expose secrets, request contents, or provider details.

MCP and Copilot also gain metadata-only discovery through list_strategy_models and list_strategy_ai_slots. An agent can understand which model artifacts and logical slots exist without gaining access to credentials or call contents.

Platform requirements and the end of BitMEX support

XTester 0.0.75 requires Windows 10 version 2004 (build 19041) or newer and an x64 process. XTester, Launcher, and MCP Host now target .NET 10 with net10.0-windows10.0.26100.0. Windows 7 and 32-bit builds are no longer supported.

BitMEX support has been retired. The exchange is removed from selection, history, symbols, fees, accounts, Launcher bundles, and Research Lab overrides. During settings normalization, legacy BitMEX accounts and symbols are removed, while saved profiles and layouts are reset where they referenced BitMEX.

Existing user market-data files are not deleted automatically. They can no longer be selected or used, but remain on disk until the user makes a separate archival or deletion decision.

One SDK handbook instead of scattered clues

A large public contract is difficult to use if developers must reconstruct it from method signatures. The release includes a bilingual Strategy SDK Handbook covering Quickstart, lifecycle, multi-timeframe data, signals, orders, risk, services, ONNX, provider AI, testing, Launcher, recipes, and a generated public API reference.

IntelliSense, compiler guidance, Copilot knowledge, sandbox checks, MCP documentation, and platform specifications were updated to match the same contract. This matters for both people and coding agents: the agent writing a strategy should receive the same rules enforced by the compiler and runtime.

Smaller changes that matter every day

Not every improvement needs an architectural chapter.

The last-price marker now shows simulated time remaining until the current bar closes, stays inside the plot, and draws above dense order and indicator labels. Readiness checks and compilation that may take noticeable time run away from the UI thread. The telemetry consent dialog now fits localized content correctly at higher DPI settings.

How the release was validated

Automated coverage for 0.0.75 now includes real ONNX inference, artifact tampering, causal time checks, provider transport, replay and privacy, lifecycle behavior, bundle compatibility, platform guards, and retired-exchange migration.

The release also passed two end-to-end golden acceptance runs in Release configuration.

The first uses a deterministic synthetic model-enabled strategy. The second uses an exact DPAPI-encrypted Strategy AI fixture in ReplayOnly. Both scenarios ran through the regular Tester SimulationRunner, direct BundleBacktestRunner, and an actual XTester.Launcher.exe --worker process.

Strategy decisions, fills, statistics, model and AI fingerprints, and pinned order-trace SHA-256 values matched across all three paths.

These fixtures prove the consistency of the platform paths. They do not prove that any arbitrary model is a correct trading system. Every production strategy, feature set, and ONNX graph still needs its own calibration, out-of-sample testing, and acceptance run.

What 0.0.75 changes in practice

The release removes hidden variables from the path between research and launch.

A model is no longer an incidental file on one computer. An AI provider does not give its credentials and network details to strategy code. Verification can be repeated through replay. Multiple data feeds advance causally. A strategy run finishes with an explicit reason. Tester and Launcher share the same runtime path.

None of this removes trading risk or turns AI into a source of guaranteed returns. It does make a result easier to explain: which model ran, what data it could see, which provider endpoint was allowed, which response was used, and whether behavior matched between the test and the launch.

XTester 0.0.75 is available now. Existing installations receive it through the built-in update flow. Setup, Installer, and Portable packages are available on the release page.

Download XTester 0.0.75

This article is for informational purposes. Backtests, AI models, and automation do not guarantee future returns. Validate every strategy on unseen data and apply suitable risk limits before live trading.