XTester Studio alpha.4: strategy research and the path to portfolio testing

A strategy accumulates a history of decisions long before it reaches a trading account. An entry rule changes, a filter is added, an imported script closes a position differently. When an AI assistant does some of the work, the number of candidate versions can grow quickly. Eventually, the useful question is which version produced the result, and why that version was kept.

XTester Studio 1.0.0-alpha.4 is now available for Windows, macOS and Linux. This release gives each AI Lab investigation its own Copilot conversation and improves charts, strategy-conversion checks and order execution. It also changes how Studio checks for updates, collects optional diagnostics and packages trading robots.

Our September articles covered strategy projects, market phases, experiment branches and portfolio management separately. This longer update connects those topics: develop a strategy, understand its behavior, retain the reasoning behind a version choice, then investigate how it might behave alongside other strategies. The earlier stages are available in Studio today. A programmable portfolio manager and multi-strategy backtests on a shared account remain design work, not alpha.4 features.

The working environment available today

Studio brings the editor, historical data, simulation and AI Lab into one application. Strategies live in projects, with source files, modules and settings you can return to after an experiment. Downloaded history, backtests and reports work locally. Data downloads, updates and cloud AI providers need a network connection; AI features can also use a local model.

The current environment extends beyond the older Windows client. Studio has development tools for ten languages: C#, Python, JavaScript, TypeScript, Pine Script, Java, C++, Rust, Go and R. They do not all offer the same capabilities. C# has the fullest support for development, execution and AI Lab. Other languages use execution and backtest adapters, and some require a language package or an installed toolchain.

Pine Script v5/v6 runs in XTester's own interpreter. Orders and trading costs are handled by the XTester engine, so matching TradingView results cannot be assumed. Library imports and some other Pine features are unsupported. Choose a language based on the APIs and libraries your strategy needs, and check a port by its behavior.

These capabilities describe Studio as a whole; the short release article lists the changes introduced in alpha.4.

A separate conversation for each investigation

In alpha.4, each AI Lab investigation has a separate Copilot chat session. You can open the conversation when needed, and questions take you back to the relevant investigation. This keeps discussions about different ideas in their own conversations.

Consider two investigations: one changes an entry filter, while another tests an exit rule. They have different starting versions and different questions. Each conversation stays with the investigation it belongs to.

The laboratory already supports strategy versions, experiments, result comparisons and applying a chosen version to the project. Our article on experiment branches explored those operations alongside a mockup of a proposed interface.

A broader question is how much of the search should remain visible after the agent delivers a strategy. Which versions did it discard? Did it change the hypothesis after inspecting results? Why did it switch the test period? At what point did it start solving a different problem?

Studio lets you revisit versions and past investigations. We are still exploring how to retain the original hypothesis, the reasons for every change and all discarded attempts. That record would help researchers decide what to test next on data that has not already shaped the strategy. Keeping a history of the search does not eliminate overfitting.

Tracing a result back to an execution

When a result changes, the investigation often comes down to a particular event: an entry, a partial exit, a trailing stop or an order at a candle boundary. This is where chart work and execution fixes meet.

Alpha.4 keeps candles properly spaced when little history is available and shows the candle still forming during fast tick-by-tick simulations. The loading indicator remains visible during startup and compilation. Starting another run preserves the selected simulation period.

These changes reduce the work of returning to the same part of a test and make the chart's loading state clearer. The chart still needs to be read alongside the execution records and test settings.

In Studio, a strategy can itself request finer historical data when it detects an event, for example the last three minutes at one-second resolution. The tester pauses simulation time, obtains the data from the local cache or the exchange, then resumes the run. Availability depends on the source and period. If real one-second data is unavailable, synthetic data can be used only with explicit user opt-in and must be labelled as synthetic; it is not observed exchange data. The alpha.4 fix corrects how a limited portion of data is read during this refinement on long histories.

The strategy-conversion wizard now checks for more errors in order quantity, direction, crossover conditions and exit handling before accepting a port. Execution fixes cover slippage on market orders placed at minute boundaries, several Pine partial and trailing-exit cases, and live order cancellation handling. Closing a Studio window now ends the debugging session started with F5 in that window.

If your strategy uses one of those mechanisms, a useful next step is to rerun the earlier test with the same data and settings, then compare the affected trades. A changed result after an engine fix does not necessarily mean the trading idea improved. The difference may come from how an order was simulated.

Imported code also needs a behavioral check after it compiles. Compare entry conditions, quantities, exits and costs with the original strategy. Even matching trade times and directions does not establish equal financial results.

Market phases and changing risk budgets

When we published the strategy-project article, the market-phase analyzer was described as part of the upcoming Studio release. It is now listed among Studio's current capabilities. Direction, volatility, transitions and events are evaluated on closed bars and are available to strategies through the C# API.

For a researcher, that makes a more specific question possible. An entry rule can remain unchanged while you examine its behavior in a directional market and in a range. Robustness checks also explore changed commissions and slippage. The market-phase episodes come from the same history as the main backtest, however. They are another view of that period, not an independent test on fresh data.

One idea we are exploring is to adjust a strategy's risk budget as conditions change. A trend-following strategy could have a lower risk limit when its rules indicate a shift into a sideways market.

The timing of the decision belongs in the test. What information was available when the limit changed? Which observation triggered it? If a market phase was identified using later price movements, the test has introduced information that would not have been available at the time.

A useful comparison would keep the strategy, data and execution assumptions the same, then test a fixed risk budget against a changing one. The selected rules would still need evaluation on a new period. Adding a more elaborate controller creates another hypothesis to test; it does not establish that risk management has improved.

Several strategies, one account

The programmable portfolio layer is still being designed, with no announced release date. Its central requirement is a shared account. Giving every independent backtest the full starting balance and then combining the reports cannot show what happens when those strategies run together.

Suppose one strategy is already using some of the account's margin when another receives a signal in the same market. The second strategy's standalone backtest has enough capacity. On a shared account, its order might need to be smaller or might fail a limit. A third strategy could add another position in the same direction. Different strategy names do not necessarily produce different exposures.

A management module, or orchestrator, would sit above the strategies. Each strategy would determine its trading actions, while the manager would allocate risk based on market conditions, strategy history, open positions and portfolio drawdown. Users could write those management rules in code or connect a ready-made module. We want users to combine their own and third-party strategies in one portfolio; a marketplace could become another source in the future.

Capital allocation and risk allocation need separate treatment. Equal amounts of capital can produce different exposures because leverage, volatility and position size differ. A future control panel should therefore show allocated and used risk, strategy statistics and a decision history: when a limit changed and why.

Alpha.4 already adds a narrower control. Robot profiles can have an optional daily loss limit, including a percentage of account equity. Robot packages include the connectors and runtime components required by their settings, and the wizard estimates the corresponding package size. A robot's daily loss limit should not be mistaken for a finished system that distributes risk across several strategies.

The experiment we want from the future portfolio layer is straightforward to describe: keep the strategies, shared starting balance, data and execution assumptions fixed, and vary the risk-management rules. Compare drawdown, capital usage, rejected orders and each strategy's contribution. The combined equity curve needs an account-event history that explains how it was produced.

Manual control and the assistant's role

In that design, users should be able to change a limit, pause a strategy's new entries and later return it to automatic management. Preventing new entries and closing existing positions need different commands. A manual restriction should remain in force until the user removes it, rather than disappearing at the next recalculation.

We are also considering an AI assistant's role through MCP: inspect portfolio state, explain a decision and propose a change. Its ability to act would depend on permissions granted by the user. MCP provides a way to call application functions; risk limits still need enforcement in the execution system.

For work on projects, data, tests and results, you can already connect an external agent to Studio. Connections are approved in Studio, access can be read-only, and only one session can hold write access at a time.

As the agent's tool catalogue grows, we plan to introduce Progressive Tool Discovery: searching for a tool and loading its description and parameters when needed. To investigate an entry, for example, the agent needs the chart and trades; export tools would only take up context at that point. Instead of receiving the entire catalogue with every request, it would load the functions relevant to the current step.

Updates, diagnostics and installing alpha.4

Studio can now use the website's release feed if GitHub is temporarily unavailable. Installer downloads still use the same versioned GitHub URLs, with size and SHA-256 checks. The fallback helps Studio obtain release information; it does not make the website an independent mirror of the installers.

Optional diagnostics now cover update checks, displayed offers, verified downloads and installation outcomes, as well as a limited set of startup and process-failure categories. Installation success is reported only after the expected version starts with its engine and core ready.

Consent policy 4 explains those outcomes and the country code derived by the receiving server. Previous Allow and Ask Later choices require a new opt-in; previous denials remain denied. Disabling diagnostics clears queued reports. Raw logs, local paths and credentials are excluded.

Seven distributions are available: a Windows x64 installer and portable archive, macOS archives for Apple Silicon and Intel, and DEB, RPM and tar.gz packages for Linux x64. This is an early public release. Intel Macs require macOS 14 or later; the download page lists macOS 12 or later for Apple Silicon. The older Windows release, 0.0.91, remains in the release archive.

Code signing is still an open issue. Windows packages have no Authenticode certificate. The macOS packages are ad-hoc signed, without Apple Developer ID or Apple notarization. Operating-system trust warnings are therefore expected. Obtaining the required certificates is currently difficult for Russian developers, and we are working on that issue. There is no announced resolution date. The signed checksum list provides a separate way to verify files; it does not replace the application signatures trusted by Windows or macOS.

The full release notes describe the checks performed and their limits. Native macOS execution and Gatekeeper acceptance remain unverified. Linux checks ran under Ubuntu in WSL2/Xvfb, not across every listed distribution. Availability of a package and the extent of platform testing are different claims.

There is also a known update limitation. The update helper restarts Studio with default launch options. If you use --user-data-dir, --extensions-dir or --shared-data-dir, reopen Studio through your original shortcut after updating. Your files are preserved, but those arguments are not carried over into the automatic restart.

You can download XTester Studio now. A strategy whose behavior you already know is a useful starting point: retain the old test conditions, inspect any affected executions and start a separate AI Lab investigation for the next hypothesis. To help shape the portfolio plans, describe a specific scenario: which strategies need to share the account, how their risk should be limited, and what the user needs to be able to override.