Strategy workflow

Keep research, strategy versions, backtests and operating modes distinct.

Build and revise through Chat

1. Open Terminal, select the intended chart tab, and choose Chat.
2. Describe the asset or screening universe, evaluation interval, entry, exit and size. For example: “For this token on 15-minute bars, buy when the fast moving average crosses above the slow one; exit on the reverse cross. Use 10% allocation. Build and backtest it.”
3. Read the assistant's assumptions and the strategy in Code. The Code panel is read-only; request edits in Chat. On desktop, Code opens as soon as the assistant starts working on a strategy, and the source then appears line by line as it is written. Validation runs once writing finishes, and the saved revision then replaces the live view. On mobile web there is no Code panel: open a completed backtest card's Results and choose Code to read this chat's current source. It is read-only and can be newer than the recorded result you opened; Code is unavailable until the chat has a strategy. If writing stops before the strategy is saved, Code returns to the last saved revision. Reloading the page during writing also shows the last saved revision; the live view is not stored.
4. Ask for a specific revision, such as “Change the exit to a 5% stop and rerun.” One session holds one current strategy; follow-ups revise that source. To compare ideas, ask for several variations, such as “Try 4 variations with different lookbacks.” The assistant runs them one after another as revisions of this strategy, backtests each, lists every result together, and tells you which variation the strategy is now on; ask it to return to the one you want before saving. Use a separate chat for a separate idea. If you ask for a second strategy in the same chat, the assistant keeps the current one and tells you so rather than starting another draft; open a new chat for it.
5. Inspect validation and the backtest result for the final revision. A failed run or validation warning is not a successful test. You can explicitly ask to build without backtesting.
6. Save the reviewed revision using the save flow. A later conversation edit does not prove that the saved record or an existing deployment was updated.

Warnings belong to the source revision that produced them. In a long conversation, ask the assistant to reread the current session source and its validation warnings before treating an earlier warning as fixed. A shortened conversation summary, a valid source or a completed backtest does not by itself prove that the strategy matches the requested selection rules.

Recover an interrupted edit

If the connection or assistant worker stops after a strategy edit was saved, recovery can recognize that exact saved revision without applying the edit twice. The same applies when the assistant rewrote the whole strategy. It verifies the recorded edit, current revision and source before continuing. Validation or automatic date advice may still need to run again; recovery of an edit is not a completed backtest.

If the source changed afterward, or an older interrupted edit has no saved execution receipt, recovery stops for reconciliation instead of guessing. Ask the assistant to inspect the current source and revision before requesting another edit. Do not repeat an uncertain write just because its earlier response was missing. This applies to session strategy edits on desktop/mobile web in both Paper and Real money; it does not replay orders, repair historical edits, update saved strategies or change deployments.

The agent brings up relevant charts and plots indicators through explicit chart actions. Strategy creation, revision and backtesting do not automatically copy internal calculations onto charts. Ask for a missing study on an exact asset and interval; a dynamic screen name is not itself a chartable token. Backtest results and Replay still show the run's recorded trades, independently of which studies the agent plots.

Resolve source validation errors

In Terminal → Chat, ask the assistant to reread the current source and its diagnostics; use the read-only Code panel to inspect the revision. For uniquely named rules, signals and derived series, the diagnostic's line points to the affected declaration or expression rather than the start of the whole list.

• Unknown identifier after a rename: ask the assistant to update the intended dependent references as well as the declaration. Validation does not automatically propagate a rename or choose a replacement for you.
• Stateful calculation in a rule: calculations that need earlier bars, such as PCT_CHANGE, must be declared as a boolean signal or numeric derived series, then referenced by name in the rule. Moving only the declaration without updating the rule leaves the error in place.
• Duplicate description or argument: keep one intended value. The diagnostic identifies the first and repeated lines; the compiler does not silently discard one.

Request the correction in Chat, then inspect validation for that exact final revision. Better error locations do not make invalid source executable, change a saved version or deployment, or replace a backtest.

Fixed tokens and dynamic screens

A fixed strategy names exact assets. A dynamic strategy re-evaluates a supported on-chain screening plan at each strategy bar close and selects one or a ranked set of tokens. State the chain, filters, ranking, holding rule, sizing and what should happen when no token qualifies. Entry selection and the policy for an already-owned token are separate decisions. Unless you ask otherwise, the agent builds a screened strategy so that each purchase is its own trade: it is sized from the account at that moment and keeps the token it bought until its own exit, whatever the screen picks next. Ask to rotate if you want to always hold the screen's current pick; see what rotation does to position size.

For Solana selection strategies, the agent normally includes crash-risk and already-collapsed-token filters unless you explicitly ask for different thresholds or an unfiltered strategy. It should disclose these filters. Unknown scores do not qualify. A volume floor helps avoid selecting assets with too little trading to exit. These are filters, not guarantees of profit or sellability; see Strategy reference.

Which tokens a screen can pick

A new screen considers every token on its network that traded in the 10 minutes before each decision, so that an order has a recent price to fill at. That is the only built-in requirement. Everything else is a filter written in the screen, which the agent discloses and you can change or remove by asking:

• at least $10,000 traded in the last hour and at least 10 different wallets trading in the last hour, unless you name your own activity filters. Without a wallet floor a screen lets through tokens moved by one or two large transfers an hour, which then have no price to trade at;
• on Solana, the crash-risk, already-collapsed and $1M market-cap filters described above;
• tokens Astral cannot trade are skipped: those that trade only on exchanges or pool types Astral does not route through, are still on their pump.fun bonding curve, are tokenized stocks, or whose issuer can mint, freeze, charge a transfer fee or run code on transfers.

Because the screen ranks the whole network, the first backtest of a new screen over a month of hourly decisions takes a few minutes; later runs of the same screen are faster. Ask for "steadily traded tokens only" to use the stricter rule instead: trading in 48 of the last 60 minutes, a trade in the last 2 minutes, buys and sells each at least 5% of volume, and 20 wallets with $100 of turnover. It leaves out most of a network, including large tokens that trade in bursts, and its backtests are faster. Strategies built before this change keep the rule they were built with.

Check what a screen's ranking picks

A screened strategy buys the token its screen ranks first, so the ranking decides most of its result. Before building, or after a screened backtest loses money, ask the assistant what the screen's picks did next, for example "does ranking by one-hour gain pick better than the screen's average?" It replays the screen at every hour of a past period (up to 31 days) and reports, for holds of 1, 4 and 24 hours by default:

• the screen average: the average of every token the screen matched at each decision. This is what the filters alone returned, whatever the ranking;
• the tokens ranked 1st, 2nd, 3rd, 5th, 10th and 20th, and equal baskets of the top 3, 5 and 10;
• how much the first pick beat or trailed the screen average, how often, and week by week;
• the best and worst first picks, which you can open on a chart.

Read the median as well as the mean: a positive mean with a negative median is a few large wins among many losses. Returns are before trading costs unless you ask for a cost per side, and assume your order does not move the price. Holds longer than the step between decisions overlap, so they are not independent samples. A token that never trades again after the hold counts as a total loss, as in a backtest.

This study covers screens of on-chain tokens; perpetual and crypto-pair screens are tested with a backtest. A month of hourly decisions usually takes a few minutes, and each decision keeps the first 100 tokens the screen matched, so on a broad screen the screen average is of those. The result also counts picks that had no price to buy at within an hour of the decision; a high share means the screen admits tokens that barely trade. The study has no exits, sizing, cash or compounding, so it does not replace a backtest, and a ranking's past picks do not predict its next one.

From a result to automation

Open Deploy from the saved strategy or completed result, confirm the mode/account and capital, then read the final confirmation. Notifications-only, Paper and real-money execution have different effects. Real-money confirmation can include moving funds or paying a shortfall by card before deployment. Follow Saved and deployed strategies for confirmation and stopping steps.

A confirmed backtest deployment in the same Terminal session opens its existing Live view. Use the compact Live / Backtest toggle to switch performance views; Backtest shows the backtest saved with the strategy and is disabled only when it has none. On desktop, hover Live for the strategy name, Paper/Real mode and deployment status, also available to screen readers. Pause next to the toggle pauses the strategy after a confirmation; resume, stop and other lifecycle actions are under Strategies → Deployed. Reconnect appears with a live-data error in the performance chart and only retries data. See Confirm and monitor in Terminal for status, recovery and desktop/mobile boundaries.

Research and specify

Identify the token by network and address. Inspect available market context, then describe the interval, entry, exit and sizing. Confirm that the engine supports the required data and actions. Do not assume a token's research coverage includes every strategy operation.

Review and test

Inspect generated code and revise any unclear rule. Run a backtest against available history. Read the effective window, warmup, cost assumptions and individual trades alongside aggregate performance.

For a strategy with fixed assets, the assistant states the indicator warmup (in bars) when it validates or edits the strategy, before any backtest. The number comes from the strategy's longest indicator period or lookback; there is no separate warmup setting to change. Warmup bars feed the indicators but are not simulated, so a longer lookback shortens the period a fixed date range actually evaluates. Screened strategies warm up each token on its own history, so no single number is given for them; the backtest reports the result.

Save and share

Save a version before iterating. Publishing makes an item available according to its visibility; it does not deploy the strategy. Public examples may come from earlier product workflows, so check asset compatibility before copying or running them.

From Saved, choose View in terminal to open that snapshot's source and result together in a fresh session. Reloading restores the saved snapshot. Opening it does not change an existing deployment. The Code panel shows settled source without a streaming cursor after restore.

Ask the assistant to make an editable copy before changing a saved snapshot. After checkout, the terminal and subsequent reloads show that session copy; the original saved strategy stays unchanged until you explicitly save an update.

To keep the saved version and also keep an edited one, choose Save as new copy once a strategy is saved and has a backtest result. On desktop, use the copy icon next to the save control in the chart actions. On mobile web, open the strategy chart in Fullscreen, open its top-right menu and choose Save as new copy. It is not offered while viewing a live deployment or a published strategy. The dialog suggests your strategy's name followed by “copy”, which you can change; choose Save, review Confirm Copy, then choose Save Copy. This saves a separate strategy, leaves the earlier saved version as it was, and the chat continues on the copy. The copy counts toward your saved-strategy limit. A failed save offers retry; verify the success state before leaving. You can also ask the assistant to save the current revision as a new copy. Plain Save on a saved strategy still updates that saved record.

Publish an indicator from Chat

You can ask the assistant to publish an indicator you made in the chat or already saved in your library. It asks you to confirm the title and visibility first, and publishes nothing until you agree. Visibility defaults to link (only people with the link can open the page); say so if you want it public and listed on Explore. Only expression indicators you own can be published, and an indicator from the chart is saved to your library first. The assistant returns the share path (/indicator/…) when it is done. Publishing an indicator does not deploy anything; see Explore & Sharing.

The assistant can read a saved source that references a removed metric. It is labeled read-only with validation diagnostics; inspection does not make it executable. Review an explicit replacement before checking out, editing or rerunning it.

Select an operating mode

Use paper mode where supported before considering live activity. Review the selected account, capital and authorization. The UI and service determine whether an execution mode is available; a subscription does not enable unsupported markets.

A deployed live strategy can act under configured permissions without an individual prompt for every event. Inspect entries, exits and risk controls before authorizing it.

Monitor and stop

Follow the latest status, signals and transactions. Liquidate & Stop attempts to close strategy-owned positions before undeploying; Stop & Undeploy is for an eligible flat strategy. Wait for the actual result, inspect remaining exposure, and check wallet permissions separately. Neither action reverses an already submitted transaction.

See Backtesting, Orders, and Wallets.