Help Center

Getting Started with VTX Macro

⚠️ EXPERIMENTAL SOFTWARE & RISK WARNING

VTX Macro is an experimental AI trading tool in active development. AI models can hallucinate, misunderstand market conditions, and make unpredictable trades leading to rapid financial loss.

By using this software, you acknowledge:

• The AI can and will make mistakes.
• You should only trade with money you can afford to lose. Do not use rent money, savings, or crucial funds.
• You are entirely responsible for your trades. The developers of VTX Macro are not liable for any losses incurred. Set strict conservative limits before enabling automated trading.

Welcome to VTX Macro, your advanced AI-powered trading platform. This platform is designed to help you automate your trading strategies using cutting-edge AI models and real-time market analysis. Whether you are looking to automate trades or get intelligent market insights, VTX Macro provides the tools you need.

For the shortest setup path, open Start, next to Help in the navigation whether you are signed in or signed out. It lets you choose a guided chatbot explanation, a connected VTX Insights agent, or manual setup before you return here for the full details.

For community help, use Join Telegram on Start, Help, or the FAQ page.

For quick answers about costs, models, bot decisions, and public results, read the FAQ. It is available without signing in; this Help page covers the detailed setup steps and settings.

Quick start

These steps get your first bot running on VTX's default settings. Each step links to the full details further down this page. If a chatbot such as ChatGPT, Claude, or Gemini is helping you, it can follow these steps with you; paste keys only into VTX, never into a chat.

1. Choose your starting amount. We recommend starting with $100. The default bot settings are tuned for that amount, and starting small gives you time to see how the bot behaves (how often it trades, how long it holds, and how it handles losing streaks) before you consider a larger amount. Only trade money you can afford to lose.
   • $100: keep the defaults: a Unit Size of 20 USDC and 10 Max Units, so the bot holds at most about $200 in positions.
   • Less than $100: that works too. Keep 10 Max Units for more risk (at 3x leverage, the bot can only open as many units as your balance has margin for), or use about one Max Unit per $10 for the same risk as the defaults. For example, with $50, use 5 Max Units.
   • More than $100: raise Max Units first, by about one for each extra $10, until you reach 20 Max Units at about $200. Above that, keep 20 Max Units and raise Unit Size instead. For example, with $500, use 20 Max Units with a Unit Size of about 50 USDC.
   • You set these on the AI page in step 8. Max Units means all four unit limits: Max Units (Global), Max Units Per Exchange, Max Units Per Asset, and Max Units Per Cycle. With one market, give them the same number.
2. Create your VTX account. Select Get Started and sign up with Google or email. If you use email, open the verification link we send you, then log in. Your first profile is created for you and starts in Client Mode, which is free from VTX.
3. Open VTX on the computer that will run your bot. In Client Mode, your bot runs while the VTX desktop app or a VTX browser tab stays open and signed in on that computer, so keep it awake (how). Do the next steps on that computer.
4. Add an AI model key. Create a free Google AI Studio key (steps) and paste it on the System page under Bring Your Own Key. The default model, gemma-4-31b-it, uses this key. You can use another provider's key and model instead.
5. Fund a Hyperliquid wallet. (full steps)
   • Use a wallet such as Rabby, MetaMask, or Trust Wallet, and keep it for VTX only.
   • Send your USDC and a little ETH for gas to that wallet on the Arbitrum network.
   • Connect the wallet at Hyperliquid, make sure its account type is Manual, then use Hyperliquid's Deposit to move your USDC into Hyperliquid. Check that it shows in your Perps balance.
6. Create an API wallet. On Hyperliquid's API page, name the API wallet, select Generate, and copy its private key. Then select Authorize API Wallet, choose how many days it stays valid, and approve it with your main wallet. An API wallet can trade for you but cannot withdraw your funds.
7. Connect Hyperliquid in VTX. On the System page, enter your main wallet address (the one holding your funds) as Wallet Address, and the API wallet's private key as Private Key. VTX checks them without placing an order.
8. Review the defaults. The default bot trades HYPE at 3x leverage, reads 1d, 30m, 4h candles, and analyzes the market every 60 seconds. The Tradability filter starts on: the bot opens a position only on setups it rates at least 7 out of 10 and adds to one at 7 or higher. Built-in guardrails also push back on overtrading and choppy markets. Stop loss starts off, take profit off, the kill switch off, and the trading schedule off; while stop loss and take profit are off, the AI manages its own exits. You can change any of these on the AI page, along with the Unit Size and Max Units from step 1. See all defaults.
9. Start your bot. On the Trade page, select Start under Trader in the AI panel. Once it runs, the profile shows a live status pulse and the bot's analyses appear in the AI panel. Its open trades appear under Positions and its fills under Trade History. Keep VTX open on this computer while you want the bot to run.

How It Works

VTX Macro connects to your Hyperliquid account to execute trades on your behalf. Our AI engine analyzes market data, identifies trends, and executes strategies based on your configuration. The system operates in real-time, ensuring that you never miss a trading opportunity.

• Real-time Analysis: Continuous monitoring of market conditions.
• AI Execution: Automated trade execution based on AI signals.
• Risk Management: Built-in safeguards to protect your capital.

Account Sign-In Options

You can sign in with email/password, passkeys and two-factor authentication, or Google when Google sign-in is available.

Google sign-in is used only to verify control of your email address and sign you in to VTX Macro. VTX does not request, store, display, or depend on your Google profile name, profile photo, contacts, Gmail, Drive, Calendar, files, or any non-auth Google scope.

Optional: Free Google AI Studio BYOK Setup

If you want a low-cost starting model, you can use Google AI Studio's free Gemini API tier with Gemma 4 31B (gemma-4-31b-it) as your VTX Macro BYOK model. Google makes Gemma 4 available in Google AI Studio and through the Gemini API, and its pricing page currently lists Gemma 4 input and output tokens as free on the free tier.

Important: do NOT add a credit card or enable billing for this setup. Keep each Google AI Studio project on the free tier. Adding billing moves the project into a paid tier, which changes the token/request limits and can make usage billable under Google's current rules. If you want a paid Google setup later, create a separate paid project so your free-tier bot projects stay isolated.

Create the Google AI Studio key

1. Sign in to Google AI Studio with the Google account you want to use.
2. Open API Keys.
3. Create a new project or use the default project AI Studio creates for new users.
4. Create an API key for that project and copy it once.
5. Do not click billing, upgrade, Google Cloud free trial, or credit-card prompts for this free-tier project.

Google AI Studio rate limits are project-scoped, not key-scoped. Creating more keys inside the same project does not create more free capacity. For VTX Macro, use one Google AI Studio project per bot so each bot has its own project quota.

Add it to VTX Macro

1. Go to the System page.
2. Open Bring Your Own Key (BYOK).
3. Find Google Gemini and paste the AI Studio key into Key 1.
4. Save the System page.
5. Go to the AI page.
6. Set the preferred model to Gemma 4 31B / gemma-4-31b-it with source Google Gemini.
7. Start with one bot, watch for rate-limit warnings, and keep the Review Model off or on a separate provider/project while testing because reviewer calls consume additional provider quota.

With one free Google AI Studio account, users can potentially run up to 5 VTX Macro bots by creating up to 5 separate Google AI Studio projects and using one project/API key per bot. Treat this as practical free-tier guidance, not a guarantee: Google can change available models, token limits, request limits, and abuse controls at any time, so always check Google AI Studio -> Rate limits for each project before leaving bots running.

Setting Up Hyperliquid

To use VTX Macro, you need to connect your Hyperliquid account. Follow these steps carefully to ensure correct configuration:

Before You Connect

You need a crypto wallet that can connect to Hyperliquid, such as Trust Wallet, Rabby, MetaMask, or another wallet you trust. This will be your main wallet: it holds your funds, connects to Hyperliquid, and authorizes the trading-only API wallet you later add to VTX Macro.

Before opening Hyperliquid:

1. Create or open your wallet and make sure you control the recovery phrase.
2. Send USDC to that wallet on the Arbitrum network. For example, you might start with 100 USDC if that is the amount you are comfortable testing with.
3. Send a small amount of ETH to the same wallet on the Arbitrum network for gas. For example, about $0.25 of ETH on Arbitrum is enough for typical setup transactions, though gas needs can change.
4. Go to Hyperliquid, connect that wallet, and deposit your USDC as described in the steps below.

Double-check the network before sending funds. USDC and ETH must arrive on Arbitrum, not Ethereum mainnet or another chain, for this setup flow.

IMPORTANT: Account Type Requirement VTX Macro only supports Manual account mode on Hyperliquid. This is the required setup because perp collateral, account equity, drawdown, and strategy history are easier to reconcile consistently.

• Manual account mode (required): You explicitly deposit USDC into the matching Hyperliquid Perps balance before trading.
• Why Manual: Hyperliquid's own account-mode guidance recommends this account setup for market makers, high-volume automated users, and builders. VTX follows that automation-oriented guidance instead of trying to run bots through account modes whose balances and cross-margin behavior are harder to reconcile safely.
• Unified Account, Portfolio Margin, and HIP-3 DEX Abstraction (not supported): VTX Macro does not support running bots through these Hyperliquid account modes. The System and Trade surfaces reject unsupported account modes instead of silently treating them as normal perps accounts.
• HIP-3 perp DEX markets: Some Hyperliquid perp markets are builder-deployed DEX markets. VTX shows clean labels such as GOLD-USDC or USA500-USDC with a small DEX pill such as xyz or cash; technical/API/debug symbols may still appear as xyz:GOLD or cash:USA500.
• One wallet per exchange/DEX: Use a separate main wallet and API wallet for each venue you trade with VTX Macro, such as default Hyperliquid Perps (hl), xyz, cash, or any other HIP-3 perp DEX. Do not mix default Perps and multiple DEX venues on one VTX wallet. Keeping them separate makes balances, positions, PnL, history, and risk controls much easier to reconcile.

Current Unified Account Scope:

• Existing profiles are not automatically changed or removed.
• Some compatibility behavior may still appear in the app, but official support is paused because Hyperliquid's current Unified Account API behavior is not reliable enough for supported bot operation.
• To use VTX Macro, switch the wallet to Manual account mode, disable HIP-3 DEX Abstraction, and keep USDC in the specific Perps balance for the market you trade.

How to Switch Between Account Types: If you want to switch from Unified Account mode to the supported Manual account mode:

1. Go to the Hyperliquid App.
2. Open Portfolio.
3. Click Account Type in the Portfolio action bar.
4. Choose Manual. If Hyperliquid documentation or older UI copy uses names like Standard or Classic, use the current app's Manual account type for VTX Macro.
5. To use the supported Manual setup, make sure Unified Account, Portfolio Margin, and HIP-3 DEX Abstraction are not selected. Manually transfer USDC in Hyperliquid to the correct destination: Perps for default markets, or the matching Perps (xyz) / Perps (cash) style balance for a HIP-3 DEX market. VTX Macro does not move collateral between Spot, native Perps, and HIP-3 DEX balances for you.

1. Connect to Hyperliquid: Go to Hyperliquid and connect your main trading wallet (for example, Rabby or another wallet from the list above). This is the wallet that holds your funds.
   • Strongly recommended: Use a separate Hyperliquid wallet for VTX Macro only, and dedicate that wallet to one exchange/DEX venue. For example, do not use the same VTX wallet for default Hyperliquid Perps (hl) and xyz or cash markets. For the best experience, do not manually trade on the same wallet while VTX Macro is using it. Outside activity on the same wallet can make the app's wallet balance, PnL, and trade history appear incorrect. A bot's account and exposure checks cover only default Perps and the venues of the symbols selected on its AI page, so it does not see orders or positions on other venues of the same wallet; outside activity there is your responsibility.
2. Deposit your USDC: Use Hyperliquid's Deposit to move the USDC from your wallet on Arbitrum into Hyperliquid. Check that it shows in your Perps balance (or the matching DEX balance, such as Perps (xyz), for a HIP-3 DEX market). If it shows under Spot instead, transfer it to Perps in Hyperliquid.
3. Generate API Wallet: Open Hyperliquid's API page (More → API), enter a name for the API wallet, and select Generate.
   • This will provide you with an API Wallet Address and a Private Key.
   • Copy the Private Key immediately, as it may not be shown again.
   • Select Authorize API Wallet, choose how many days it stays valid, and approve the request with your main wallet. Hyperliquid may require funds in the account before it accepts the authorization.
   • When the API wallet expires, create and authorize a new one, then replace the Private Key in VTX.
4. Configure VTX Macro: Go to the System page on VTX Macro.
5. Enter Credentials:
   • Wallet Address: Enter your MAIN Wallet Address (the one with the funds), NOT the API wallet address.
   • Private Key: Enter the API Wallet Private Key you just generated.

CRITICAL: The "Wallet Address" field must be your Main Wallet Address (where your funds are). The "Private Key" is the signer key from the API wallet. If you enter the API wallet address as the main address, the system will not be able to find your funds or execute trades correctly.

Verification & Requirements

To ensure security and proper configuration, the system performs a read-only credential check.

• No Test Order: Verification does not place or cancel an order.
• Authorization: Hyperliquid confirms that the signing key belongs to the wallet or is an authorized agent for it.
• Account Read: VTX Macro reads the selected account state to confirm the wallet is available.
• Purpose: This prevents a signing key for one wallet from being used with a different profile wallet.

Security & Fund Custody

Agent Tokens

Agent tokens let CLI and MCP agents act as your authenticated user with only the scopes you grant. The easiest setup is vtx auth login, which opens a browser approval page and saves the approved token locally for the CLI and MCP server. If it says your CLI version can no longer sign in, update with npm install -g @vtxmacro/cli and run it again.

• Browser login stores the approved token in the local CLI token file.
• Use the smallest scope set that fits the job. For example, a status-only agent usually needs read access, while a trading agent needs explicit trading or bot-control scopes.
• Use vtx auth logout --revoke on that machine when you want to remove its CLI/MCP access.
• Revoking a token removes future access, closes its private live-update connection after the next authorization check, and stops any headless Client Mode runtime lease tied to that token.
• Client Mode agents use your own compute, provider access, and exchange access and do not add a VTX platform fee. Server Mode bots started by agents use VTX infrastructure and normal Server Mode fees.

Using The CLI

The VTX CLI is for users who want to manage profiles, check bot status, run a headless Client Mode runtime, or connect VTX Macro to local automation.

Install the VTX CLI on the machine that will run the agent:

npm install -g @vtxmacro/cli

The CLI and its MCP server keep themselves up to date. Every few hours, a vtx or vtx-mcp start checks npm for a newer release, verifies it, installs it in your VTX folder (~/.vtx/cli-update, no administrator rights needed), and runs your command on it. vtx-mcp prepares the update in the background and uses it at its next start, so a connected agent is never interrupted. A new release that fails to start is rolled back and skipped. If your CLI is older than VTX supports and cannot update (for example, offline), it stops and shows the command to update it. Set VTX_CLI_AUTO_UPDATE=0 to turn automatic updates off; installs that npx or a project manages are left to that tool.

1. Choose scopes for the job:
   • Read-only/status: read
   • Create or revoke tokens: token:write (new tokens can only receive scopes this token already has)
   • Edit profiles or bot settings: profile:write
   • Start or stop bots/runtimes: bot:control
   • Place or cancel orders: trading:execute
   • Write provider or exchange credentials: secrets:write
   • Run headless Client Mode with local secret hydration: secrets:hydrate
2. In a terminal on the machine that will run the agent, set the API URL and profile if needed:

export VTX_API_URL="https://api.vtxmacro.com"
export VTX_PROFILE_ID="<profile-id>"

3. Log in:

vtx auth login --scopes read,bot:control,trading:execute,secrets:hydrate

The CLI prints an approval link and opens your browser. Sign in to VTX Macro if needed, approve access, then return to the terminal.

4. Verify access:

vtx --json auth whoami
vtx --json bots status

Common CLI commands:

# Read status and recent bot logs
vtx --json bots status
vtx --json bots logs

# Configure and start a Server Mode bot
vtx --profile <profile-id> bots configure --symbol BTC --timeframe 15m --size 100
vtx --profile <profile-id> bots start

# Run headless Client Mode locally
vtx --profile <profile-id> runtime run --follow

# Run one local Client Mode cycle, useful for testing
vtx --profile <profile-id> runtime run --once

# Stop the local runtime lease
vtx --profile <profile-id> runtime stop

Headless Client Mode runs on your machine with the same runtime as the Trade page: cycles follow the bot's trading interval, and the main model, review model, fallbacks, copy trading and safety controls behave as they do in the app. --once runs one cycle right away and then stops the bot; pressing Ctrl+C stops the bot while this run is the one running it. If you took the bot over in the app or another terminal in the meantime, Ctrl+C ends only this run and the bot keeps running where you moved it. Closing the terminal or SSH session ends a --follow run without stopping the bot, as closing the app does (a --once run stops the bot, as it would after its cycle): it stays set to run, so another of your devices or Server Mode Backup can take it over. To keep a run going after you disconnect, run it in tmux, screen or as a service. Your machine must stay online, and any local AI server or provider access used by that runtime must also be reachable from that machine. If Server Mode Backup takes the bot over while the machine is offline, --follow waits and takes the bot back once the machine is ready again, as the app does, including after a restart of vtx runtime run --follow on that machine. Pressing Ctrl+C while it waits ends only this run; the backup keeps running the bot.

Direct CLI trade commands require a Server Mode profile. For Client Mode, use the app's Trade controls or the headless runtime, which keep exchange execution on the durable local path. A trading scope does not enable the legacy server order commands for a Client Mode profile.

Using MCP

MCP lets compatible agent apps call VTX tools directly instead of shelling out to individual CLI commands.

1. Make sure the VTX MCP command is installed on the same machine as your agent app.
2. Log in once with the CLI on that machine:

vtx auth login --scopes read,bot:control,trading:execute,secrets:hydrate

3. Configure your MCP-compatible agent app to start this command:

vtx-mcp

The MCP server reads the same saved token and environment settings as the CLI. If your agent app lets you set environment variables for an MCP server, set VTX_API_URL and VTX_PROFILE_ID there too.

MCP tools follow the same permissions as the CLI. Examples include vtx_whoami, vtx_profiles_list, vtx_bots_status, vtx_bots_start, vtx_runtime_events, vtx_trade_market_order, vtx_secrets_status, and vtx_ai_config. If a tool fails with a permission error, run vtx auth login --scopes ... again with the missing scope or revoke the old token and start over with a narrower, correct scope set.

Keep Agent Tokens private. Anyone with the token can use the scopes you granted until the token expires or you revoke it.

Is my money safe? Can VTX Macro withdraw my funds?

Yes, your money is safe, and no, VTX Macro cannot withdraw your funds. The platform is strictly non-custodial, meaning your capital remains securely protected by Hyperliquid's native cryptographic boundaries.

When you configure the platform, you provide an API Wallet (Agent Key), not your main wallet's private key. Hyperliquid's protocol enforces strict, mathematical limitations on what an Agent Key can do:

• What it CAN do: Place orders, cancel orders, and adjust leverage (known as L1 trading actions).
• What it CANNOT do: Withdraw funds, transfer USDC, or move assets to another account.

Withdrawals and transfers are "User-Signed Actions" that can only be authorized by your Main Wallet (e.g., your MetaMask or Rabby extension).

Because of this architectural design, even in the absolute worst-case scenario—if your VTX Macro account or the platform itself were fully compromised—your funds mathematically cannot be withdrawn or stolen. The maximum risk exposure from a leaked API key is strictly limited to unauthorized trading activity within the exchange.

System Settings

The System page is the central configuration hub for your VTX Macro environment. From here, you can manage your trading profiles, connect your exchange accounts, configure AI providers (BYOK), and personalize your user settings.

Note on Defaults: Looking for the default AI parameters (Timeout, Tokens, etc.)? These are listed in Global Platform Defaults, not on the System page.

Trading Profiles

Profiles allow you to create isolated environments for different trading strategies or purposes. Each profile maintains its own:

• Exchange Connection (Wallet Address)
• AI Preferences (Risk tolerance, active models)
• Trade History & Performance Metrics

Managing Profiles

• Create: Click the + button to create a new profile. Each account can have up to 100 profiles total.
• Switch: Click on any profile card to make it active. The entire application (Trading, Analysis, Settings) will context-switch to this profile.
• Emoji: Click the slot before a bot's @handle to pick an emoji for it; click the selected emoji again to remove it. Hover an emoji to see its name (for example Owl or Crescent Moon); agents can assign an emoji by that name too. The emoji then appears before that handle everywhere it shows: Trade, the AI panel, the profile selector, History, Analytics, Changelog, the Leaderboard, browser tab titles, and Telegram notifications. Bot emoji are public: everyone sees them, on your bots and on everyone else's, so people can follow and compare a set of bots by its emoji, and anyone can reuse an emoji they like. Use it to group bots, for example one emoji per set of bots you are comparing; several bots can share one. The emoji button left of Running bots only filters by emoji, and clicking the selected emoji again clears the filter. On the Leaderboard it shows every bot with that emoji, or only yours when My bots only is on. On Analytics it appears in Account and Platform: Account shows that account's bots with the emoji, and Platform shows every bot on the platform with it. Analytics and the Leaderboard share the filter, like Running bots only. Sorting by Profile on Trade (Positions, Open Orders, Trade History, Funding History, Order History) or by Trader on the Leaderboard groups bots by emoji, in the order the picker shows them, then by handle; bots without an emoji come after them.
• Handle: Each public profile handle is 3-20 letters, numbers, underscores, or hyphens. The leading @ is displayed by the app and does not count toward that limit.
• Delete: Remove a stopped profile from your profile list. Deleted profiles cannot be restored and are excluded from your Account and Profile analytics views. Their public handle resets to a new default @trader-… handle, which releases the old handle for reuse, while the profile identity, public Leaderboard entry, and historical Trades and Volume remain part of platform totals. A wallet-backed profile must first have a published Leaderboard snapshot so deletion cannot strand its public history.
• Execution Mode: Any profile can use Client Mode or Server Mode. The account's 100-profile total limit is the only profile-count limit; execution mode does not reduce that allowance.
• Profile Start and Stop: In Server Mode, the profile controls start or stop the VTX-hosted runtime. In Client Mode, those same controls save what the profile should do without making the System page the runtime owner. If no eligible app currently owns the profile, a VTX toast explains that the request is waiting for Trade to establish ownership. Stop remains authoritative even when a different window owns the runtime: after Stop succeeds, System clears the matching saved recovery intent in that browser, and browser or desktop recovery cannot restart that profile until you send a new Start request.
• Exchange outages: Start and Stop do not require live Hyperliquid data. Start checks your saved configuration and, in Server Mode, your stored connection, then accepts the request to run. If exchange data is unavailable, the runtime waits and retries; it still requires usable exchange data and valid trading authority before placing orders. Stop prevents that runtime from resuming until you request Start again.

Exchange Connection (Hyperliquid)

Connect your Hyperliquid account to enable live trading. See Getting Started for the full step-by-step guide on generating these credentials.

• Wallet Address: Your primary Hyperliquid address (e.g., 0x...). This is used for monitoring balances and positions.
• Private Key: The API Wallet Private Key generated on Hyperliquid's API page.
  • Note: Do not use your main wallet's private key. Always use an API Wallet key, which is restricted to trading only and cannot withdraw funds.

VTX uses the profile's public wallet address for read-only balance, position, and risk-monitoring account reads. The API wallet private key stays encrypted in that profile and is available only to profile-scoped exchange operations; it is not copied into or sourced from platform environment configuration.

Before the profile has any fills, funding, or account-ledger history, you can stop its runtime and correct or remove the wallet address. Once VTX records that economic history, the wallet address is permanently linked to the profile and the Wallet Address field becomes read-only. You can still stop the runtime and replace or remove an expired API wallet private key; a replacement key must be authorized for that same main wallet. A validated replacement key can be saved while existing protective orders remain active, without cancelling those orders. VTX still blocks changes while an exchange action or protective-order update is awaiting confirmation. Changing the wallet address or removing its signing key also remains blocked by active protective orders. VTX rejects credential changes while the profile is running so an in-flight Client or Server action cannot cross from one signer to another.

Strongly recommended: Use a dedicated Hyperliquid wallet for VTX Macro only, and dedicate each wallet to one exchange/DEX venue. For example, use one wallet for default Hyperliquid Perps (hl) and separate wallets for xyz, cash, or other HIP-3 perp DEX markets. Avoid manually trading on that wallet or using it for separate strategies while VTX Macro is running. Outside activity or mixed venue activity on the same wallet can make the app's wallet balance, PnL, and trade history appear incorrect. A bot's account and exposure checks cover only default Perps and the venues of its AI-page symbols, and its Trade page lists only the positions and orders on the venues selected in its Exchanges panel on the AI page, and on the DEX of the market the chart shows. It does not see orders or positions on other venues of the same wallet.

Unsupported Hyperliquid account modes: If the connected wallet is detected in Unified Account mode, the System page shows a red warning. VTX trading support is for Hyperliquid Manual account mode only. Hyperliquid's own account-mode guidance recommends this setup for market makers, high-volume automated users, and builders, and VTX follows that automation-oriented guidance for bot safety and reconciliation. Portfolio Margin and HIP-3 DEX Abstraction are also unsupported. Disable those modes in Hyperliquid before running bots.

HIP-3 DEX collateral: HIP-3 perp DEX markets can use separate balances such as Perps (xyz) instead of the default Perps balance. VTX can show and route the selected market identity, but it does not transfer funds between Spot, default Perps, and DEX-specific Perps balances. Move collateral in the Hyperliquid interface before trading that market, and keep each VTX wallet dedicated to one of those venues.

Bring Your Own Key (BYOK)

VTX Macro is Bring Your Own Key (BYOK) only. To run the bot or use any AI generation feature, connect API keys from the providers you want to use. There is no platform-key mode or account-level BYOK switch. If the active profile does not have a key for the selected provider, VTX stops the request and asks you to add one instead of using a VTX-owned provider key.

VTX Macro handles the trading workflow, runtime controls, model selection, analysis history, and safety layer around those provider accounts. Provider-managed usage, rate limits, model access, and provider bills remain in your provider account.

Each profile can store up to five keys for the same BYOK provider. The System page shows configured provider keys as Key 1, Key 2, and so on. VTX tries the keys in the visible order for the selected provider and model within that model's timeout before moving to the next eligible model in the profile's Model cascade. A fallback provider must also have its own key on the profile; VTX never reuses one provider's key for another provider. Keys stay masked after saving, and clearing a key removes it from that provider's order.

Your API keys and Hyperliquid signing key are stored encrypted on VTX. In Client Mode, your device fetches them when your bot runs and signs every exchange request from your own connection. A Hyperliquid API (agent) key can trade but cannot withdraw funds. A running Client Mode bot picks up changes to its provider keys before its next analysis, without restarting. That refresh never replaces the bot's exchange signing key, and if the updated keys cannot be loaded, the analysis does not run with the old list; a later cycle retries.

Supported Providers

VTX Macro groups cloud AI connections under one BYOK provider experience while keeping each provider's API key and model routing separate. The app currently tracks 17 BYOK providers and a synced catalog of 1147 available AI models:

• Providers: Alibaba Cloud Model Studio, Amazon Bedrock, Anthropic, BytePlus, Cerebras, DeepSeek, Fireworks AI, Google Gemini, Groq, Lightning AI, Mistral, Moonshot/Kimi, OpenAI, OpenRouter, Together AI, Venice AI, and xAI.
• Google keys: Google Gemini keys can be limited to different Google API surfaces. Some keys call the Gemini / Generative Language API, while Vertex AI Express keys call Vertex's aiplatform.googleapis.com API. Prefixes such as AIza and AQ. are useful hints, but the exact API restrictions attached to the key are what determine where it works.
  • VTX Macro routes Gemma 4 models through the Gemini / Generative Language API because Vertex AI Express does not currently expose the Gemma 4 publisher-model endpoint for normal API-key calls. Use a Google key that is allowed to call the Gemini API for Gemma 4.
  • Google AI Studio, Gemini API, and Vertex AI can price or limit the same Google model differently. Treat displayed prices as guidance and confirm the Google pricing and rate-limit page for the API surface your key is allowed to use.
  • For the free Google AI Studio Gemma 4 setup, do not add a credit card or enable billing on that project. Billing changes the project's tier, limits, and billing behavior. Keep paid Google experiments in a separate project from free-tier bot projects.

Every row in the AI page's Model cascade uses the full model selector. Available choices come from synced provider catalogs and the local or external connections configured for your profile.

Native Provider Plans

Subscriptions and pay-as-you-go access use the same BYOK settings and model selectors. Add your provider API key and choose its matching plan where offered:

• BytePlus: choose Coding Plan for an active subscription or Pay as you go for usage charged to your BytePlus account balance. Use your ModelArk API key from the BytePlus console. Adding wallet credits does not activate a Coding Plan subscription. The plans have separate model catalogs: Coding Plan includes aliases such as ark-code-latest, which follows the model or automatic selection configured in your BytePlus console; pay-as-you-go models use their own model IDs. Existing BytePlus keys keep Coding Plan selected until you change it. To allow wallet fallback, add a second entry with Pay as you go selected after the Coding Plan entry. You can enter the same ModelArk key in both entries if it has access to both services. Without a pay-as-you-go entry, VTX does not switch to wallet billing. In browser Client Mode, your device runs the workflow and sends requests for either plan through VTX. The request and API key pass through VTX for forwarding to BytePlus.
• Alibaba Cloud Model Studio: choose Coding Plan (Singapore) or Token Plan (Singapore) for that subscription's key. Both key types can start with sk-sp-, so the prefix alone does not identify the correct plan. Keep ordinary pay-as-you-go keys on their matching regional endpoint. Custom region URLs must not include embedded credentials, query parameters, or fragments. Server-side model discovery and inference require a public HTTPS endpoint; private and loopback destinations are rejected. Local AI continues to use Client Mode.
• Moonshot/Kimi: choose Kimi Code for a Kimi Code subscription key, or Pay as you go for a Moonshot platform key. The two services have different model catalogs and credentials.

In Server Mode and browser Client Mode, VTX follows the visible key order and keeps the plan selected for each entry. A later entry must support the selected model ID: adding a pay-as-you-go entry does not translate subscription aliases into different models. Different providers can require different credentials for their subscription and pay-as-you-go services.

Your provider determines which models your subscription can use and when its quota resets. A subscription does not make every model from that provider available. Save the key in Bring Your Own Keys, as with other BYOK connections.

Displayed token prices and prompt costs are informative estimates of what usage would cost at the corresponding published token rates, even when a subscription covers the request. They are not your subscription invoice or a measure of remaining quota. Unavailable rates follow the usual - display; they are not treated as free.

What BYOK gives you:

• Provider choice: Use the providers, model families, and account tiers you already trust.
• Your own provider limits: Requests use your provider account, so available throughput, model access, and rate limits come from your provider plan.
• Execution-mode privacy: In Server Mode, prompts go from VTX Macro servers to the provider. In Client Mode, your browser or desktop app owns the workflow. Provider requests normally go directly from your device; BytePlus browser requests pass through VTX as described above. VTX Macro keeps status, history, and settings in sync.
• Predictable VTX billing boundary: You pay the provider directly for provider-side API usage. In Server Mode, qualifying trader calls are billed with the flat VTX Macro platform fee of $0.0025 per AI trader call, but prompt/run cost displays stay raw and do not include that flat fee. In Client Mode, VTX Macro is free forever and does not add a platform fee because your browser/device runtime sends the model request. Insights and Trade Analysis calls are exempt from the trader-call fee. You must maintain a positive VTX Macro credit balance for billable server-side activity.

Execution Mode

Each trading profile runs in one of two execution modes. Your choice determines where the AI runs, how your API keys are stored, and uptime guarantees.

How to Select Execution Mode

On the System page:

1. Select or create a trading profile.
2. Look for the Execution Mode control in the profile card (typically near the top or profile settings).
3. Click the mode selector to toggle between Server (Purple badge) and Client (Blue badge).
4. The selection is saved automatically per profile.

Indicator: A colored status badge shows the current mode:

• Purple badge = Server Mode
• Blue badge = Client Mode

Server Mode Backup

For a Client Mode profile, the Server Mode Backup card on System lets you enable Use Server Mode when my client is unavailable. It is off by default and saved separately for each profile.

Enabling backup checks that its required credentials are available on the server. If anything is missing, the toggle stays off and a toast explains what to configure.

When enabled, VTX can temporarily run an already-started Trader or Assistant on the server after its client host becomes unavailable. Takeover waits for the previous client ownership to expire and a further grace period, so it is not immediate. Your other open devices take over first (see Automatic Failover Between Your Devices); the server is the last fallback. It returns to Client Mode when the bot's device is back and ready: the device you last pressed Start on (or, if there is none, the device that last ran the bot), in the browser or desktop app signed in to your account, or vtx runtime run --follow on that machine (still running, or started again). Stopping the bot still stops it; backup does not restart a bot you stopped.

Normal Server Mode fees, credit requirements, credentials, model availability, and capacity limits apply during backup. Enabling backup does not reserve a server slot. If free Google server slots are full, backup waits for capacity. Likewise, a settings preview checks whether an active Server Trader can switch to a free Google model with the capacity available now; it does not reserve a slot, and the final update checks again. A model or credential available only on the disconnected device cannot be used by the server.

The enabled backup toggle is blue while standing by and purple while backup is actively running. The System mode selector stays on Client during backup; runtime indicators use the usual Server Mode colors until the client takes over again.

Profile Selector and Runtime Pulse

On profile-scoped pages, the top navigation bar includes a compact profile selector. Open it to switch between your profiles without leaving the current workflow.

On AI, Analytics, Models, Billing, Security, and Screener, the browser tab title follows the profile in the page URL when you switch profiles or use the browser's Back and Forward buttons.

The selector can also show a small runtime pulse next to a profile handle:

• A visible pulse means that profile has a live AI Assistant or AI Trader runtime signal.
• The pulse follows the profile, not only the page you are viewing. If a bot is running for @Example, the indicator can still appear when you are switching from another profile.
• The menu is intentionally compact on desktop and mobile; long handles are clipped instead of stretching the whole menu.

Security Page

The Security page is where you manage sign-in safety for your account.

• Authenticator: Set up or remove app-based two-factor authentication.
• Email 2FA: Use your account email as a second sign-in factor. Request a code on the sign-in screen, then enter it in that same sign-in flow. If the sign-in attempt expires, choose Back to login and sign in again before requesting another code.
• Passkeys: Add, rename, or remove passkeys for faster secure sign-in.
• Sessions: Review signed-in browser and desktop sessions, including the device, IP address, start time, expiration time, and any active Client Mode profile labels tied to that session. While any of your bots is running, your sessions do not expire, so you are never signed out mid-run. Once every bot is stopped, sessions expire normally.
• Revoke: Remove one session if you do not recognize it. Revoking a session also stops Client Mode bots tied to that session and closes its private live-update connection after the next authorization check. Expired sessions cannot keep receiving private live updates.
• Terminate All Sessions: Sign out every browser and desktop session, revoke every CLI/MCP agent token and every connected Insights app or agent authorization, and stop Client Mode bots tied to that access. Passkeys and authenticator-app 2FA are preserved so you can sign in again.

Sensitive credential changes may ask you to sign in again when your current session is no longer recent enough. Changing or resetting your password signs out every session and revokes every CLI/MCP agent token and connected Insights app or agent authorization. If you believe an authenticator was added by an attacker, use password recovery and select Remove passkeys and authenticator-app 2FA. The option is off by default, and email 2FA remains enabled.

CLI and MCP Access

VTX Macro can be controlled from automation tools such as Codex, Claude Code, and other MCP-capable clients through the VTX CLI and vtx-mcp server. This uses your normal VTX account permissions: agent tools do not get extra hidden access, and profile-scoped actions still need the selected profile ID.

What Agents Can Do

With the right token scopes, an agent can:

• List, create, rename, or delete your profiles. Deletion removes a profile from your account views while retaining its public trading history.
• Read or set each bot's public emoji, and narrow a selection of your bots or the whole platform to the bots with one emoji, as the Leaderboard and Analytics filter does.
• Switch a profile between Client Mode and Server Mode.
• Configure AI Trader settings such as symbol, timeframe, size, leverage, and loop interval.
• Start, stop, check status, and read logs for Server Mode AI Trader bots.
• Read Client Mode runtime status and runtime events.
• Add or rotate runtime secrets such as provider API keys or Hyperliquid API-wallet keys. Secret responses stay masked.
• Place or cancel manual trade orders only when you explicitly grant trade execution access.

Setup Flow

1. Install the VTX CLI package on the machine where your agent runs.
2. Run vtx auth login --scopes read,bot:control for a read-and-control setup, or add only the extra scopes you actually need.
3. Approve the browser login prompt while signed in to VTX Macro.
4. Verify the connection with vtx --json auth whoami.
5. Point your MCP client at the vtx-mcp command. Set VTX_API_URL for the target VTX API, and set VTX_PROFILE_ID when you want tools to default to one profile.
6. Ask your MCP client to list tools. You should see VTX tools such as vtx_profiles_list, vtx_bots_configure, vtx_bots_start, vtx_bots_stop, vtx_runtime_status, and vtx_trade_market_order.

Scope Guide

• read: profile lists, runtime status, events, billing visibility, AI config, and history reads.
• profile:write: profile changes, preference changes, and execution-mode changes.
• bot:control: start or stop Server Mode bots and start Client Mode runtime sessions.
• secrets:write: write or rotate runtime secrets.
• secrets:hydrate: allow a leased Client Mode runtime to hydrate the secrets it needs locally.
• trading:execute: place or cancel orders through the same Trade page safety checks, risk rules, rate limits, and duplicate-order protections.

Start with the smallest scope set that matches the task. For example, a status-only setup needs read; a user managing a Server Mode bot usually needs read,bot:control,profile:write; direct order placement requires trading:execute.

Server Mode vs. Client Mode From Agents

MCP tools can configure profiles and start or stop Server Mode AI Trader bots. Server Mode runs on VTX Macro servers and uses normal Server Mode billing and limits.

For Client Mode, the headless runtime is launched with the CLI command vtx --profile <id> runtime run --once or vtx --profile <id> runtime run --follow. It runs the same Client runtime as the Trade page: the same schedule, prompt, models (including the review model and fallbacks), copy trading and safety controls. The runtime acquires a lease, runs provider and exchange work locally on that machine, reports decisions and executions back to VTX Macro, and stops cleanly if it loses ownership. MCP can read Client Mode runtime status/events, while the actual long-running local runtime should be started with the CLI.

Safety Notes

• Agent tokens authenticate as you. Treat them like account credentials.
• Raw tokens are shown only once during creation or login approval. Store them in the CLI token file, not in chat prompts or MCP config text.
• Use vtx auth logout --revoke when you no longer want that machine or agent to have access.
• If you grant trading:execute, the agent can submit real orders within normal VTX and exchange constraints.

Desktop App Settings

When you are using VTX Macro Desktop, the System page includes a Desktop App card. These controls affect only the desktop app on the current device:

• Start at login: Launch VTX Macro Desktop after you sign in to this computer.
• Start minimized: Open the app in the background after startup.
• Close to tray: Hide the desktop window instead of fully exiting when you close it.

These controls are hidden in a normal browser tab. The desktop app uses the same VTX Macro pages and profile settings as the browser, so you do not need to configure separate trading or AI settings for desktop.

Mode Comparison

Aspect	Server Mode	Client Mode
Runtime Location	Runs on VTX Macro servers	Runs in your browser or desktop app
API Key Storage	Encrypted in VTX Macro	Encrypted in VTX Macro; your device fetches them while your bot runs
Uptime	24/7 continuous (even with browser or desktop app closed)	Only while the browser or desktop app session stays open
Key Privacy	Keys stay encrypted with VTX Macro	Provider requests normally authenticate directly; BytePlus browser requests forward the key through VTX
VTX Cost	Premium paid mode using VTX credits	Free forever from VTX
Best For	24/7 trading, always-on monitoring	Privacy-first users, testing, limited sessions
Resume After Close	N/A (always running)	Best-effort auto-resume if intent was active

When to Use Each Mode

Choose Server Mode if:

• You want your AI Trader running 24/7 without needing to keep a browser tab open.
• You prefer VTX Macro to securely manage your API keys.
• You need guaranteed uptime for continuous market monitoring.
• You are comfortable using VTX credits for premium server-side automation.

Choose Client Mode if:

• You want your own device to sign and send every exchange request.
• You're testing strategies for short sessions.
• You want to connect a local LLM (Ollama, LM Studio) for offline inference.
• You prefer browser-based execution for compliance or security reasons.
• You want the VTX runtime to be free forever and can keep your browser or desktop app open while it runs.

Multiple Client Mode Profiles in One Browser

Client Mode ownership is tracked per profile. In one browser window, you can start a Client Mode AI runtime for one profile, switch to another profile, and start another Client Mode runtime there. Each profile keeps its own runtime state and status pulse.

This does not make Client Mode a background server:

• The browser window or desktop app still needs to stay open and connected.
• Each profile still has one active owner at a time.
• Opening the same profile in another window or on another device can take over that profile's runtime.
• Taking over one profile does not automatically stop unrelated profile runtimes that the original window still owns.

Automatic Failover Between Your Devices

If you keep VTX open on more than one device, such as the desktop app on your PC and a browser on your laptop, your Client Mode bots keep running when one device goes down. There is nothing to set up.

• Home device: the device where you last pressed Start for a bot (or confirmed a Take Over) is that bot's home device.
• Failover: when the device running a bot stops responding for about 5 minutes, another of your open, signed-in devices takes the bot over automatically. If several are ready, the home device goes first, then a device on wall power before one on battery, and the desktop app before a browser.
• Low battery: a device running on battery below 15% that is not charging never takes a bot over automatically. Pressing Start on it still works.
• Returning home: when the home device comes back and stays ready for a short while, it takes its bot back between AI cycles, never in the middle of one or while an order is still being confirmed.
• Your choice wins: pressing Start on another device makes that device the new home device, so nothing moves the bot back afterwards.
• A device takes a bot over only if it can run it there: a local model that runs only on the device that went down cannot be used elsewhere.
• With Server Mode Backup on, the server takes over only when none of your devices can.

The System page can request Client Mode Assistant or Trader Start/Stop for any profile, but it does not silently move ownership into the System window. Open that profile on Trade to establish ownership or use Trade's existing Take Over action when another window owns it. A Start-request toast means the intent was saved; the existing runtime status indicator shows when the bot is actually running.

If Stop is requested while an order, cancel, or leverage update is already being confirmed, the bot is marked stopped immediately but ownership can remain briefly reserved until the exchange action settles. VTX blocks new work and sensitive mode, wallet/key, profile, or takeover changes during that safety window. If the browser loses the response, VTX keeps the profile protected through the signed expiry and releases the fence only after a new exchange check started after expiry confirms that no effect was observed.

Keep Your Device Awake for Client Mode

Client Mode runs from the browser window or desktop app that owns the profile. If the operating system sleeps, hibernates, suspends network access, or aggressively pauses the app, the local runtime can miss cycles until the device wakes and reconnects. Before relying on Client Mode for an active session, keep the device powered and configure sleep settings for the machine that owns the runtime.

Windows:

• Open Settings > System > Power & battery.
• Under Screen and sleep, set When plugged in, put my device to sleep after to Never while Client Mode is running.
• If you run on battery, choose a longer battery sleep timeout or keep the laptop plugged in.
• In Control Panel > Power Options > Choose what closing the lid does, make sure closing the lid does not put the computer to sleep if you expect the bot to keep running.
• Optional command-line setup: open PowerShell as Administrator and run powercfg /change standby-timeout-ac 0 to disable plugged-in sleep.

macOS:

• Open System Settings > Battery.
• On desktops, open Energy Saver if it appears; on laptops, review Options and Power Adapter settings.
• Enable Prevent automatic sleeping when the display is off when available.
• Set display and sleep-related power adapter settings so the Mac stays awake while plugged in.
• Keep the lid open, or use an external display, keyboard, mouse, and power adapter if you run a Mac laptop in clamshell mode.

Linux:

• In GNOME, open Settings > Power and set Automatic Suspend to Off for plugged-in sessions.
• In KDE Plasma, open System Settings > Power Management and disable sleep/suspend for AC power.
• If your distribution uses systemd sleep controls, advanced users can review systemctl status sleep.target suspend.target hibernate.target hybrid-sleep.target before changing system policy.
• Make sure laptop lid-close behavior does not suspend the machine if the runtime must continue.

Also check browser-level energy features if you run Client Mode in a browser tab. Chrome, Edge, Safari, and Firefox can reduce background activity under battery saver or memory saver modes. Keep the VTX Macro tab open, avoid force-quitting the browser, and disable browser energy saver for long Client Mode sessions when needed. VTX Macro Desktop startup and tray settings can help reopen the app after login, but they do not override operating-system sleep.

Local AI & Client Mode

Local AI models (Ollama, LM Studio, etc.) require Client Mode because they run on your machine via loopback. See Local AI below for setup instructions.

OpenAI-Compatible Endpoint

Use OpenAI-Compatible Endpoint on the System page for a provider that accepts an API key and exposes an OpenAI-compatible API. Enter the provider's full API Base URL, including its path, and click Apply before Test & Refresh. Explicit API paths such as /api/coding/v3 are preserved. A URL containing only a host uses /v1.

Test & Refresh requests the model list at the configured API base plus /models; choose a returned model on the AI page. The test runs from your browser, including in Server Mode, so the provider must allow browser requests (CORS). HTTP authentication errors, missing model endpoints, invalid responses, and browser/network failures are reported separately. A successful model-list test does not verify inference or subscription eligibility.

If an older saved URL has an unwanted /v1 after the provider's API path, correct the Base URL and apply it again. A saved key stays with the server it was entered for: if you change the Base URL to a different host, enter that endpoint's key again (switching back to a previously saved endpoint restores its key). Removing a URL from the Base URL history forgets only that URL's saved key; other remembered URLs keep theirs, and the active connection is cleared only when it uses the removed URL.

Local AI (Ollama, LM Studio, llmster)

The Local AI card on the System page connects to local servers through their OpenAI-compatible API, including LM Studio / llmster, Ollama, llama.cpp, vLLM, and SGLang.

Use Quick setup to fill the default loopback Base URL for LM Studio / llmster, Ollama, llama.cpp, vLLM, or SGLang. Choose Custom for another OpenAI-compatible server. You can edit the URL after choosing a preset. Selecting a preset updates the form only; it does not install or start a server, save the connection, choose a model, or configure model capabilities.

Important rules:

• Local AI requires Client Mode for the active profile.
• The recommended Base URL is loopback on the same device as the browser, with the server's OpenAI-compatible /v1 API path.
• Test & Refresh reads /models at the configured API base and loads the returned models for the active endpoint so they appear on the AI page.
• Inference uses the OpenAI-compatible /chat/completions endpoint at that API base. Ollama uses this same contract.
• For Ollama, keep the full returned tag when present, for example my-local-model:latest.
• Apply saves endpoint access only. Choose the active main and review models on the AI page.
• An optional API key stays with the server it was saved for. If you change the Base URL to a different host or port, enter that server's key again. Switching back restores its saved key.
• Removing a URL from the Base URL history forgets only that URL's saved key. Other remembered URLs keep their keys, and the active connection is cleared only when it uses the removed URL.
• Older connections saved with the removed native Ollama mode must be configured again: select Ollama in Quick setup, Apply, then run Test & Refresh.

Quick start

1. Install and start your local server with its OpenAI-compatible API and browser access enabled.
2. Choose the matching Quick setup preset, or choose Custom and enter the API Base URL.
3. Adjust the URL for your server's actual listening address and port. Enter an API key only if your server requires one.
4. Click Apply to save the endpoint, then run Test & Refresh to load its models.
5. Choose the Local AI main and review models on the AI page.

The LM Studio / llmster preset supplies the usual connection defaults for llmster.

For llmster in browser Client Mode, a working startup command is:

lms server start --bind 127.0.0.1 --port 1234 --cors

For Ollama, a practical flow is:

ollama pull qwen3:8b
curl http://127.0.0.1:11434/v1/models

If you already have a GGUF file and want Ollama to serve that exact model, create a Modelfile:

FROM C:\path\to\your-model.gguf

Then import it:

ollama create my-local-model -f Modelfile

Ollama normally exposes browser-usable loopback CORS headers already, so it does not usually need an LM Studio-style --cors startup flag.

Loopback Forwarding for Another LAN Machine

Keep VTX Macro pointed at localhost / 127.0.0.1 on the browser device and run a local TCP forwarder on that same device. The browser should not depend on arbitrary LAN IP targets directly.

This means:

• The remote machine runs Ollama, LM Studio, or llmster.
• VTX Macro still uses loopback locally.
• The user's device forwards the local port to the LAN machine.

Why VTX Macro still uses loopback

VTX Macro's hosted app runs in a secure browser context over HTTPS. Modern browsers treat direct requests from an HTTPS page to a private LAN HTTP address such as http://192.168.x.x:1234 as restricted mixed-content / private-network traffic. Depending on the browser, that can be blocked outright or require extra CORS and private-network headers that many local model servers do not provide.

Loopback addresses such as 127.0.0.1 and localhost are treated specially by browsers and are the most reliable way to connect Local AI from Client Mode. This is a browser security boundary, not an app setting that VTX Macro can disable.

Example topology

• Browser / VTX device: your main desktop or laptop running the VTX Macro tab.
• Model server device: another PC on your LAN running LM Studio, Ollama, or llmster.
• Remote model server example: <remote-lan-ip>:1234
• Local loopback forward example: 127.0.0.1:1235 -> <remote-lan-ip>:1234
• VTX Base URL: http://127.0.0.1:1235/v1

You can keep port 1234 on the remote machine. If 1234 is already used on the browser device, choose another local port such as 1235 for the forwarder.

Windows loopback setup

Windows has a built-in TCP forwarder:

netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=1235 connectaddress=<remote-lan-ip> connectport=1234

Check the rule:

netsh interface portproxy show all

Test it:

curl http://127.0.0.1:1235/v1/models

Remove it later if needed:

netsh interface portproxy delete v4tov4 listenaddress=127.0.0.1 listenport=1235

macOS loopback setup

Install socat if it is not already available, then forward a local loopback port to the LAN machine:

brew install socat
socat TCP-LISTEN:1235,bind=127.0.0.1,fork TCP:<remote-lan-ip>:1234

Test it:

curl http://127.0.0.1:1235/v1/models

Keep the socat terminal running while you use VTX Macro.

Linux loopback setup

Most Linux distributions can use socat as well:

socat TCP-LISTEN:1235,bind=127.0.0.1,fork TCP:<remote-lan-ip>:1234

Test it:

curl http://127.0.0.1:1235/v1/models

Keep the socat process running while you use VTX Macro. If your distro does not include socat, install it from your package manager first.

What to enter in VTX Macro

After the forwarder is working, keep the Local AI card pointed at the local loopback URL on the browser device:

• http://127.0.0.1:1235/v1 for the forwarded remote machine example above
• http://127.0.0.1:1234/v1 if the model server is running on the same device as the browser

User Profile

Manage your public identity on the platform.

• Handle: Your unique @username (e.g., @trader-alpha). This is visible on public leaderboards and public Trade Analysis links. You can change this periodically.
• Identity: Displays your registered email and account role.

Notifications

Get Telegram messages and desktop notifications about your bots. Notifications only control what you are told; they never change how a bot trades, and they cost nothing.

Connect Telegram

1. Open System > Notifications and press Connect Telegram.
2. Telegram opens a private chat with the VTX Macro bot. Tap Start to finish. The link works once and expires after 10 minutes.
3. Press Send test message to check that messages arrive.

You connect once for your whole account. Only private chats can be connected, so your alerts never reach a group. Pause stops messages until you resume; nothing that happens while paused is sent later. Typing /notify pause in the chat also pauses, and /notify resume resumes. Disconnect removes the chat and discards any messages still waiting. If you block the bot, VTX stops sending and asks you to connect again.

Commands in Telegram

Type / in the connected chat to see the commands with a short description of each:

• /status: how many bots are running out of all of them, as Client and Server Mode counts too, with total equity and the last 24 hours' PnL and ROI; then each set of bots sharing an emoji, with the set's equity, 24h PnL and ROI and one aligned row per bot (equity, 24h PnL and 24h ROI, plus its state when it is not running, such as Disconnected); then the stopped bots by name. /status all lists stopped bots in their sets too. The numbers are the ones VTX last recorded, as on the Leaderboard (a Client Mode bot's come from its device).
• /notify: your settings at a glance: the default types for Telegram and the desktop, then each group of bots whose settings differ from the defaults with what it adds (+) or leaves out (-), then the bots switched off. When every bot uses the defaults it says so in one line.
• /notify @name: one bot's notification types, each with its Telegram and Desktop setting and its short name (buy, sell, hold, filled, tpsl, hard, notrunning, and so on).
• /notify @name off hold sell: switch types off (or on). Group names (decisions, executions, copy, errors, status) switch every type in the group. Add desktop to change desktop notifications instead of Telegram.
• /notify @name off: switch all of a bot's notifications off (or on), keeping its choices, like the switch at the top of the card.
• /notify reset @name: return a bot's choices to the defaults and switch it on, like the reset arrow.
• /notify pause and /notify resume: stop and restart all Telegram messages.
• /help: every command with examples.

Name bots with @name, several names, an emoji you gave your bots (every bot with that emoji), or all. If you connected more than one VTX account to the same chat, commands cover the bots of all of them. Reply to a notification to use its bot without naming it: /notify off as a reply switches off that notification's type for that bot. Commands change the same settings as this card. /status reads what VTX already has; it never contacts the exchange.

Desktop Notifications

The Desktop column sends notifications to your computer: to the VTX Macro desktop app when it is open, otherwise to an open VTX Macro browser tab, never both, and only one tab shows each. Every type starts off. Turning one on in a browser asks that browser for permission to show notifications; if the browser blocks them, allow notifications for VTX Macro in its site settings. Desktop notifications are live: something that happens while neither the app nor a browser tab is open is not shown later, so use Telegram for alerts you must not miss. A desktop notification shows the bot and what happened; open the app for the full card.

What You Get

Each notification type has a Telegram switch and a Desktop switch, and the card shows which start on. Messages use the same wording as the app:

• AI decisions: the full AI panel card for a Buy, Sell, or Hold, including models, timing, cost, tokens, and the complete reasoning. Assistant cards keep their A badge.
• Executions: an order that filled, an order that was rejected, failed, left with an unknown outcome, or blocked for safety, and TP/SL/trailing stop fills. An execution message arrives as a reply to its decision. A fill that closes a position shows its Closed PNL with its percent of the bot's equity without that profit or loss. Blocked by Tradability starts off: a Buy or Sell below the bot's own Tradability minimum places no order, and the decision arrives with no follow-up. Turned on, the block follows as a reply to its decision, as it appears in the AI panel.
• Copy trading: copied orders that executed, failed, or were skipped, with their copy card.
• Errors: hard errors (such as an invalid key) are sent once and not repeated while the bot keeps failing the same way. Transient errors (rate limits, provider outages, timeouts) are sent only after the bot has gone 3 cycles and 10 minutes without a successful cycle. Every transient error sends each one instead.
• Bot status: a bot you set to run that is not running (for example its browser or desktop app closed, or it is blocked until you fix something), the same bot running again, a kill switch stop, and Server Mode Backup taking over or handing back.

Every message starts with the bot's name and what happened, so chat previews and phone alerts show it. AI cards then show their models with timing, cost, and tokens, and every message ends with when it happened, in your timezone. The bot name, models, symbols, and fill amounts are in bold, stats in italics, the time in bold italics, and a bot going offline or live again is set off in stars. Long messages are split into several parts, never shortened. Events from before you connected are not sent.

Each Bot Chooses Its Own

Notification choices belong to each profile, so each bot can send different messages. The card shows the choices of the profile you are viewing on the System page; switch profiles to change another bot's. New profiles start with the defaults. The switch at the top right of the card turns all of this bot's notifications off or back on; its choices are kept while it is off. The reset arrow beside it returns the choices to the defaults and switches the bot on. The profiles icon left of the arrow, Apply to all profiles, gives every other bot on your account exactly this bot's settings, including the switch and both columns, after you confirm. Every bot's messages arrive in your one connected Telegram chat.

A connected Insights agent with the Manage settings permission can read every bot's Telegram and Desktop choices, apply one change to many bots at once, pause or resume, send a test message, start a connection, or disconnect. Connecting always finishes with you tapping Start in Telegram.

Trade Display

Hide trading controls is off by default, so the Trade page's order form and Deposit, Perps ⇄ Spot, and Withdraw actions are visible. Enable it to hide these controls across profiles for your account. Open Trade pages animate the controls in or out when you change this setting, without a reload. Trading controls remain visible when signed out. The controls use the same transition pace as the homepage leaderboard entrance. These transitions are skipped when your device requests reduced motion. AI settings panels, animated numbers, scrolling snapshot names, loading pulses, pull-to-refresh motion, and decision-chat scrolling also respect that preference. Numbers show their final values immediately.

The right-hand panel retains account information, AI controls, and footer links. Position closing, position TP/SL, and order cancellation remain available independently of this setting.

Regional Settings

• Timezone: Configure the display timezone for all charts, logs, and timestamps.
  • Auto: Detects your browser's timezone.
  • Manual: Force a specific timezone (e.g., UTC) for consistent reporting.

Timezone settings apply across your account. A connected Insights agent with the Manage settings permission can change them; Auto still follows the device displaying VTX, which the agent cannot see.

Trading Interface & AI

The Trade Dashboard

The Trade page is your command center for both manual execution and AI supervision. It combines professional-grade charting with direct exchange execution and AI controls.

1. Market Overview & Charting

• Asset Selector: Use the dropdown in the top-left to switch between markets (e.g., BTC, ETH, SOL). HIP-3 Hyperliquid perp DEX markets use the same clean pair labels, such as GOLD-USDC, with a small DEX pill such as xyz; technical/debug contexts may still show canonical symbols such as xyz:GOLD.
• Advanced Chart: A fully interactive candlestick chart with adjustable timeframes (1m to 1w) and drawing tools. Your chart settings, drawings, zoom, and visible dates are saved automatically for your account. Switching symbols or timeframes saves the resulting view too. Reloading the app or recovering interrupted chart data preserves your view.
• Customizable Layout: You can resize the Chart, Order Entry, and Bottom Panel sections to suit your workflow.
• Profile Selector: Use the profile selector in the top navigation bar to switch the Trade page between profiles. The selector can show a small runtime pulse beside profiles with a live AI Assistant or AI Trader signal, so you can see which profile is active even before opening that profile.
• All Profiles View: If your account has more than one profile, the Trade page shows an All toggle beside the profile selector. Turn it on to view profile-owned positions, orders, history, AI activity, account equity, perps overview, and AI controls for every profile on the same page.
• Runtime Ownership: Client Mode bots are owned per profile. If a profile is already running in another browser, desktop app, or headless runtime, the Trade page shows the current ownership state and lets you take over when that is safe. If the device running a bot goes down, another of your open devices takes it over automatically, and the device you started it on takes it back when it returns (System > Automatic Failover Between Your Devices).
• Start requests from other pages: System can save a Client Mode Start request, but it does not take ownership. Trade remains the place where your app establishes ownership or explicitly takes it over. A saved request can wait until an eligible owner is available, and the normal runtime indicator confirms when execution actually starts.
• Desktop pickup: An open, signed-in desktop app can pick up saved Client Mode Start requests across your profiles, including after a switch from Server Mode. Previously saved local start state does not require another manual Start. Existing runtime owners and explicit Stops remain protected.
• Recovery waits: Client Mode waits between failed recovery attempts and respects account-key request cooldowns. Switching profiles does not skip that wait. If a required key is missing, add it in System. Startup fetches the profile's keys from VTX. An explicit Stop prevents automatic recovery from starting the bot again.
• Startup errors: If automatic recovery cannot start a profile, its Trade AI panel shows the setup error, such as a missing model or signing key. The error does not mean the runtime has acquired ownership. Successful startup or an explicit Stop clears the active error; its entry can remain in the AI history.
• Errors that need your action: If the profile has no wallet address, or Hyperliquid does not accept the profile's private key (the key is not valid, or its API wallet expired or was never authorized for the profile wallet), automatic recovery stops retrying instead of looping. The bot keeps its saved Start request and the Trade AI panel shows what to fix; when you pressed Start on the System page, System shows it too. Add the wallet, or authorize an API wallet on Hyperliquid (More → API), paste its private key in System > Hyperliquid Configuration > Private Key (Secret), save, then start the bot again. The key belongs to the profile, so one fix covers every device, and the same message appears when you save the key, switch to Server Mode, or an order is refused for this reason.
• In-flight exchange actions: Client Mode orders, cancels, and leverage updates are registered before they are sent. While Hyperliquid is still confirming one of these actions, VTX can temporarily block Take Over, mode, wallet/key, or profile changes. If confirmation is uncertain, do not retry the trade blindly; VTX keeps it fenced until fresh exchange evidence confirms the result or, after the signed request expires, a new exchange check confirms that no effect was observed.

2. Manual Order Entry

Manual trading controls are visible by default, including when signed out. Turn on Hide trading controls on the System page to hide them across profiles for your account. Open Trade pages animate the controls in or out when you change this setting, without a reload.

Deposit, Perps ⇄ Spot, and Withdraw appear with the order controls. The right-hand panel keeps its account information, AI controls, and footer links. Position closing, position TP/SL, and order cancellation remain available in the bottom panel.

The order controls include:

• Order Types:
  • Market: Execute immediately at the best available price.
  • Limit: Set a specific limit price. Limit orders rest as GTC (Good Til Cancel) in both Server and Client Mode; IOC and ALO (Post-Only) are not available yet.
  • Pro: Scale (laddering) splits the size evenly across the price range and rests each order as GTC. Stop Limit, Stop Market, Take Limit, Take Market, and starting a new TWAP are listed but not available yet, so they cannot be submitted. To protect an open position, use Edit TP/SL in Positions. Existing TWAP orders still appear in the TWAP tab.
• Positions and orders shown: For each bot, the Trade page lists the positions and open orders on its exchanges: the DEXes selected in its Exchanges panel on the AI page, and the DEX of the market the chart shows. Positions and orders on other DEXes of the same wallet are not listed. Close All closes exactly the listed positions, and Cancel All cancels exactly the listed orders.
• Client Mode action scope: Manual Client Mode orders, cancels, leverage changes, and position closes require that profile to be selected. Select a profile before acting on its rows in All view. Scale, TWAP cancellation, and Close All are unavailable in Client Mode for now; place individual supported orders, cancel supported orders, or close positions individually instead.
• Leverage: specific leverage slider. Note: This leverage setting applies to both manual trades AND AI trades for this symbol.
• Size Inputs: Enter trade size in either Coin (e.g., 0.5 BTC) or USDC (e.g., $5,000).
• Collateral scope: Default Hyperliquid perp markets use the default Perps balance. HIP-3 DEX markets can require funds in the matching DEX-specific balance, such as Perps (xyz). VTX does not move funds between Spot, default Perps, and DEX-specific Perps balances. A bot can technically monitor and trade both native and DEX-specific perp markets in one wallet, but VTX recommends a separate wallet for each venue so balances, PnL, and history stay easy to reconcile (see Setting Up Hyperliquid). When one bot does trade several venues, its account prompt includes default Perps and the separate collateral pool of each selected market's venue; multiple symbols on the same DEX share that pool. The bot's account and exposure checks do not read venues outside its selected markets, and the Trade figures built from a running bot's reads show only default Perps and those venues; use Hyperliquid directly to see any other activity on the wallet. Position percentages use that DEX's equity, and fee estimates use each market's effective taker rate. Unavailable fees remain unavailable. The Trade account panel continues to follow the chart-selected market.
• Bot equity and performance: A bot's equity, drawdown, killswitch, ROI, leaderboard row, and equity history measure only the perp balances of the venues its selected markets trade on: default Perps for default Hyperliquid markets, the DEX-specific balance such as Perps (xyz) for HIP-3 markets, and the sum of those balances when it trades both. Money the wallet keeps on other venues never counts, so you can leave funds on one venue while a bot trades another. Changing a bot's markets to another venue starts a new equity series for it: Insights reports treat the switch as a rebase, not as a gain or loss; drawdown limits, the killswitch, and leaderboard performance windows start measuring again from the new venues. Moving money between a bot's venue and another balance of the same wallet counts as a deposit or withdrawal for that bot. Drawdown limits and the killswitch measure equity without subtracting deposits or withdrawals, so stop a bot before moving money off its venue, just as before a withdrawal; otherwise a large enough move can trigger its killswitch.
• Risk Tools:
  • Reduce Only: Sent with Market and Limit orders in both Server and Client Mode. The order can only reduce or close an open position, never increase or reverse it.
  • Max Slippage: Limits how far a Market order can fill from the estimated price. Your setting is saved for the selected profile. It applies to Market orders and to full and partial market closes in both Server and Client Mode.
  • TP/SL (Market orders): Turn on Take Profit / Stop Loss to attach a fixed take profit, a fixed stop loss, or both to a new Market order, in both Server and Client Mode. Set each as a percent distance from the average fill price or as a USDC profit or loss on the filled size, within the same limits as the AI page's Auto SL/TP. After the entry fills, VTX places reduce-only market triggers; when both are set they are grouped as position TP/SL. Your choices are saved for the selected profile. In Client Mode, if the fill cannot be confirmed right away, the TP/SL stays pending and this browser keeps retrying while VTX is open, unless the AI runtime (Trader or Assistant) is running for that profile here, in which case it finishes the TP/SL. If the position is already closed or reversed by then, the pending TP/SL is dropped. TP/SL cannot be combined with Reduce Only. Trailing stop loss is not available for manual orders yet, and Limit and Scale orders do not attach TP/SL; add or edit protection from Edit TP/SL in Positions.

3. Position Management

The bottom panel gives you full visibility into your account state:

• Positions Tab: View all active open positions, including Entry Price, Mark Price, Unrealized PnL, and Liquidation Price.
  • PNL (ROI): a position's unrealized PnL and its percent of the bot's equity without that PnL, measured on the venues its selected markets trade on (see Bot equity and performance), as its Leaderboard ROI is. It does not change with the market the chart shows; when the bot's equity on one of its venues has not been read, only the PnL shows.
  • Actions: "Close Market" (instant exit), "Close Limit" (queued exit), "Edit Leverage", and "Edit TP/SL".
• Open Orders: View and cancel working perpetual orders, including HIP-3 markets. For a Client Mode bot, your device reads positions and open orders on the venues you use: default Perps, the bot's Exchanges, and the venue of the market the chart shows. Positions and orders on other venues of the same wallet are not shown or included in Cancel All. Spot orders are excluded from this list and Cancel All; manage them on the exchange or in the app that placed them.
• Trade History: A log of your recent fills and executions.
• Funding: Track funding fee payments and receipts.

4. All Profiles View

The All toggle is a view mode, not a new profile. Your selected profile remains the chart and order-entry context, while the data panels expand to show every profile you own.

What changes in All view:

• A Profile column appears on profile-owned rows so you can see which profile owns each position, open order, TWAP order, trade, funding entry, or order-history row.
• Profile handles such as @Example are clickable. Clicking one opens that profile's normal Trade view.
• Duplicate symbols stay separate when they belong to different profiles. VTX Macro does not merge or summarize them.
• In Server Mode, row actions act on the row's profile. Client Mode keeps All view read-capable but requires selecting the row's profile before an exchange action, so another profile's local signer or durable action authority is never used implicitly.
• The right rail shows per-profile account equity, perps overview, and AI Assistant / AI Trader controls.
• Each account card is resolved from one coherent backend observation. A temporary live-read failure may reuse the profile's recent trading observation or retained wallet snapshot; account values are never inferred from AI prompt text. The selected profile uses the same resolver as All view.
• AI messages can appear together in the normal AI panel with profile labels, so you can compare what different profiles are doing without losing ownership context.
• When many profiles respond close together, every response appears immediately and the panel automatically shortens the card motion so the feed stays animated without building a visual backlog.
• Copy Trading messages also appear in the normal AI panel. CT rows show the copied trade result, while CR rows show the Review Model's approval or block using the same result-and-reasoning format as normal Trader review rows. Each message is one copy order, or the reason an order was not placed. Position checks that need no order show nothing.
• If Copy Trading remains active while the Main Model is disabled, the AI panel stays live for copied trades but does not show a countdown for a Main Model analysis that will not run. This is the same in Server and Client modes. An active AI Assistant keeps its own countdown.
• Orders that were not placed: when a safety control stops a decision's order, or VTX holds it back, its card says so in a box with the reason. Blocked by Tradability and Blocked by Protection Safety mean a safety control stopped it (for example, a leftover stop or take-profit order that would reduce the new position). Not placed means no order was needed or VTX held it back (for example, the position already matched the decision, the same order was placed seconds earlier, the order was too small to place, the bot was already at its position limit, or the cycle ended before the order was sent). Partly placed means the bot's position limit left room for only part of the order; the box says how many units were placed. Order failed means the order could not be sent, the exchange rejected it, or VTX could not confirm its result; the box gives the reason, and an unconfirmed order leaves the box once VTX confirms it was placed.
• Positions and the matching unrealized PnL come from the same profile snapshot, so a completed close clears both together instead of leaving an old PnL value behind.
• Position refresh continues automatically through temporary exchange delays, retaining previously loaded rows until fresh data arrives. Exchange reads needed for trading take priority over display refreshes.
• When a fill opens, reduces, or closes a position, the visible Trade History tab refreshes automatically. VTX retries saving received fills after temporary interruptions. Recent confirmed executions and filled automatic stop-loss/take-profit orders receive dedicated recovery opportunities even when ordinary history catch-up is busy, without requiring that profile to be selected. An executed trade can appear later in history while its exact fill details are being recovered; you do not need to reload the page or switch profiles.

The chart and order-entry form stay tied to the selected profile. Selecting a symbol from another profile can update the chart symbol, but it does not silently switch which profile manual orders would use.

---

AI Assistant

The AI Assistant acts as a "dry run" for the AI Trader. It runs the same analysis logic as the automated trader but does not execute any trades.

Execution mode matters: In Server Mode, the AI Assistant analyzes the market securely on VTX servers and can continue running in the background after you close the browser or desktop app. Server Mode is the premium paid runtime, and qualifying server-mode trader calls may be billed with a VTX Macro platform fee. In Client Mode, your browser or desktop app owns the analysis logic entirely on your device, meaning the Assistant only runs while that active app session keeps control. Client Mode is free forever from VTX and never charges a VTX Macro platform fee.

This allows you to see exactly what the AI would do in the current market conditions without risking capital. You can activate it by toggling the AI Assistant switch on the Trade page (top right panel).

The newest AI response appears at the top of the panel. While you remain at the top, incoming responses continue to appear normally. If you scroll down to inspect an earlier response, the panel keeps that response in place while newer responses accumulate above it; return to the top to resume following the newest activity.

Failed scheduled analyses appear in this same feed as warning or error cards. Failures before an LLM request is dispatched use the system label. If the LLM was dispatched and inference or result processing then failed, the card retains the exact model/provider label for that attempt. Error cards are not counted as successful prompts. Provider overload warnings show the reported failure; an HTTP status appears only when one is available. Scheduled provider retry messages show the current delay, which can increase after repeated overloads. If no delay is available, the message says that VTX will retry automatically.

When another configured API key is eligible after a provider failure, VTX tries it without an added delay. If the provider explicitly requests a wait, VTX honors that wait within the analysis timeout. Key retries do not add attempts or change your bot's recurring schedule.

AI Trader

The automated execution side of the system relies on the same logic but connects directly to your active Trading Profile. It is designed with robust safety measures to protect your capital and active sessions:

• Intelligent Pauses: In the event that an AI provider's network goes down (e.g., a "503 Service Unavailable" error) or you hit a temporary rate limit ("429"), the AI will automatically pause and display a clear warning banner. Crucially, the AI will not crash or halt indefinitely; it will intelligently retry running the analysis loop automatically instead. To start the AI Trader:

1. On the System page, connect Hyperliquid (your main wallet address and API wallet private key) and add a key for your AI model's provider. See the Quick start.
2. Check the profile's execution mode. New profiles start in Client Mode.
3. Configure your strategy settings (Model, Risk, Prompts) on the AI page.
4. Go to the Trade dashboard.
5. Click the Start button inside the AI Trader panel.

Server Execution Mode: The AI Trader securely executes your strategy on VTX servers. Once started, it continues analyzing and trading 24/7, even if you close your browser or desktop app, log out, or turn off your device, until you explicitly click Stop.

Client Execution Mode: The AI Trader runs inside your browser or desktop app. This local execution mode signs every exchange request on your device and sends user-specific Hyperliquid account, order, fee, and execution reads from your active app session instead of using VTX servers as a live exchange proxy. VTX Macro still keeps shared market data, bot status, billing, history, and app settings in sync. Client mode has no guaranteed uptime or background daemon, but it provides best-effort auto-resume after app restart if the bot was active before closing and the same profile/session context is restored. Since the local app session manages the bot, it uses a single-master model; if you open the profile on another device, you can instantly take control of the AI Trader from that new device.

Multiple profiles in one app session: Client Mode can keep separate profile runtimes alive in one browser window or desktop app. You can start a Client Mode bot for one profile, switch profiles from the top selector, and start another profile's Client Mode bot without stopping the first one. Each profile still has one owner at a time, so another window or device can take over that specific profile.

Headless Client Mode: Advanced users can also run Client Mode from the VTX CLI or MCP agent on their own machine. Those runtimes still follow the same profile ownership, lease, and safety rules as app-owned Client Mode. If you need to remove access from an old machine, revoke its CLI token or use the Security page session controls.

Mode transparency: Whether running on VTX servers or in your local Client app session, decision logging, history, and active performance display look and feel the same. Execution safety logic remains identical across platforms.

When staggered scheduling is enabled for a bot, periodic analyses keep a stable place within its configured interval in both Client and Server Mode. Bots using the same Main provider within your account are spread apart, with small timing adjustments to balance overall service load. Other users' bots do not join your provider group. The configured analysis interval stays the same. A slow cycle or a sleeping device can miss a scheduled time; the bot skips missed runs and waits for the next eligible time instead of starting several analyses together. Each analysis uses fresh context after that wait. Existing provider pauses still apply. Manual analysis, protection checks, and Main Agent instruction polling keep their existing timing.

The shared presentation also applies when Main or Review uses a connected external subscription agent. In Provider mode, VTX still owns the cycle and exact prompts. In Main Agent mode, the assigned agent chooses its cadence and which assignment-scoped data to request. Both submit the same structured decision; VTX owns current-state validation and the final result. The normal AI panel shows the accepted decision through the same compact presentation used by native models. Exact prompts and detailed invocation telemetry remain in VTX's canonical research records, not in a separate per-attempt panel. An external result is never shown as final merely because a host returned it; it must still belong to the current running bot and pass the same runtime and parser checks.

The AI Trader will now execute trades automatically based on your configuration. Monitor the Positions and Trade History tabs to see the AI in action; protective stop-loss and take-profit orders, when enabled, appear under Open Orders.

VTX trading support is limited to Hyperliquid Manual account mode only. Hyperliquid's own account-mode guidance recommends this setup for market makers, high-volume automated users, and builders, so VTX follows that automation-oriented guidance for bot safety and reconciliation. Unified Account mode, Portfolio Margin, and HIP-3 DEX Abstraction remain unsupported for automated trading and are rejected by app safety checks.

Risk, Size & Leverage

VTX Macro keeps your automated trading defaults consistent across the platform:

• Unit Size (USDC): The notional size of one trade unit for AI Trader orders. This is stored separately from your manual Trade page order size, so you can tune automation without affecting your one-off trades.
• Leverage / Max Leverage: Your selected leverage is shared between the AI and Trade pages so you don't end up running automation at one leverage while placing manual orders at another.
• Exposure and margin: Exchange leverage sets initial-margin requirements. Unit size and unit limits govern sizing; actual exposure/equity changes with prices and equity. In account context, maintenance utilization is the percentage of equity consumed by maintenance requirements, not the percentage remaining. Funding and maintenance risk are shown per DEX; wallet totals are reporting totals and cannot fund another DEX. Unavailable pool data is marked as unavailable rather than treated as zero.
• Unit limits: Global caps total absolute exposure across all markets. Max Units Per Exchange caps the combined units within each exchange: native Hyperliquid markets share one limit, and markets with the same prefix (such as xyz:) share another. Per Asset caps one market. All three limits apply together. Lowering Global also lowers Exchange and Per Asset if needed; lowering Exchange also lowers Per Asset. Raising a parent preserves smaller limits. New bots and Reset use 10 units per exchange; existing bots keep their previous Global allowance as their initial exchange limit. Lowering a limit does not automatically close positions, and reductions remain allowed.
• Platform Cap: Leverage is capped at 50x (or the asset's specific limit) to ensure safety. If any setting reports a higher value, VTX Macro will clamp it back to the allowed maximum. The default recommended leverage is 3x.

Note: AI settings may auto-save with a short debounce. Once saved, other pages refresh the updated preference automatically.

AI Controls and Status

In the right-hand panel, each profile's name is followed by its Assistant and Trader Start/Stop buttons, then Account Equity and Perps Overview. Symbols, timeframes, and progress remain below the balances:

• Assets: List of symbols being monitored (e.g., BTC, ETH). HIP-3 markets may appear with clean labels plus DEX pills in the UI while prompts, API calls, and debug traces preserve canonical symbols such as xyz:GOLD.
• Timeframes: Active intervals and candle lookback counts (e.g., 5m (25) = 25 candles of 5m data).

Units counter (shown as used/max below the timeframes):

• Used: Current number of "units" engaged in open positions.
• Max: Your configured Max Units (Global) limit.
• Updates: Refreshes instantly on every AI execution cycle.

When you are using All view, each profile gets its own AI control block. Start and Stop buttons affect only that profile, and the status color follows the profile's execution mode.

AI Models & Reliability

VTX Macro uses advanced chat and reasoning models from your selected provider to analyze the market. Sometimes, a specific model may be unavailable due to high demand (Rate Limits).

Model cascade If your preferred model encounters an eligible error (for example, a rate limit), VTX can try the next model in your profile’s saved AI-page Model cascade. Each model has its own timeout, including its key or host attempts. With only Model 1 configured, there is no model fallback.

• Indicator: Look for the Amber colored badge and 🔀 shuffle icon in the AI log.
• Hover Tooltip: Hover over the badge to see exactly which model was requested and which one was used.
• Configured Cascades: Main, Review, and Screener each use their own ordered model list, which can include different providers. Each row keeps its generation parameters when reordered; prompts remain shared within that list.
• Automatic: Once you save a list, eligible fallback attempts happen automatically. A later model is not guaranteed to succeed.

Local AI: Cloud models are tried only if you explicitly add them to this profile’s model list. Unknown request outcomes and partially streamed responses stop the chain.

Multi-Asset Selection

You can configure the AI to monitor and trade multiple assets simultaneously using the Asset Selector on the AI page.

• Click the assets input to open the selection menu.
• Select assets to monitor (up to 3).
• Use the sorting options (Volume, Price, Change) to find liquid markets.
• The AI will analyze ALL selected assets in every execution cycle.

Operating Schedule

You can restrict autonomous trading to specific hours or market sessions (e.g., NY/London overlap) using the Schedule settings on the AI page.

• Active Windows: Define specific day and time ranges. Outside these times, the AI status becomes Paused.
• Timezone: Align windows with your local time or major market centers.
• Presets: Quickly load standard sessions (e.g., "EU + US", "24/5 Weekdays") from the preset dropdown.
• Close on Stop (Trader Only): Optionally close the bot's open positions when a schedule window ends: the positions on the bot's Exchanges. A position on another venue of the same wallet stays open.
• Client and Server Mode: The schedule applies in both modes. Outside its windows the bot skips its analyses (no market reads or model calls for them, and no AI orders) and resumes at the next window; in Client Mode the device running the bot follows it. Copy Trading keeps mirroring outside the windows, and Trigger immediate analysis still runs one analysis.

Troubleshooting

If you are having issues starting the AI Assistant or AI Trader, please try disabling your VPN and/or ad blocker. These tools can sometimes interfere with the connection.

If you are using Local AI with Ollama, LM Studio, or llmster:

• Keep the profile in Client Mode.
• Prefer a loopback browser target on the same device:
  • LM Studio / llmster: http://127.0.0.1:1234/v1
  • Ollama: http://127.0.0.1:11434/v1
• If the local server is running on another LAN machine, use a local forwarder on the browser device and still keep VTX Macro pointed at loopback. See the Local AI loopback setup.

Optional: Windows Boot Auto-Launch for Client Mode

Client mode runs in your browser tab or desktop app. If you want best-effort recovery after Windows reboot/login, you can auto-launch Chrome with a pinned VTX Macro Trade URL or use the desktop app's startup options.

This setup is not needed if your profile is in Server Mode. Opening or closing the browser window does not affect the Server Mode bot, and only an explicit Start or Stop command can change its state.

Preconditions:

• You are logged into Windows for the scheduled task trigger.
• Your VTX Macro auth session is still valid in that browser profile.
• You already selected the target profile in VTX Macro.
• Browser startup policy allows auto-opening the requested URL.

Task Scheduler Setup (Windows):

1. Open Task Scheduler and choose Create Task.
2. In General:
   • Set a name such as VTX Macro Client Resume.
   • Choose Run only when user is logged on.
3. In Triggers:
   • Add trigger At log on for your user.
4. In Actions:
   • Program/script: C:\Program Files\Google\Chrome\Application\chrome.exe
   • Add arguments: --new-window https://vtxmacro.com/trade
5. Save the task and run it once manually to validate.

Client mode auto-resume and boot caveats:

• This is best-effort only: it does not create a background daemon or guaranteed uptime.
• Auto-resume only applies when runtime intent was active before close/restart.
• Auto-resume is skipped when execution mode is not client or the restored profile does not match the bot that was active before close.
• Ownership lease arbitration remains authoritative; another active owner window/device prevents duplicate local starts.
• Startup retries are bounded with cooldown to avoid infinite failure loops; if resume is still skipped, open Trade and manually start once after resolving config/auth issues.
• A missing profile wallet, or a private key Hyperliquid does not accept, stops automatic recovery until you fix it and start the bot again.
• If your organization hardens browser startup policies, review Chrome policy restrictions for command-line URL launches.

AI Configuration

The AI page is the brain of your VTX Macro system. This is where you define how the AI thinks, what it trades, and the strict risk limits it must follow.

Tip: You can save different setups as Snapshots (e.g., "Bull Market Aggressive", "Weekend Conservative") to switch strategies instantly.

Refreshing the page preserves your saved prompts. A selected snapshot supplies Reset values; it does not replace saved prompts on page load. Deliberate edits remain unsaved until you save them, and Discard restores saved settings.

The Reset button beside Settings Snapshots applies the selected snapshot or Default to the whole AI configuration. It is enabled when your settings differ from that target. Reset changes remain unsaved until you save them. Your own snapshots retain external model selections, reasoning effort, mode, and the ordered Host cascade; shared copies still require your own membership binding. Choosing a reset target preserves your unsaved edits and does not apply or save those settings. The selected target stays selected even when your current settings match another snapshot.

Snapshots can be created from unsaved edits, renamed, replaced, marked as a favorite, imported, and deleted. They are separate from the immutable rollback points Insights saves before fleet changes. A connected Insights agent can manage the same snapshots, read or reset the shared AI defaults while keeping settings you name (such as the model), and choose a Copy Trading source with the same profile identity checks as the app.

A snapshot saves the bot's Exchanges together with its trading symbols, so applying it brings both. Saved settings shown read-only (a snapshot, a decision's settings, a leaderboard bot) list their Exchanges too. A snapshot saved before the Exchanges setting existed uses the exchanges of its own trading symbols. Applying a snapshot follows the same rules as editing the settings yourself: an exchange the snapshot leaves cannot be removed while the wallet has an open position on it.

If asset leverage limits are unavailable, Trading Limits shows the affected symbols while retrying temporarily failed reads. After automatic retries finish, use Retry to refresh those limits.

Fresh-profile baseline

When a profile has no saved override for an AI setting, VTX initializes that setting from this app-wide baseline:

• Main Model uses gemma-4-31b-it. Review Model starts disabled with gemma-4-31b-it preselected.
• The initial market scope is HYPE across 1d, 30m, 4h. If 5-minute or 15-minute analysis is selected later, its default lookback is 25 or 100 completed candles, respectively.
• Each cycle runs every 60 seconds, uses 20 USDC units, and applies 3x leverage.
• The application-side Tradability filter starts on, with an Open minimum of 7 and an Increase minimum of 7.
• The Max Loss Count guardrail starts on for the short window at warning/critical 1/2, and off for the long window at 2/4.

Mechanical stop-loss protection starts off and take-profit protection starts off. Review starts off and the Screener starts off. The short-window Max Loss Count guardrail uses Hard enforcement. The AI schedule starts off. Timezone remains automatic by default, following your browser's local timezone. Use My Averages is disabled by default as a personal cost-display preference; it remains UI-only and is not a trading input. Saved profile settings and snapshots continue to override this baseline. Adding another profile can copy the selected profile's settings.

Older snapshots without recorded Tradability minimums show Unknown for those values. Their previews do not substitute today's profile defaults.

Read-only configuration previews on Leaderboard, Trade Analysis, and embedded snapshot cards use the same compact Performance labels: Max F/E, Max DD%, and Max Loss%. Main, Review, and Screener cascades show Model 1, Model 2, and subsequent entries as provider • model, without a separate Provider field. Expand a model entry to see its saved parameters and any included host cascade. Entries start collapsed, and your account remembers each Main, Review, and Screener model slot’s expansion choice across configuration previews. Details expand smoothly and the columns adapt to the actual section heights, respecting reduced-motion preferences. Missing historical parameter values show Default. Public previews show model controllers and host cascades as saved. Model, provider, reasoning, and externally managed parameter labels come from the saved Main, Review, or Screener controller; dormant native-provider fields do not replace an active connected-subscription controller. Public and cross-profile copies retain a portable external-model label but remove the source membership identity and require you to bind one of your own memberships before restore.

Recorded Last Execution Context panels appear automatically on AI and public Trade Analysis views. On public Trade Analysis, the panel is collapsed by default for signed-out visitors and remembers their choice in that browser. For a signed-in owner, the choice remains profile-specific. The panel animates when it opens or closes. Retained provider reasoning traces also appear automatically in History and Trade Analysis when the provider supplied one; there are no System-page visibility switches for either feature. Automated Codex models retain provider-emitted raw reasoning content for Main and Review calls made in Provider mode. VTX does not ask the model to write a separate analysis and does not substitute a summary when raw content is absent, so a call can still have no trace.

Follow-up chat on a retained Trade Analysis uses the exact accepted Main or Review invocation that produced the decision. If that invocation used an automated Codex subscription, the existing chat box sends the question through that historical controller and any compatible Codex-membership cascade; the original Trader or Assistant does not need to remain running. The Codex host must still be online and updated for subscription chat. Because this historical request is owned by the VTX API, it uses the normal Server Mode VTX call fee even when the original decision came from Client Mode. VTX saves the answer and its exact invocation together only after a complete accepted response. A failure, cancellation, disconnected browser, or unsupported agent-driven adapter leaves no partial turn and never substitutes a dormant native API-key model.

Main and Review responses can include extra commentary fields without invalidating an otherwise valid decision. VTX retains those additions for analysis but does not use them to place orders or replace the required decision, units, Tradability score, or reasoning. Missing or invalid required fields still fail validation in both Client and Server Mode. For your own bots, a connected Insights agent can read these retained additions and distinguishes unavailable history, responses without extra fields, and partially retained additions; calls that failed without a retained decision are not listed.

Changelog

The Changelog records profile setting updates as a compact timestamped list generated from the saved database event. Each entry shows the profile, source, setting, and readable before/after values. Snapshot changes show the snapshot name. Performance and Market Regime entries include each enabled switch, enforcement mode, evaluation or flip window, and warning/critical threshold, including Max Loss Count.

In account scope, profiles from one confirmed multi-profile action are combined only when their visible settings and before/after values are identical. Select N profiles changed to open the affected-profile overlay, where every handle links directly to that profile's individual Changelog. If profiles in the same action have different visible outcomes, those outcomes remain separate profile cards so the timeline shows each exact change directly. Profile scope continues to show individual profile events. Controller and Host cascade changes appear in the public Changelog like any other setting.

Prompt update rows are clickable. Open one to compare the complete saved prompt in a unified line-by-line view, where removed and added lines are marked separately. The Before and After tabs show either complete version by itself and provide copy buttons, while long unchanged sections can be expanded when needed. Profile Changelogs are public, so prompt text shown in a public Changelog can be viewed without signing in.

Settings updates approved through Codex, Claude Code, Cursor, GitHub Copilot, or another VTX Insights MCP client are written to this same Changelog with an Insights MCP source label. The MCP result links to the saved event instead of maintaining a separate change log.

VTX stores one canonical AI-page settings shape per profile. Older prompt aliases, nested symbol/timeframe fields, duplicate Performance mirrors, retired panel-wide Performance controls, and reasoning metadata that does not apply to the active control type are normalized at save or snapshot-restore time. Canonical values win when an older duplicate is also present, and unrelated profile settings are preserved. Runtime readers use only the canonical root symbol and timeframe fields; retired nested copies are no longer consulted.

Model & Intelligence

Choose the brain that powers your trader.

• Preferred Model: Select the specific chat or reasoning model used for trading decisions, such as a GPT, Claude, Gemini, Grok, Groq-hosted Llama/Qwen, or first-class BYOK provider model.
  • Models are dynamically synced from the app's current catalog of 1147 available AI models across 17 BYOK providers, including Alibaba Cloud Model Studio, Amazon Bedrock, Anthropic, BytePlus, Cerebras, DeepSeek, Fireworks AI, Google Gemini, Groq, Lightning AI, Mistral, Moonshot/Kimi, OpenAI, OpenRouter, Together AI, Venice AI, and xAI.
  • Native provider plans use these same model controls. Choose BytePlus Coding Plan or wallet-funded Pay as you go, Alibaba Coding/Token Plan, or Kimi Code in System settings, then select a model available to that plan. BytePlus subscription aliases and pay-as-you-go model IDs belong to separate catalogs. For subscription-first fallback, add a Coding Plan entry before a Pay as you go entry in System settings. VTX only attempts wallet billing when you explicitly add that entry, and the selected model ID must be supported on that route. These connections do not require an external inference host.
  • If your profile has Local AI configured, an additional Local AI group appears in the selector.
  • Each Model cascade row's full dropdown supports text search, available-key filtering, confirmed-free-model filtering, and multi-sort by model, provider, context window, token prices, and average observed cost. Model dropdowns animate when they open or close, and visible choices move smoothly when search, filters, or sort order changes. Local AI choices appear there when a Local AI server is configured for the active profile.
  • In Server Mode and browser Client Mode, if a BYOK provider has multiple saved keys, VTX tries Key 1, then Key 2, and continues in visible System-page order for key-specific or transient provider failures before using configured fallback models.
  • The Has key filter includes device-saved provider keys in Client Mode. Server Mode requires server-saved keys. Every cloud model call requires a key available for that provider on the active profile in the chosen mode. Missing keys fail closed, fallback providers require their own profile keys, and Google endpoint retries keep using the same profile key.
• Serverless vs. endpoint models: Some BYOK providers show both instantly callable serverless models and models that require you to create or start a provider-hosted endpoint first.
  • VTX Macro may show both kinds of models so you can use the full provider catalog.
  • Token prices are shown only when the provider publishes normal serverless or pay-as-you-go token pricing for that exact model.
  • Models that show $0.00 input and $0.00 output are treated as free in the model filters only when VTX Macro has confirmed both token prices are zero. Free models can be useful for testing or low-stakes analysis, but their quality, availability, rate limits, and latency may be less reliable than paid models.
  • BYOK users are responsible for reviewing each provider's current terms, free-tier limits, retention rules, and usage policies before relying on a free model for automated trading.
  • For Google models, Gemini API / Generative Language keys and Vertex AI Express keys can have different pricing, rate limits, and model availability for the same model. Treat the displayed catalog price as a guide and confirm the provider pricing page for the Google API surface your key is allowed to use.
  • Google Gemini API Gemma 4 models: Gemma 4 31B and Gemma 4 26B can be useful Google choices when your own Gemini API project shows them as available. VTX Macro routes Gemma 4 through the Gemini / Generative Language API because Vertex AI Express does not currently expose the Gemma 4 publisher-model endpoint for normal API-key calls.
    • A free Google AI Studio project currently shows about 1,500 requests per day for these Gemma 4 models. At the configured default loop interval of 60 seconds, one bot can use most of that daily request budget when each loop makes a single model call. Manual retries, extra testing, or a Review Model can push the project over the daily request limit.
    • In practice, default VTX Macro bot settings appear to run into Google AI Studio free-tier limits at around 5 active Gemma 4 bots total. For the best chance of stable operation, use one bot per Google AI Studio project and keep the total at 5 bots or fewer across the Google AI Studio account.
    • Among profiles whose Server Mode AI Trader is marked active, a profile counts toward the free-Google model limit only while its Main Model or Review Model is enabled. A Copy Trading-only profile with both models disabled does not use a model slot merely because an old Trader state is still marked active.
    • If you want the free-tier setup, do not add a credit card or enable billing on those Google AI Studio projects. Billing moves a project to a paid tier and changes the token/request limits; use a separate project for any paid Google API testing.
    • If multiple bots start hitting rate limits, stop all Gemma 4 bots for about 10 minutes, then restart no more than 5 bots total.
    • Google applies Gemini API rate limits per project, not per API key. Creating another key inside the same project does not multiply the daily request budget, and creating more projects, API keys, or Google accounts may not increase practical capacity. Google may associate related accounts or usage patterns when applying abuse and quota controls.
    • If you enable billing or your project is on a paid tier, the same Gemma 4 models may show different limits. Current AI Studio rate-limit pages have shown about 16K tokens per minute and 14.4K requests per day for Gemma 4 31B/26B. That is still usually one bot per project on default VTX settings, but only if the prompt stays below the token-per-minute limit. Larger prompts, more symbols/timeframes, longer lookbacks, shorter loop intervals, or a Review Model can hit the token limit before the daily request limit.
    • Review Model calls count separately from the primary trader call. If the reviewer uses the same Google project, it consumes the same request and token budgets as the main bot.
    • Always check Google AI Studio -> Rate Limit for the exact project and model before starting a long-running bot. Google can change limits, and your active account tier is the source of truth.
  • If the Models page shows - for a model's input or output price, VTX Macro does not have a safe per-token price for that model. For endpoint-required models, the provider may charge separately by hosted minute, hardware, replica, or reserved capacity instead of by tokens.
  • Provider failure messages show the result for each attempted model separately. For example, a main model returning HTTP 500 and a fallback returning HTTP 429 are different failures: 500 indicates a provider error, while 429 indicates a rate or quota limit. A failed main attempt followed by a successful fallback can still produce a usable decision. If no HTTP response was received, VTX does not invent a status code.
  • If a provider says a model is non-serverless or requires a dedicated endpoint, create or start that endpoint in the provider dashboard, then retry with the endpoint/model name the provider gives you.
• Model cascade: Main, Review, and Screener each have their own saved model list. Use + beside the heading, above the rows, to add Model 2, Model 3, and so on. Model 1 is primary. Every row uses the same full model selector. Use the arrows to change the order or × to remove a model. Each list supports up to 128 models including the primary. Models already selected in another row are excluded.
  • Each row has its own supported temperature, token limit, reasoning controls, provider-specific parameters, and timeout. Those settings stay with the model when you reorder it. New rows begin with the configured defaults for Main, Review, or Screener. Prompts remain shared within each model list.
  • VTX tries your saved models in order after eligible failures. Each model has its own request timeout, including attempts through its keys, connection routes, or hosts; moving to the next eligible model starts that model's timeout. Where alternate provider routing is enabled, a transport retry keeps the same model and counts against this timeout. Native model requests receive their timeout after context preparation. A failed native connection or model timeout can advance to the next saved model when no output was accepted; late responses from the abandoned request are discarded. Unknown external-agent outcomes, partially streamed responses, and stopping the runtime still stop the chain. An abandoned native request may still consume provider quota or incur provider charges. With only Model 1, there is no model fallback. A failure does not guarantee that a later model can be attempted or will succeed.
  • Connected external models support model fallback in Provider mode. Agent mode does not switch models automatically. Each external model has its own reasoning effort and Host cascade, which tries compatible hosts for that same model within that row's timeout.
  • Each fallback provider needs its own available profile key or connected host. Existing clearly matched fallback choices are carried into profiles when this feature is introduced; new profiles start without model fallbacks.
• Dynamic Reasoning Controls: Take control over how the AI "thinks" for compatible reasoning models.
  • Controls are provider-documented best effort and come from provider APIs or provider documentation. Some providers publish broad model-family controls, so a specific model may accept fewer choices than the AI page can show.
  • Advanced provider response details are handled automatically and kept out of normal AI Settings.
  • Leaving a reasoning control unselected means VTX Macro sends no value for that control, so the provider's own model default applies.
  • Explicit selections are sent to the provider as selected. If a provider rejects a combination, VTX Macro surfaces the provider error so you can clear the control so no value is selected/sent, or pick another supported setting and retry.
  • Some models are fixed reasoning or non-reasoning variants and intentionally expose no control unless the provider documents a configurable request parameter.
  • Effort Levels: Select documented provider effort values such as low, medium, high, or provider-specific values like max when the selected model supports them.
  • Thinking Budgets: Set strict token budget limits for models that support explicit thinking budgets to manage exactly how much computational effort the AI spends.
    • The -1 preset requests provider-managed adaptive budget behavior where supported.
    • Leaving all budget presets unselected sends no explicit budget override and uses provider default behavior.
  • Thinking Mode / Toggle Options: Some providers expose switches such as thinking enabled/disabled. These appear only when the provider documents them as user-configurable request parameters.
  • Configuration summaries show the resulting reasoning status: an unchecked Disable Thinking switch means reasoning is Enabled. A switch that controls whether reasoning output is included is labeled separately and does not establish whether the model is thinking.
  • Anthropic adaptive thinking and Groq reasoning-output controls appear when documented for the model family. Lightning AI and xAI show no thinking-effort control unless their provider documentation adds a user-configurable thinking setting.
• Cloud models are strictly filtered to a minimum system context window requirement of 16000 tokens.
  • Recommendation: Start with the configured default model and adjust based on your own latency, quality, and cost needs.
• Main Model Enabled: Turn this off when you want the profile to stop AI-originated autonomous entries without disabling Review Model settings, Screener, or Copy Trading. The Main Model settings collapse when disabled and expand again when enabled.
• Review Model Enabled: The Review Model starts disabled. Its settings collapse when disabled and expand when enabled. Main Model, Review Model, and Screener Model use the same smooth panel transition while keeping each enable switch visible. Review has separate Open, Increase, Reduce, Close, Flip, and Hold checkboxes. Their configured defaults are Open on, Increase on, Reduce on, Close on, Flip on, and Hold off.
• Cost Tracking: The panel shows raw model/source cost per run so you can budget before starting automation. It does not fold the flat trader-call fee into the displayed prompt/run cost.
  • Server Mode: Trader calls run on VTX Macro servers. This is the premium paid runtime. Qualifying calls are billed with the configured VTX Macro platform fee of $0.0025, but the displayed run cost stays raw.
  • Client Mode: VTX Macro is free forever and does not charge a platform fee. Your browser or desktop app owns the workflow and initiates model requests. BytePlus browser requests pass through VTX for browser compatibility. External provider costs come from the provider account or local runtime you choose, not from a VTX Macro client-mode fee.
• Use My Averages: Each of Main, Review, and Screener has an independent toggle to show costs from the viewed profile’s usage history or global platform averages. This account preference saves immediately and affects only the displayed estimates.

Connected inference agents

In Server Mode, changing AI settings while a connected provider is analyzing can supersede that analysis. VTX discards its result and shows an informational message that the next cycle will use the new settings. This does not require restarting the inference host.

Active, email-verified accounts can connect an agent inference host. Install or update it with npm install -g @vtxmacro/cli, then use the setup in Insights. Background services are available for OpenAI Codex, GitHub Copilot, DeepSeek Harness, Grok Build, Pi. These services keep running independently of the chat that performs setup, restart when the user signs in to the computer, and reconnect after sleep or a temporary network loss. There are two host paths. Both can serve Provider mode. Agent mode appears only for Main models whose host explicitly advertises Agent control:

• Grok Build: Connect Grok Build with its own OAuth sign-in on your computer, then select its advertised models through the existing Connected Providers controls. Its durable host supports Provider and Main Agent modes on native Windows or Linux. Provider mode receives VTX's complete prompt and context with no tools. Main Agent mode chooses its cadence, requests permitted VTX data, and submits the normal structured decision. Grok's built-in Web Search and X Search are disabled in both modes to keep requests within the selected VTX tool scope. Review and Screener remain Provider-only. Grok sign-in credentials stay in the private local state for that host instance. VTX validates the structured result and retains reported model and token usage; Grok does not provide the Codex subscription quota display. Interrupted work with an uncertain outcome stops safely and is not automatically repeated. Hosts with system-managed Grok or Claude settings are not supported by this adapter.

• Pi: Use the setup instructions in Insights to connect Pi with a separate OpenAI API key and API billing. Its supported models appear in the existing Provider / Agent controls. Provider mode uses VTX's prompt and context with no tools. Main Agent mode keeps a separate conversation and can request permitted VTX data and submit decisions. Available models depend on the supported provider protocol and exact model/effort capabilities. The integration does not import ordinary Pi conversations or subscription logins. Interrupted calls with uncertain outcomes stop safely rather than being repeated automatically.

• Durable providers: Codex keeps its existing pinned App Server, dedicated ChatGPT login, quota telemetry, and exact recovery path unchanged. GitHub Copilot uses the official pinned SDK and authenticated subscription model catalog. VTX resolves the package-owned pinned platform runtime explicitly and rejects an auto-only catalog because it cannot prove the effective model. Copilot output is validated by VTX against the immutable schema. It does not claim Codex recovery: after an uncertain process loss VTX records outcome_unknown, quarantines the attempt, and never blindly dispatches it again. DeepSeek Harness uses the exact-pinned official Harness package wave with the user's DeepSeek API key kept in VTX's local private credential store. Provider mode is tool-less. Main Agent mode keeps a durable Harness session and exposes only vtx_get_data, vtx_submit_decision, and vtx_decision_status; Review and Screener remain Provider-only. The host verifies the requested model and effort plus the provider-returned response ID and model before accepting a result. It does not silently retry an ambiguous interrupted call. The durable host writes an Agent failure fence that survives service restart; status --json and doctor --json expose it. Revoke and relink the exact instance only after reconciling an ambiguous fence. A DeepSeek authentication fence clears after a successful replacement key import, while quota and rate-limit failures honor the provider retry time or a bounded local cooldown. Each adapter uses a distinct instance and VTX grant, so Copilot cannot replace an installed Codex worker. The Codex package owns and verifies its supported binary, keeps the ChatGPT subscription login in a dedicated private home, and runs the encrypted job loop as a background service on native Windows x64 or native Linux x64. WSL supports the foreground diagnostic and agent-driven commands, but it does not install the durable service; use the native Windows CLI for Windows login startup. Before vtx inference-host codex-login, enable Device code authorization for Codex in ChatGPT Security settings. Never share a device code or enter one from a login you did not initiate. The automated host reads the authenticated Codex model picker and advertises every visible model with that model's exact display name, default effort, and supported reasoning efforts. The running host periodically checks for model changes, and AI Settings refreshes connected models while the page is visible and when you return to it. Refreshing availability preserves your selected model and unsaved settings. Settings saved through Insights also update the open AI page. Fields you have edited locally keep your unsaved values; untouched fields follow the saved update. A newly released model may require an updated VTX CLI; updating Codex in an editor or another app does not update VTX's bundled runtime. Hidden Codex entries are not exposed. Codex remains the connected execution provider; when an advertised model ID also exists in VTX's synced OpenAI catalog, the row identifies OpenAI as the model source and shows the same context and API-equivalent input/output prices as the native OpenAI row. Those prices are reference estimates, not an additional charge against the ChatGPT subscription. The scheduled OpenAI catalog and pricing sync handles new exact model IDs automatically; VTX does not maintain a separate Codex model metadata list. Codex-only or unpublished model metadata stays blank rather than being guessed. Claude Code uses the same exact-ID enrichment against the synced Anthropic catalog. DeepSeek Harness is a single-publisher adapter, distinct from the ordinary DeepSeek BYOK provider, and maps exact advertised model IDs to the synced DeepSeek catalog. Cursor and GitHub Copilot remain unenriched unless their runtime contract can authoritatively identify each model's publisher; VTX does not guess from a model name. Before starting a Trader, confirm that the selected model row shows the intended authenticated account when the adapter reports one. DeepSeek Harness reports its adapter, host, and model but does not claim a stable provider account identity or rate-limit window. Its API key and billing remain separate from the ordinary profile-level DeepSeek BYOK setting. The next line shows the host name, current status, and latest heartbeat in your configured timezone, so you can confirm which connected device will run the request. For Codex, VTX reads the account's live rate-limit window rather than guessing a fixed request count. A reached account limit pauses new Codex work until its reported reset. Exhausted included usage does not pause work when Codex reports available credits and no active workspace credit or spending-control block. Provider rejections and explicit retry delays still apply. The weekly percentage still measures included usage, not the credit balance. A transient provider throttle uses a short cooldown instead of repeatedly dispatching. Weekly capacity remaining does not rule out a shorter account limit. When a fresh account check confirms that all applicable limits have recovered, VTX makes that membership eligible again automatically. Explicit provider retry delays remain in effect until they expire. A durable host does not impose its own profile-count or prompt-concurrency limit by default. Agents can set an explicit positive integer with --max-concurrency when they want a local limit. Every active prompt still consumes capacity from its adapter-specific provider account or API key, so unlimited local admission does not promise provider capacity. Updating from an older bounded host removes its previous numeric limit; run service install --max-concurrency <positive-integer> only to add one back. When the adapter reports authenticated account and quota telemetry, the selected model row can show email and plan plus this profile's current membership burn rate as percentage points per hour, per day, and per seven days. These three values are the same observed rate expressed at different time scales, with one decimal of display precision. A final compact percentage on that account row shows the live weekly membership capacity remaining, so 90% means 90 percent remains. It appears only while the host has current provider quota evidence. VTX derives the rate from up to seven days of successive provider percentage snapshots and the exact membership that ran each prompt. If several VTX profiles overlap, reported token usage divides the change between them; external Codex activity during the same interval can make the estimate less precise. Collection is prospective, so a newly connected or newly upgraded membership needs two snapshots before percentages appear and its estimate stabilizes as evidence accumulates. Bot restarts, settings generations, model changes, and reasoning changes do not reset the estimate while the same membership remains bound. Provider quota resets and changed host/account identity discard the prior attributable window. Telemetry gaps are excluded from measured coverage but do not erase earlier evidence from the same provider window; stale telemetry stays hidden until fresh snapshots resume. Usage estimates update in the background when new evidence arrives, and an open AI page receives the updates automatically. Opening the page reads the prepared estimates. Rates may briefly be unavailable while their history is recovering; host status and current quota continue to update separately. DeepSeek Harness is API-billed and does not expose this subscription telemetry. Cascaded prompts appear on the membership that actually ran them, not necessarily the profile's preferred membership.

• Exo foreground bridge: Exo has an automatic VTX bridge for Provider and Main Agent modes on Linux or WSL. Provider mode receives the complete VTX prompt and context. Main Agent mode chooses its cadence and can request data for its assigned bot before submitting a decision. Review and Screener remain Provider-only. Setup uses a separate OpenAI or Venice API key. Each instance shows only the supported models for its provider. Venice currently offers Gemma 4 31B IT with reasoning effort None only; other Venice models and efforts are not supported. Other Exo providers and subscription logins are not supported by this integration. Keep the bridge open while the bot runs; it does not restart automatically. Uncertain interrupted work is not blindly repeated.

• Foreground agent-driven: Claude Code, OpenClaw, Hermes Agent, Google Antigravity, Gemini CLI, Kiro, Cursor, Amp, Auggie, Junie, Warp/Oz, Qwen Code, OpenCode, or another compatible harness can use its current first-party session. The agent connects its self-attested harness/model identity and advertises only the control modes it can serve. In Provider mode it waits for exact VTX jobs, reasons over the separately delivered system prompt, user prompt, context, and output schema, and submits the final result. Have the harness ready before it requests work: in Server Mode, each Provider job has a short window to begin inference while its account context is fresh. If that window expires, the harness must report that inference did not start and wait for fresh work. In Agent mode it waits for a Main Trader assignment, chooses its own cadence, requests any allowed VTX data it needs or none, and submits the normal structured decision. VTX never receives the harness's vendor login or subscription credential.

Decision history uses the Agent's review start time when the host reports it, matching Provider mode; older hosts show when VTX processed the decision. The duration beside it shows measured model latency when available; otherwise it shows measured review-to-submission time, including data reads and analysis. Submission retries do not extend this duration. Without either measurement it stays blank. Later decisions within the same durable Agent turn omit review duration unless they have an independent review boundary; an independently measured model latency can still be shown. Review duration is not model inference time and excludes waiting between reviews.

OpenCode, OpenClaw, and Hermes Agent can also connect directly to the ordinary VTX Insights MCP with OAuth and install the public VTX analysis skills. OpenCode uses its native remote MCP configuration and opencode mcp auth vtx-insights; the public Insights page provides the checked configuration and skill paths. This gives these apps the same Insights analysis and approved action capabilities as other listed agent apps; it does not make their trading-inference loop durable. Keep the VTX inference session in the foreground. If an interruption leaves the result uncertain, VTX does not blindly repeat the work.

When a host is online, its models appear first under Connected Providers in the normal Main, Review, and Screener model lists. Each lane shows one copy of each model from that profile's Host #1; compatible secondary hosts appear only under Host cascade, not as duplicate model rows. The model selector's membership usage rates show the selected profile's estimated consumption. Host cascade shows the combined estimated usage of all your profiles on each host, so its hourly, daily, and weekly rates stay the same whichever profile you open. The separate remaining percentage shows the account's remaining weekly quota in both places. Missing usage evidence is not shown as zero. For a lane without an external selection, VTX offers models from the first connected membership for each agent provider. External and native models use the same single-selection and sort behavior. The selected external row uses the same model, provider, context, pricing, observed average cost, and hourly, daily, and 30-day estimate pattern as native rows. Authenticated account email and plan appear beneath those usage estimates only when the adapter reports them; DeepSeek Harness does not claim either field. Model details, cost estimates, account details, and host details wrap onto additional lines on narrow screens instead of being cut off. A separate line beneath the account shows the connected host name, current status, and latest heartbeat. The same device details appear in the model list and every Host cascade row. Its advertised reasoning-effort controls appear in Model Parameters with the standard expand/fade animation, respecting your reduced-motion preference. Host details load before historical usage estimates. The model selector shows available details immediately and hides missing values without placeholders or reserved empty rows. Its height animates as details arrive or change, while long values wrap naturally on narrow screens. Existing details remain visible during background refreshes. An unavailable host is shown only when the catalog confirms that state. Main also shows Mode: Provider is always available, while Agent appears only when that exact model explicitly supports Agent control. Review and Screener are Provider-only and do not show an Agent choice. Use Host cascade below the selected model to add and order compatible computers for that profile and lane. Provider-mode calls can continue only through the exact hosts saved there. Agent mode keeps its durable thread and assignment on the exact selected Host #1; an Agent failure is fenced rather than automatically transferred to a different host. The first row is Host #1, and moving another row into that slot makes it the selected host without changing the model, reasoning effort, or control mode. Distinct host IDs remain separate even when they advertise the same authenticated subscription, so a desktop and laptop can provide machine-level fallback. The rows animate when you add, remove, or reorder them. Another profile can use a different order. It never changes to a saved native model, another provider, another model, or another effort. While multiple online hosts report the same account email, VTX withholds the profile and combined host usage estimates rather than double-attribute one provider quota window; this does not affect host routing.

Hyperliquid fresh-data budget exhaustion is reported separately from an AI provider rate limit. It does not mean the connected ChatGPT subscription is out of Codex capacity.

• Provider: VTX keeps its normal analysis cadence, builds the lane's prompt and context, and asks the connected model for a response. This is unchanged for Main and remains the only mode for Review and Screener.
• Agent: VTX assigns the running Trader to the connected Main agent. The agent decides when to run, requests any assignment-scoped VTX data it needs or none, and submits the same structured decision used by the normal Trader. VTX still validates current bot and trading state and retains lifecycle, risk, history, and execution authority.

Agent data tools expose every supported trading prompt variable from the same shared source, including future additions, even when your saved prompt omits it: candles, indicators, market statistics, account and position context, performance, behavior context, each news source, and calendar. News and calendar inputs still follow the profile's saved News and Calendar settings. These requests do not change settings, and unavailable values are never treated as zero.

An Agent's data request can take time while VTX retrieves current information. For Exo, a history request that returns too much data lets the agent choose a smaller time window. A failed connection or lost assignment stops the turn; missing data is not treated as a successful read.

For Codex, run vtx inference-host service install --adapter codex after both logins are healthy. Durable service installation uses the computer's device name by default; pass --display-name <name> when you want a different label. Services update automatically through a recovery launcher that retains the previous working release. A failed update rolls back without changing saved accounts or worker settings. An intentionally stopped service stays stopped. An operator-managed durable host can optionally use a direct inference route. This requires both VTX_INFERENCE_HOST_MCP_CONNECT_ADDRESS and VTX_INFERENCE_HOST_MCP_CA_FILE, followed by reinstalling the same service instance. Use the operator-provided address and CA file, keep VTX_API_URL unchanged, and keep TLS verification enabled. This affects inference traffic only; sign-in and provider connections keep their normal routes. Clear both variables and reinstall the service to return to the public route.

For Grok Build, use a separate instance: run vtx inference-host login --instance grok-1, then vtx inference-host grok-login --instance grok-1 and complete Grok's sign-in. Install its service with vtx inference-host service install --adapter grok-build --instance grok-1 on native Windows or Linux. Use the same instance for all three commands. For Pi, run vtx inference-host login --instance pi-1, import the OpenAI key through stdin with vtx inference-host pi-login --provider openai --instance pi-1, then run vtx inference-host doctor --adapter pi --instance pi-1 and vtx inference-host service install --adapter pi --instance pi-1. For Copilot, sign in with its official CLI and use --adapter copilot --instance copilot-1 with a distinct VTX grant. A Copilot account that exposes only auto is not advertised because VTX cannot prove its effective model. For DeepSeek Harness, first run vtx inference-host login --instance deepseek-1, then supply the API key only through stdin with vtx inference-host deepseek-login --instance deepseek-1. Run vtx inference-host doctor --adapter deepseek-harness --instance deepseek-1 and vtx inference-host service install --adapter deepseek-harness --instance deepseek-1. The key is never sent to VTX or written into the service manifest. DeepSeek API charges remain the user's responsibility and are separate from VTX fees. Antigravity remains foreground-only: live 1.1.13 acceptance advertised shell, file, browser, web, MCP, subagent, and messaging tools despite an isolated tools: [] agent, and its requested JSON Schema was not enforced. Gemini CLI's current individual OAuth flow rejects that client and directs users to Antigravity. Installation starts the service immediately and enables startup at user login. service status reports the installed/desired state and OS service-manager state, while vtx inference-host status --json reports local-only state. Confirm current remote host registration on the AI page, then select its advertised entry under Connected Providers in Main Model, Review Model, or Screener Model and choose the reasoning effort. For Main, choose Provider or an explicitly available Agent mode; Review and Screener stay Provider-only. Save, then start the profile's normal AI Trader. Both Main control modes work in Server Mode and Client Mode. Server Mode consumes the agent's submitted instruction directly. In Client Mode, the active browser or desktop owner claims it and performs the normal client decision, execution, and sync flow; without that live owner the instruction waits rather than bypassing the client lease.

For Exo, install the VTX CLI and the supported Exo version using the setup instructions linked from Insights. Windows users run the bridge in WSL. Sign in to VTX for a separate Exo instance, import its OpenAI or Venice key through the CLI's private key-import step, and run its connection check. Use one provider credential per instance; create separate instances to use both providers. Start the Exo bridge and leave it open: one process handles incoming Provider jobs and Main Agent assignments automatically, without copying prompts or results between terminals. Select its advertised model and reasoning effort through the same Connected Providers controls. The VTX authorization credential stays outside Exo; the provider key is used locally and is not sent to VTX. This trading connection does not make Exo a native VTX Insights MCP client.

The public Insights page includes the complete setup and run instructions. You can ask any compatible agentic harness to read https://vtxmacro.com/insights#subscription-inference and walk you through the chosen mode. The agent should ask before starting the normal VTX Trader. Stopping the Trader leaves a durable account-level service online and idle. A foreground host stays online only while its agent-run process and harness session remain open, or while its automatic Exo bridge is running. Use service stop, service start, and service logs for provider operations. Run service uninstall before logging out, revoking the VTX grant, or removing the package. The foreground run and agent-run commands remain available for diagnostics and harnesses without a supported headless adapter. Provider work uses agent-next, agent-complete, and agent-fail. Agent work uses agent-assignment-next, agent-assignment-heartbeat, agent-review-begin, agent-data-call, agent-decision-submit, agent-decision-status, and agent-assignment-release. The assignment response also shows the exact decision-submit input shape. The harness sends a candidate matching the displayed output schema and reports its stable run ID plus requested and actual model and reasoning effort as provenance.

A submitted decision is first accepted for processing. The harness should use the returned status command to confirm whether it completed or was rejected. If the result is uncertain, it must check that same submission before trying another; a temporary data failure is not permission to replay an old trade.

Recurring Agent checks: ask your harness to check markets at your chosen cadence using its own scheduling tools. There is no corresponding AI-page setting, and saved trading interval does not schedule Agent turns. Scheduling support, minimum intervals and operation after you close a session depend on the harness. VTX Agent compatibility alone does not promise a particular cadence, including one check per minute.

The harness should prefer its available scheduling tools, verify the task, interval and next wake, and complete an initial fresh data read. If scheduling tools are unavailable, it can wait between checks within the current session and must clearly report that this is session-bound operation.

Checks follow the requested clock rhythm rather than waiting a full interval after each analysis finishes. Only one analysis runs at a time; long turns skip missed checks instead of queuing overlapping work. Small timing delays are normal and should not shift the whole schedule.

The agent decides whether and when to submit trading JSON. A market check can finish without HOLD or a trade. The foreground keeper maintains the VTX host's heartbeat; it does not schedule checks, fetch market data, or reopen a closed harness. Long model turns, sleep and outages can leave gaps. A heartbeat or a recently returned result alone does not prove fresh market data; the agent should check the returned source timestamps and unavailable values.

Live prices and candle data carry separate timestamps. A current quote does not make an older candle's open, high, low, close or volume current. Market snapshots say whether a price is a live quote or a candle-close fallback, with its source and timestamp basis; a candle's timestamp is its opening time, and candle age is reported separately. Request market history when current candles are needed, and check freshness before relying on a fallback price.

After reconnecting, the harness must confirm its current assignment and obtain fresh data before continuing. Stopping the bot ends its assignment. Cancelling a harness's recurring task alone does not stop the bot or close positions. Your session can use its authorized Insights and external tools; VTX does not install those connections or grant access to them for you.

The service log records safe request timing, concurrency, token totals, failure codes, and provider cooldown events without recording prompts, responses, or credentials. Use service logs --instance <name> when you need to isolate one worker. The service log has a size limit. When it reaches the limit, its newest entries move to one .1 file beside it, replacing the previous one, and the log starts again, so it cannot fill the disk. service logs reads across both files. Background heartbeat requests have a short deadline so a slow request cannot hold up subsequent heartbeats for the full general request timeout. Failed heartbeats record limited timing details for support; server retry instructions still apply.

If Grok reports that VTX rejected its tool list locally, the rejected request did not reach xAI. This message identifies a VTX host validation failure, not an xAI outage. The error distinguishes an invalid tool list, an unsupported tool type, a missing tool name, or an unexpected set of tools. Updated hosts automatically send a limited diagnostic to VTX so support can inspect the failure without asking you to collect logs. Prompts, tool arguments, responses, and credentials are excluded. If support needs the local entry, run vtx inference-host service logs --instance grok-1 on the computer running the host (use your instance name) and locate grok_tool_validation_failed. Across providers, VTX sends your selected model and records the model name reported by the provider. A returned name may differ from your selection or be absent from the model catalog; this does not invalidate a successful response. This applies to Server and Client modes, including connected hosts in both Provider and Agent modes. Grok's available selections and routing names come from your connected account's model catalog.

A response-identity failure means Grok returned a missing or malformed response ID or model name, or inconsistent identity within a response. Updated hosts report a limited diagnostic automatically without collecting your prompts or responses. Tool restrictions and structured-output checks remain enforced. Installed services receive routine updates automatically.

Installed services check for verified CLI updates at startup and periodically while running. They download the new release in the background, stop taking new work, and let active Provider calls and Agent turns finish before switching. Heartbeats continue during that wait. The new release becomes active only after all configured workers report ready; a failed candidate returns to the previous release. Routine updates do not require an npm command or a manual restart. An intentionally stopped service stays stopped and does not check for updates. Foreground hosts still use the version that was started.

Older startup-only services adopt background updating after their next normal service start activates a release that includes it. Publishing a new release cannot replace an older process that is already running. Check service health with vtx inference-host service status --json and the running version in host diagnostics.

Moving an existing fleet to another computer

Before changing an existing fleet, write down the exact profiles and each lane's model, reasoning effort, control mode, execution mode, primary host, and ordered fallback hosts. Give every worker a stable --instance name. On the new computer, install from native Windows or native Linux and run login, the adapter-specific vendor step (codex-login, official Copilot CLI login, grok-login, or deepseek-login / pi-login --provider openai through stdin), doctor, and service install separately for each named instance. Use the same --instance throughout and the matching --adapter for doctor and installation; the Insights harness guide lists each setup. One per-user OS supervisor manages the isolated workers; each still has its own VTX grant, credential boundary, and runtime state. DeepSeek Harness currently permits only one worker for that adapter per computer because it does not advertise a stable provider account identity.

A new installation creates a new host identity even when it uses the same vendor credential. Matching email, API key, adapter, or device name is therefore not proof that an existing AI setting points to the new computer. Check every target lane, explicitly preview and approve any primary or Host cascade rebind, and preserve the existing model, reasoning, control mode, execution mode, symbols, prompts, and unrelated settings. Read the effective settings back after saving. Keep the previous computer's grants available until the new bindings and workers have been verified, then disconnect only the obsolete hosts.

Verification requires more than a routed request or a running Trader. Confirm that every named worker reports the intended adapter, model, and host ID plus the authenticated account when one is available; every new host must have a fresh remote heartbeat, and each primary host must produce a fresh completed inference that VTX accepts. For full fleet verification, observe one such completion from every target profile. A claim, start acknowledgement, start receipt, or brief Live state is not completion evidence.

The durable service starts immediately when installed and registers startup for that user at sign-in; it is not a pre-login Windows service. While the computer is off, asleep, signed out, or offline, it cannot provide inference. After the user signs in, workers whose desired state is running reconnect automatically. Active hosts renew their VTX authorization automatically as they reconnect and refresh access. Routine token renewal does not require another login. A disconnected authorization, or one that has expired after inactivity, requires login again. Run vtx inference-host login --instance <name> using the same instance to reconnect its saved host. This keeps the bot's existing host selection; do not revoke or log out just to sign in again. An installed service keeps running during approval, then briefly pauses its workers to replace the credentials and restores its previous running state automatically. An intentionally stopped service stays stopped. If the handover is interrupted, rerun the same login command to finish recovery.

If an analysis is cancelled or times out while its host is finishing, VTX retains the host's final report so the old analysis does not trap it in a restart loop. When the trader is still set to run, the host can accept the next analysis without another login or manual restart. While the host is finishing or recovering work, VTX reports that state and retries while your trader is running. An explicit Stop stays respected. Agent mode also saves each completed turn with its next scheduled wake, so a restart can resume that schedule without repeating the turn.

An explicitly revoked host cannot reconnect this way. Revoking or removing its local state disconnects that identity; a newly registered host must be selected in the bot settings, even if its name is unchanged. service stop disables automatic recovery and login startup until service start re-enables them. Fallback workers on the same computer protect against an individual provider credential or quota failure, not against that computer being unavailable. Reboot or sign out only when you intend to test startup; after signing back in, recheck every worker, remote heartbeat, and a fresh completed inference.

On native Windows, if service status or logs show that guarded recovery is blocking one installed subscription, run vtx inference-host service recover --instance <name> --force-recovery --json for that exact instance. Recovery is noninteractive and requires both --instance and --force-recovery; --json changes only the output format. The shared supervisor briefly pauses so every installed worker can stop cooperatively, then VTX restores its previous desired state and the same peer subscriptions. Recovery does not kill an arbitrary process, reboot the computer, log either account out, change profile settings, or control a Trader. If any package-owned VTX automation is still live, the command fails closed and preserves its recovery evidence.

To use the same Codex subscription as a machine-level fallback, complete login, codex-login, doctor, and durable service installation separately on each computer. Each computer receives its own VTX grant and host ID, keeps its own private Codex credentials, and defaults its displayed host name to the operating system device name. Do not copy the inference-host state directory or credential files between machines. Add the desktop and laptop to the lane's Host cascade and put the preferred computer in Host #1. If that computer is offline, stale, or fails locally, VTX advances only through that saved host order.

Multiple installed workers on one computer still require distinct authenticated ChatGPT subscriptions. For that setup, repeat the commands with a local instance name such as codex-2; one OS supervisor manages the isolated workers, and service status --json lists them. service uninstall --instance <name> removes one worker while preserving the others; unqualified service uninstall removes the whole supervisor. Provider quota remains account-level: another computer using the same subscription does not create extra capacity, so quota-classified failures skip peer hosts with that same reported identity and may continue to a later distinct subscription. Codex results keep their frozen host position in product badges: Host #1 has no suffix, Host #2 uses #2, and Host #3 uses #3, including when a request starts directly on an available later host because Host #1 is already offline. VTX does not retry another host for a bad request, context limit, invalid response, cancellation, policy rejection, or an uncertain dispatch outcome.

Use vtx inference-host --help for command discovery. Login now verifies that the OS credential store can read back the exact VTX grant; if Windows Credential Manager or another OS store cannot retain it, VTX revokes the new grant and reports the supported private-file fallback instead of reporting success. Set VTX_INFERENCE_HOST_CREDENTIAL_STORE=file before retrying login. On PowerShell, use $env:VTX_INFERENCE_HOST_CREDENTIAL_STORE="file"; on bash, use export VTX_INFERENCE_HOST_CREDENTIAL_STORE=file.

The local callback normally displays VTX authorization complete. If a browser extension shows ERR_BLOCKED_BY_CLIENT but the CLI reports logged_in and doctor reports credential-present, only the confirmation page was blocked and the authorization succeeded. If an older failed login has no local credential to revoke, disconnect its inactive grant from Connected Agent Apps on Insights before logging in again.

Connected Agent Apps shows live logical apps rather than every OAuth credential ever issued. Repeated dynamic-registration sessions with the same immutable app contract appear as one card with an active-credential count; Disconnect or Relink revokes the exact owner-scoped credentials represented by that card. Revoked and expired rows remain in audit history but are not presented as connected apps.

After an approved Trader start, verify current status until the Trader remains running. If it returns to Stopped, inspect the latest runtime error or event, report the cause, correct it, and only then make one controlled retry. A start receipt or a brief Live label is not proof that the bot is running.

In Provider mode, a connected agent is a model source rather than a separate bot. In Main Agent mode, it controls the cadence of the normal running Trader through a fenced assignment; it is still not a second bot. The profile's normal AI Assistant or AI Trader must be running. In Client Mode, the active browser or desktop app must also remain the fresh owner of that profile's runtime and claims Agent instructions before normal client execution. In Server Mode, the server runtime consumes Agent instructions directly. Screener stays Provider-only, runs only with AI Trader, and never places an order by itself.

For Provider work, VTX builds and retains the same exact model-facing prompts and context it would use for a native model. Agent work instead retains the assignment-scoped data calls and submitted structured decision available from that run. Accepted external Main and Review decisions appear in the normal Trade AI panel and history; Screener output appears in normal Screener evaluations. VTX retains the requested and actual model, reasoning effort, control or response mode as applicable, latency, time to first token, token usage, parsing status, and cost in canonical invocation records. The normal result cards keep their existing compact presentation and do not add a per-attempt details accordion. This keeps external and native decisions comparable and preserves the inputs and outputs needed for future research.

For direct provider calls, VTX records the requested reasoning setting and what was sent for each attempt, including retries and fallback models. Budgets and reasoning switches are retained where a model uses those instead of an effort level. A provider-confirmed setting is recorded only when the provider returns it; otherwise it remains unknown. External-host reports remain distinguishable from provider confirmation. These records do not change your model settings.

• Server Mode: Every completed external-agent response uses the normal VTX call fee of $0.0025, including separate Main, Review, or Screener calls when enabled. Any vendor subscription or API usage is separate.
• Client Mode: VTX charges no platform fee and records zero VTX model cost; the call still uses the connected vendor subscription or API key and is subject to that provider's limits and billing.
• Quota and availability: When an adapter reports an authenticated account identity and reset window, a quota failure stops dispatching to that membership until reset or a fresh account check confirms recovery. A later compatible host is suppressed only when it positively reports the same account identity. DeepSeek Harness is API-billed and reports neither a stable account identity nor a membership quota window, so its ordered compatible hosts remain eligible without identity-based suppression. Server Mode also advances a call that is still queued and has never been claimed if its selected host becomes unavailable. A safe, completed failure can advance to the next model explicitly saved in the profile's Model cascade. Uncertain dispatch outcomes and partial responses stop the chain.

Screener Model

The Screener Model panel controls the profile's symbol-discovery runtime. Use it when you want VTX Macro to rank possible symbols before you decide what to inspect or trade.

• Enable Screener: Arms the profile-scoped Screener schedule. Screener runs only while AI Trader is running for that profile. Stopping AI Trader also stops active Screener work, while leaving this saved setting enabled for the next AI Trader start. Completed Screener runs can automatically switch that profile's AI trading symbols when a candidate passes the Symbol Assignment rules. The Screener page is monitoring-only; it does not expose separate Start/Stop controls.
• Model cascade: Chooses the ordered models used to score candidate symbols. Every row uses the same full selector and has its own supported parameters, timeout, and external Host cascade. Screener prompts are shared across its model list. Local AI choices follow the same Client Mode requirements as the main model.
• Exchange / Universe: Chooses the single universe scanned by each run. It must be one of the bot's Exchanges: add an exchange there before pointing the Screener at it.
• Symbol Leverage and Minimum Volume: Narrow the scanned symbols to the selected exchange maximum-leverage classes and to a minimum 24h volume. Current AI trading symbols are still evaluated.
• Schedule Type: Adaptive makes candidates wait while AI Trader is using the same Screener model and provider; cleared, candidates run back-to-back. See Screener for details.
• Run Schedule and Limits: Controls how often runs start, how many full volume-ranked passes are made, and how many candidates are evaluated per run.
• Candidates Per Run: Sets the discovery slice. The run can expand beyond this value when current AI trading symbols need to be included for comparison.
• Symbol Assignment: Guarded automation that controls when active Screener runs may update the profile's AI trading symbols. Its controls set the minimum candidate score, required edge over a replaced symbol, duplicate-symbol allowance across your active profiles, and number of trading-symbol slots Screener may manage.
• Prompts and Variables: Lets you edit Screener-specific prompts and select which Main model variables are included. Screener also adds its own candidate volume/rank context.

The Screener does not place trades, change leverage, or send BUY/SELL/HOLD instructions. Symbol assignment uses only completed Screener scores from the same run; it does not use Trade-page tradability or Main/Review model trading output. Use the Screener page to review ranked results and recent assignment history.

Exchanges

The Exchanges panel, just above Copy Trading, chooses the Hyperliquid perp DEXes this bot uses: Hyperliquid (default Perps) and the HIP-3 DEXes such as xyz. It is the one list for everything the bot does on your wallet.

• Choose at least one and up to 2 exchanges.
• Trading Symbols can only be on selected exchanges. To trade a symbol on another exchange, add the exchange first.
• An exchange cannot be removed while a trading symbol is still selected on it, or while the wallet has an open position on it, whatever its symbol. Remove those symbols and close the position first. Removing the last symbol on an exchange does not remove the exchange; it stays selected until you remove it here.
• Copy Trading can copy only on these exchanges: its DEXes row lists them and you choose which ones are copied. Removing an exchange here also removes it from that row; adding one does not start copying on it until you select it there.
• The Screener can only scan one of these exchanges, and it only assigns symbols on them.
• The Trade page, Close All, the kill switch, and a scheduled stop cover exactly these exchanges; the Trade page also shows the DEX of the market on the chart. Positions and orders on other DEXes of the same wallet are neither shown nor closed.
• The bot's equity, ROI, and drawdown are still measured only on the exchanges its trading symbols are on (see Bot equity and performance in Trading), so selecting an extra exchange for Copy Trading does not change them.
• A bot that never saved this setting uses the exchanges of its trading symbols.
• Reset restores this list from the selected snapshot, or the default list when none is selected. It changes only this panel: Trading Symbols keep their own Reset in Market Context, and saving is refused while a selected symbol is on an exchange the list no longer has.

Copy Trading

The Copy Trading panel lets a profile mirror exchange-visible Hyperliquid perpetual orders and fills from a VTX bot or any Hyperliquid wallet address.

• Copy Trading is disabled by default and does not start live copying just because you select a source from Leaderboard or Analytics.
• Source selection is profile-scoped. Leaderboard and Analytics Copy Trades actions update the active profile's Copy Trading source and recent-source list without changing the current page.
• DEXes chooses which of the bot's Exchanges are copied. It lists only the bot's exchanges, so to copy on another DEX, add it in the Exchanges panel first and then select it here; at least one is always selected. Each copied order is sized by that DEX's balance on both wallets. VTX reads account state only for the selected DEXes plus the default Hyperliquid DEX, so each extra DEX adds exchange reads for every copied fill. Source orders and fills on any other DEX are not copied and do not appear in the AI panel. Clearing a DEX here, or removing its exchange from the bot, cancels copied orders still resting there; positions you already hold on that DEX stay open.
• Account-size scaling is the default, and it is measured per DEX because orders are placed per DEX: a copied order on a DEX is sized by that DEX's own Perps balance on the source wallet and on your wallet, such as Perps (xyz) for xyz markets. A source wallet in a Hyperliquid mode that pools collateral across DEXes (Unified Account, Portfolio Margin, or HIP-3 DEX Abstraction) is measured by its whole account value, because that pool backs its orders on every DEX. VTX uses both values only when they are fresh and valid; if either is missing, stale, zero, or invalid, the copy intent is skipped instead of silently resizing. In Client Mode, VTX's servers never read your wallet: your device reads your balance each time your bot checks in, and your copies are sized from the balance of the latest check-in for up to 15 minutes, or 3 of your bot's loop intervals when that is longer. Without a check-in in that time, a copy waits for your bot's next check-in.
• Fixed multiplier scaling can scale below or above 1.0 within configured bounds.
• Copy Trading follows the profile's existing Server Mode or Client Mode setting. There is no separate Copy Trading runtime-mode toggle.
• Copy Trading can run with Main Model and Review Model both disabled. In that copy-only setup, an old active Server Mode Trader state does not consume a free-Google model slot.
• Copy Trading mirrors supported open limit and trigger orders, including exchange-visible Take Profit and Stop Loss orders. Attached entry and TP/SL children are submitted together with the exchange's atomic grouping, and VTX keeps separate ownership of every copied member for later updates or cancellation. There is no separate TP/SL copying switch.
• Copy Trading copies each source trade's change, not the source's whole position, and keeps track of the part of your position it opened (the copied part). When the source opens or adds, the change is copied at your scale. When the source reduces, your copied part shrinks by the same fraction; when the source closes, your copied part closes. Copy Trading moves your position only by the copied change, so your own trades on the same market and positions the Main Model opened are not treated as the copy's. If you close a copied position yourself, Copy Trading does not reopen it; later source trades copy only their own change.
• Hyperliquid holds one net position per market. Copy Trading does not trade against your own position: if your own position on a market is on the opposite side of a source trade, the part of that trade that would offset your position is not copied, and a copy only ever closes what it copied. A copied resting order that is already on the book can still fill against a position you open afterwards. A new copied resting order that would open or add against your own opposite position is not placed while that position is open. In Client Mode this is checked against the position your device reads each time your bot checks in. Copied reduce-only and Take Profit / Stop Loss orders are sized to the copied part, so they never close your own position: a source Take Profit / Stop Loss on its whole position protects your whole copied part (up to your maximum order size, if you set one), and a source reduce-only order closes the same share of your copied part. When the copied part changes, the resting order is resized, and it is canceled once nothing is copied or what it would close falls below the minimum order size.
• A source position that already existed when copying started is not bought when the source next trades it: only the change from that trade is copied. A source order that closes such a position is not copied, because you hold no copy of it.
• A source trade that is not copied (too old, or declined by the Review Model) is not copied later with the next trade either. A source reduction or close that arrives too late still reduces or closes your copied part.
• Copy Trading copies only fresh source activity. If VTX loses its connection to the source wallet, for example during a restart, source trades it missed are not copied late. When it reconnects, your copied part only follows the source's reductions and closes, never its opens or adds, and copying continues with the source's next trade. This also applies after a disconnection too long for VTX to read back, so copying never stays paused because of one.
• If a linked destination order remains open when its source fill arrives, VTX cancels that linked order before copying the rest of the change.
• If a copied order was definitively rejected or never sent, recovery checks the current position and source before a permitted retry. Rejected orders are not counted as fills. An uncertain result keeps copying paused for reconciliation so the same order is not sent twice.
• Only orders created by Copy Trading are updated or canceled. Your unrelated destination-wallet orders are left alone.
• VTX copies supported perpetual-market orders that Hyperliquid exposes for the selected wallet. It cannot copy private intent that has not been submitted to the exchange, and Copy Trading does not add spot-market support.
• Copied quantities are rounded to the destination market's Hyperliquid lot size and checked against the destination's current mark price when available. A source order whose copy would be below Hyperliquid's $10 minimum is never enlarged to reach it. If it opens or adds to a position it is not copied, and it is not bought later; a larger copy size avoids this when the source trades in small orders. If it reduces a position, the reduction is applied with the next copied trade on that market, so your copy never holds more than its share. An order that fills in several pieces is judged as one order. The same applies to a copy that turns out too small only when it is sent, because part of it was already delivered or the price moved. An exact full close rounds up to one reduce-only lot and remains eligible below the minimum so VTX does not submit or acknowledge a zero-size close.
• Copy Trading follows the same fee as every Server Mode trade: $0.25 per successful Server Mode trade, charged once per distinct filled order. Opening, adding, reducing, closing, and protective orders count; each filled child of a flip or batch counts separately. Client Mode execution is free. See Billing & Payments for credit reservations and settlement. Trade fees remain separate from AI prompt/model cost estimates.
• If the Review Model is enabled, a copied BUY or SELL action is reviewed when its destination-position intent has its checkbox enabled: Open, Increase, Reduce, Close, or Flip. Safety cancels do not wait for model approval, and Copy Trading has no Hold proposal to review. A triggered review receives the same context as normal Trader review, with the proposed copy action replacing the main model's decision, so CR rows include tradability and full reasoning.
• AI snapshots do not import or enable live Copy Trading source settings or the DEXes selection. They do carry the bot's Exchanges.

Local AI model selection

• Local AI is the recommended approach for high-performance offline inference. If you want larger context windows, higher speeds, and stability for local models, run them via a Local AI server (e.g., LM Studio, Ollama).
• Local AI models are available only when the profile is configured for Client Mode.
• On the System page, Quick setup fills editable connection defaults for LM Studio / llmster, Ollama, llama.cpp, vLLM, and SGLang. All use the OpenAI-compatible API; use Custom for another compatible server.
• Test & Refresh reads /models at the configured API base. Use the AI page model selectors to choose Local AI models for main and review roles after the endpoint's models have loaded.
• Click Apply on System to save endpoint access only: base URL, API key storage, and sync setting. Selecting a preset does not save settings or choose a model.
• For Ollama, keep the full returned model tag, such as :latest, if it appears in the model list.
• Native Ollama connections are no longer supported. Reconfigure any older native connection with the Ollama preset, then Apply and Test & Refresh.
• When a Local AI model is selected, VTX tries a cloud model only if you explicitly add it to the profile’s model list and the failure is eligible. Unknown request outcomes and partially streamed responses stop the chain.

Market Analysis Scope

Define the data the AI "sees" when making a decision.

• Trading Symbols: The assets the AI is allowed to monitor and trade (e.g., BTC, ETH, SOL). VTX verifies each selection against current Hyperliquid market metadata before saving or starting a Trader. An unavailable symbol is rejected; if market metadata cannot be verified temporarily, retry after the connection recovers. A symbol with an open position cannot be removed; close the position first. Every symbol must be on one of the bot's Exchanges: add the exchange before selecting a symbol on it.
• Account reconciliation: After an account change, Server Mode waits for fresh exchange confirmation before using the account in another analysis. A reconciliation-pending warning means an earlier change still needs confirmation; a state-changed-during-prefetch warning means the account changed while data was being prepared. Running Traders retry automatically. Fresh-data or read-budget failures keep the account protected until confirmation succeeds.
• Hyperliquid availability: When a Server Mode Trader or Assistant cannot obtain fresh account data, an open signed-in browser or desktop app can assist analysis using its public connection. Account data that becomes too old while other reads finish is refreshed within the original request deadline; old data is never relabeled as fresh. VTX does not refuse public requests solely because an estimated request allowance is full. If Hyperliquid returns a rate limit, requests sharing that connection coordinator pause according to the provider's retry instructions, then resume gradually. Failure messages distinguish the server or app route, an actual Hyperliquid rate limit, waiting for recovery, an unanswered request, a deadline, or rejected data. Multiple devices and other apps on the same network still share Hyperliquid's IP limit. App presence and fallback responsiveness are tracked separately; missing or stale presence does not prove that the app was closed. Execution keeps its own fresh server checks; client assistance does not guarantee an order can proceed during an exchange-node outage.
• Hyperliquid request priority: When public requests must queue, trading comes first, with closing or reducing exposure and protective actions ahead of other trading work. UI reads follow trading, and background refreshes follow UI reads. Required account, price, and metadata reads inherit the operation's priority in Server Mode, Client Mode, and app-assisted fallback. Closing a position from the Trade page counts as trading, not a UI refresh. Lower-priority work can use available capacity whenever higher-priority work is not waiting. Priority does not bypass an exchange cooldown or the fresh-data checks required before an order.
• Timeframes: The chart intervals analyzed (e.g., 5m, 1h, 4h).
• Lookback: How many past candles are sent to the model for each timeframe. For example, the default 30m lookback is 48 candles.
• Technical Indicators: Enabling these pre-calculates values like RSI, MACD, or Bollinger Bands and feeds them to the AI numerically.
• Open-position profit and loss history: Position context shows the largest observed campaign profit (MFE), largest observed loss (MAE), profit given back from a positive peak, and approximate minutes since that peak. USD values include realized and unrealized PnL minus paid trading fees, including additions and partial reductions; funding and estimated future fees are excluded. An order filled in several pieces at the same instant remains eligible when the exchange's starting-position records establish their sequence. MFE and MAE percentages use the position's current DEX equity. Giveback percentage uses positive peak profit and can exceed 100% if a profitable campaign turns negative. These are observed candle and current-mark bounds, which can understate intrabar excursions; they are not exact tick-by-tick highs and lows. Unverified history appears as -; giveback and peak age are unavailable when no positive peak is known. Saved custom prompt text is preserved.
• Behavior State: Every Trader prompt includes a runtime-assembled {behavior_state}, including custom saved prompts that omit or escape the variable; the saved prompt itself is not changed. Its compact per-symbol fill, position, last-trade, and Decision Memory (pd, pc, and et) context is mandatory for trading. Nested status values use s="a" when qualifying evidence exists and s="n" when no qualifying value applies. Fields whose schema permits bounded unavailability can use s="u"; specifically, pc and et permit it while pd does not. Those explicit states remain valid context. If VTX cannot construct or validate the behavior state, it skips only that cycle before model inference, keeps the Trader running, and retries at the next scheduled cycle. Construction uses current request data and time-bounded local database reads; it does not wait for the asynchronous Trade History projection, which may appear later during temporary Hyperliquid data delays. Review receives the exact Main Model prompt it evaluates.
• Tradability Score: Each Trader decision includes a model-authored integer score from 1 (lowest) to 10 (highest). If your Main System Prompt defines Tradability or explicitly makes it a decision constraint, the model should follow that instruction; otherwise the score is based on model judgment and remains advisory. When review is enabled, the Review Model receives those Strategy Agent rules and should preserve their explicit Tradability constraints in its final decision. Tradability never replaces the required decision, units, or reasoning, and hard account, risk, capacity, and execution constraints always take precedence. A high score with HOLD, such as HOLD - 8, can still be correct because a high score permits but does not force a trade.

News Panels

Each news source has its own prompt variable and its own panel, so a prompt includes a source only when it uses that source's variable, with that panel's limits:

• Telegram News controls {news_telegram}: every post from the Telegram news channels the bot reads, newest first, up to Max Headlines within the Timespan. Channels picks which of VTX's channels a bot reads; with none picked it reads all of them, including channels VTX adds later. If VTX stops listening to a channel you picked, the bot simply stops getting its posts; a bot whose picked channels are all gone reads every channel again. Each channel shows how many posts it made in the last 24 hours, so you can see what a channel costs in prompt space before picking it. Headlines are not filtered by what the bot trades, so a sharp move in Bitcoin or a macro shock is context for any market. Nothing is filtered out or reworded: VTX does not judge which posts are news, so a channel's promo or a headline two channels both post appears as it was posted. Only web links (https://…) and invisible characters are removed, and a long post is shortened to its opening line.
• Benzinga News controls {news_benzinga}: Benzinga news articles, plus a Source Filter that narrows them by Benzinga channel. This panel is hidden while VTX has the Benzinga source turned off; its saved settings are kept and the variable is empty until it is turned back on.

The retired {news} variable was Benzinga news; saved prompts that used it now use {news_benzinga}. A panel lights up when the user prompt uses its variable.

• Max Headlines: Sets the maximum number of recent headlines that source sends to the AI.
• Timespan: Sets how far back that source can look, from 1 hour through 7 days. The default is 24 hours.
• Feed freshness: A source whose feed is missing or stale is omitted instead of being presented to the AI as current news.
• Reset: Restores that panel's default settings for the profile.

Headlines are advisory and unverified. News should not replace candles, account state, performance guardrails, or calendar risk controls.

Trading Limits & Frequency

Control the pace and size of the automation.

• Loop Interval: How often the AI runs its analysis (e.g., every 60 seconds by default).
• Unit Size (USDC): The notional size of one trade unit. The largest position the bot can hold is Unit Size × Max Units.
• Max Units: Hard limits to prevent over-exposure:
  • Global: Maximum total absolute exposure units across all assets.
  • Per Exchange: Maximum combined units within one exchange or HIP-3 DEX.
  • Per Asset: Maximum absolute exposure units for one symbol.
  • Per Cycle: Shared BUY/SELL order-unit budget across all symbols in one decision cycle.

Safe Mode (Risk Management)

Automated safety nets that apply to every AI trade.

• Tradability: An application-side filter with a master switch and two independent minimums.
  • Open Position: Rejects an initial position when the final 1-10 Tradability score is below its enabled minimum.
  • Increase Position: Rejects an addition to existing exposure when the final score is below its enabled minimum.
  • Reductions, closes, and position flips are never blocked by these minimums. The filter runs after the model responds, so it is not added to the model prompt.
  • VTX identifies the action from the observed position, so a reduction is not treated as a new entry because earlier position information is missing or different.
  • Position units use entry value consistently in the prompt and execution. A price change alone cannot turn selling a long's displayed units (or buying a short's) into an opposite position. Deliberate reversals remain supported.
  • Reducing a position sells the requested units at their entry value, so selling 5 of 10 displayed units halves the position whatever the price has done since entry, and the next prompt shows 5 units. New positions and additions, including the new side of a reversal, are sized at the current price.
  • A reversal closes the old position first. If the new position then fails to open, the completed close stays in the bot's execution history, next to the failed entry.
  • A rejected attempt remains recorded as the model's original BUY or SELL decision. The Trade page shows Blocked by Tradability with the score and applicable minimum, and no order is placed.
• Stop Loss / Take Profit: Automatically attach TP/SL orders to every entry.
  • Fixed: Leaves the exchange-side stop at its original percentage or USDC distance.
  • Trailing: Checks existing stops at the bot's cadence using fresh data already available to the runtime, including before an inference request. It ratchets the exchange-side stop behind favorable observed price movement using the configured distance, without requiring an AI HOLD response. It never moves the stop backward or loosens protection.
  • Trailing is mechanical application behavior, not an AI-suggested target. It does not add market-data polling. A trailing stop is tightened only while the bot is running in Trader mode. While the bot is stopped or running in Assistant mode, when fresh data is unavailable, or when Client Mode goes offline, tightening waits and the latest confirmed exchange-side stop remains active. Price peaks between observations may be missed.
  • A stop that disappears: If a stop-loss order ends without filling (for example, it was cancelled on the exchange outside VTX) while the position is still open in the same direction, VTX places it again once, at the same stop price, for the part of the position no other stop covers. The take-profit is left as it is. If the replacement stop disappears too, never reaches the exchange, or the exchange rejects it, VTX does not place it again and records the missing stop in the bot's execution history, as it does for a stop lost after the position reversed. A take-profit that disappears is not placed again. A stop is not placed again either when the exchange refused its order as it triggered for a reason placing it again cannot fix (for example, because the order was below Hyperliquid's 10 USDC minimum, which the exchange checks when a stop triggers, not when it is placed); a refusal from a passing market condition, such as no liquidity at that moment, is treated like any other lost stop and placed again once. A stop is also not placed again when the price has already passed the stop price. In both of these cases VTX records the missing stop in the bot's execution history for you to handle. A stop or take-profit the exchange cancelled because its position closed is neither placed again nor recorded as missing, even if a new position in the same direction opened before VTX checked it, once the account's fills show that the earlier position closed first.
  • Cancelling a stop or take-profit yourself: A TP/SL order you cancel through VTX (the Trade page, or an agent's cancel-order action) is treated as your decision: VTX does not place it again and does not flag it.
• Performance Guardrails: Advanced risk controls (like Max Drawdown %) that monitor the AI's trading behavior and halt trading if your current market equity drops from its peak beyond configured thresholds. For HIP-3 markets, market equity follows the selected DEX-specific Perps balance. See Advanced Features for details.

Operations & Scheduling

• Temporary analysis errors: A warning that says Retrying means the running Trader or Assistant will try again automatically. It does not mean you pressed Stop. Market-data warnings distinguish a request with no response from a response that arrived but could not be read; an unreadable response can still have HTTP status 200.
• Expired account data: A decision can be skipped if its account data becomes too old while analysis is running. The warning shows the measured age and allowed limit. Model-attempt details remain available even when the completed decision is rejected; snapshot expiry alone does not establish whether the provider timed out or failed.
• Killswitch: An emergency circuit breaker.
  • Threshold: If your current market equity drops from its highest peak by X% within your configured look-back window (e.g., Y hours), the system halts.
  • Action: Optionally close the bot's open positions immediately upon trigger: the positions on the bot's Exchanges. A position on another venue of the same wallet is not the bot's and stays open. A schedule that closes positions when it stops the bot closes the same ones.
  • Runtime ownership: Server Mode monitors and acts from the VTX server. Client Mode monitors live equity and performs any configured close directly in the active browser or desktop runtime; it is not monitored after that client runtime closes.
• Schedule: Restrict trading to specific hours (e.g., 09:00 - 16:00 London Time).
• Calendar Filters: Prevent trading during high-impact news events (e.g., FOMC, CPI) by defining a "no-trade zone" buffer (e.g., 60 mins before, 30 mins after).

Prompts (The "Persona")

You have full access to the prompt text sent to the AI.

• Prompt Data: Server and Client Mode both render unavailable scalar JSON values as "-" and preserve numeric 0 as numeric data. The active tag line identifies fields whose existing aggregate fallback may also be 0 when source history or a denominator is unavailable. Behavior-state objects use the explicit s="a"|"n"|"u" status contract described above.
• Data Format Instructions: Each active variable uses the same - <tag> = shape; key definitions; units/availability grammar. These lines describe the payload rather than prescribing what conclusion the model should draw from it. Server and Client Mode render byte-identical instructions for the same active fields, and Screener reuses the same contract for selected Main variables.
• System Prompt: Defines the AI's core identity and rules. (e.g., "You are a conservative macro trader...").
• Candle Confirmation: Entry, exit, and reversal conditions follow your active system prompt. Customize the prompt to require any candle-close confirmation you want the model to use.
• User Prompt: The template used to present market data.
• Behavior State: Every Trader template receives one runtime-assembled {behavior_state} block and its generated field definitions. This applies to custom templates even when the saved text omits the variable; VTX does not modify the saved prompt.
• Decision Memory: This is an app-wide backend capability rather than a profile or AI-page setting. Every Trader behavior block receives compact pd data for its previous final Trader decision, pc data for its previous completed position campaign, and et data for the opening trade of its current position campaign. et keeps the opening decision’s original reasoning through later adds and partial reductions; it clears when flat and changes when a new campaign opens. It reports the opening action, requested units, executed opening value, weighted fill price, tradability, age, and reasoning. Missing numeric metadata is "-". et is {"s":"n"} when flat or when a verified opening has no model decision, and {"s":"u"} when the opening evidence cannot be verified against the current position. pd is {"s":"a",...} when available or {"s":"n"} when no qualifying decision exists. pc can additionally be {"s":"u"} when bounded campaign evidence is unavailable. An available pc reports how the campaign closed: cx="m" when a Trader decision closed it, or cx="p" when an automatic stop-loss or take-profit order closed it. A protective close has no close decision, so its cb and cr are "-". Independent lt data uses the same status convention and continues to describe the last executed trade whenever exact fill evidence exists, including while flat. If VTX cannot construct or validate this memory, it skips the current cycle before inference and retries on the next scheduled cycle. There are no per-profile, shadow, or Client-side modes to configure.
• Advanced: You can edit these to enforce specific behaviors, like "Never trade against the 1-hour trend" or "Focus heavily on volume anomalies."

Review Model (Dual-Layer Analysis)

The Review Model acts as a "second opinion" for your AI trader. It allows you to configure a separate, potentially more powerful or specialized AI model to critique and validate the primary model's trading decisions before they are executed.

How It Works

1. Primary Analysis: The main AI model analyzes the market and proposes a decision (for example, "BUY BTC").
2. Trigger Check: For each symbol, VTX classifies the proposal as Open, Increase, Reduce, Close, Flip, or Hold, then checks that intent's Review checkbox.
3. Review Process: If selected, the Review Model receives the primary model's reasoning and the same market data. It acts as a risk manager or senior trader.
4. Final Verdict: The Review Model can:
   • Confirm the trade.
   • Reject the trade (turning it into a "HOLD").
   • Modify the trade (e.g., reduce the size).

Both the primary model and Review Model provide their own tradability score for each symbol, as an integer from 1 (lowest) to 10 (highest). The primary model should follow any Tradability definition or explicit Tradability-based decision constraint in its Main System Prompt. The Review Model receives those Strategy Agent rules and should preserve their explicit Tradability constraints along with any additional constraint in its Review System Prompt; without an explicit constraint, its score remains advisory. The final score shown in decision history comes from the accepted final decision after review or fallback handling. Tradability never replaces the required decision, units, or reasoning, and hard account, risk, capacity, and execution constraints always take precedence.

Note on Client-Side Execution: The robust dual-stage "Reviewer" architecture natively runs even in local/client-side execution modes, ensuring strict trading safety across all executing environments.

Model Label Semantics

• + means a Review Model was used (primary + reviewer).
• -> means a fallback model was used (requested -> actual).
• Both can appear together when fallback and review both occur in the same run.

Configuration

To enable the Review Model, navigate to the Advanced or AI Settings panel.

Core Settings

• Enable Review Model: Toggles the complete review stage on/off. It starts disabled; the individual intent selections remain configured while it is off.
• Review Model: Select the specific LLM to use for reviews.
  • Recommendation: Use a capable reasoning model from a provider you trust for the review layer, even if your primary model is a faster or cheaper chat model.
• Open Position: Review an eligible decision when it would establish a new position. The configured default is on.
• Increase Position: Review an eligible decision when it would add exposure to an existing position on the same side. The configured default is on.
• Reduce Position: Review a partial reduction in exposure. The configured default is on.
• Close Position: Review a complete position exit. The configured default is on.
• Flip Position: Review a decision that crosses through flat to the opposite side. The configured default is on.
• Hold: Review a decision to leave exposure unchanged. The configured default is off.

In a multi-symbol cycle, VTX evaluates eligibility separately for each symbol. The review result is applied only within the symbols selected for that review; a missing or invalid required result becomes a safety HOLD for the affected reviewed symbol rather than changing an unrelated symbol.

Parameters

• Temperature: Controls the creativity of the reviewer (default: 1.0 for strict logic).
• Max Tokens: Limit the length of the review output.
• Timeout: Maximum time in seconds to wait for the review (default: 90s).

Custom Prompts

Just like the primary trader, the Review Model has its own customizable prompts.

System Prompt

Defines the persona of the reviewer.

• The configured default prompt is loaded from the current app configuration and can be edited.

User Prompt

The template for the data sent to the reviewer. It typically includes:

• The Primary Decision (BUY/SELL/HOLD).
• The Primary Reasoning (Why the first model wanted to trade).
• The Market Data (Price, indicators, etc.).

Cost Implications

Each cycle with at least one decision whose intent checkbox is selected adds a separate Review Model call.

• Cycles with frequent qualifying position changes therefore use more provider requests and tokens.
• With the defaults, HOLD does not add a review call. Deselecting other intent checkboxes also lowers review-call frequency.

Screener

The Screener is a symbol-discovery tool. It scans one configured exchange or universe, evaluates each eligible symbol in volume order, and records a model-authored tradability score with reasoning. Tradability is an integer from 1 (lowest) to 10 (highest); if your prompts provide a tradability definition, the model should use it.

Screener does not place trades, change leverage, size orders, or send BUY/SELL/HOLD execution instructions. When Enable Screener is active on the AI page, completed Screener runs can automatically update that profile's AI trading symbols, using Screener scores from that same run only.

For an on-demand comparison, ask your connected Insights assistant to screen symbols. It uses this same methodology and defaults, or an owned profile's effective settings when you name that profile. You can choose exact symbols or let it select candidates within one universe, and override settings for the scan without saving them. The assistant supplies the evaluations and compares repeated passes by their mean and score variability, showing missing evaluations rather than counting them as zero. This read-only comparison does not start a trader, run the configured Screener model, save a profile Screener run, or automatically change symbol assignments.

Where To Configure It

Open the AI page and use the Screener Model panel.

Core settings:

• Enable Screener: Arms the Screener schedule. Screener runs only while AI Trader is running for the same profile. Stopping AI Trader stops any active Screener work; the saved Screener setting stays enabled and becomes eligible to run again after AI Trader starts. When Screener is disabled, it does not run and the panel collapses. Completed runs can automatically switch that profile's AI trading symbols when a candidate passes the Symbol Assignment rules. Default state: off.
• Screener Model: Selects the model used for symbol evaluation.
• Exchange: Chooses the single exchange scanned by each run: Hyperliquid, the default perp DEX, or one HIP-3 DEX that has listed markets. Exactly one is always selected; the count beside each shows how many of its symbols the current filters keep. The Screener can only scan one of the bot's Exchanges (AI page): add an exchange there before choosing it here, and note that an exchange cannot be removed there while an enabled Screener scans it. A symbol assignment never adds an exchange to the bot.
• Symbol Leverage: Keeps only symbols whose exchange maximum leverage matches one of the selected leverage classes, such as 10x. Select several classes to combine them; with none selected, leverage does not filter symbols. Default: none selected. The count beside each class shows how many symbols in the selected exchange have that maximum leverage.
• Minimum Volume: Skips symbols whose 24h volume is below this USD amount, or whose volume is unavailable, before the volume ranking and Candidates Per Run apply. 0 keeps every symbol regardless of volume. Default: 0.
• Current AI trading symbols are still evaluated when Symbol Leverage or Minimum Volume would filter them out, as long as they resolve inside the selected exchange.
• Run Schedule: Controls how often a full run starts. Saved profile schedules override the default; changing the platform default does not replace a saved schedule.
• Schedule Type: With Adaptive selected, each candidate evaluation first checks how your AI Trader is using the same Screener model and provider on your account. The candidate waits, then resumes on its own, while a trader decision on that model is running or just finished, while the trader's response times on it are high or rise during Screener work, or when the next trader decision is due before the candidate could finish. A run that has waited long enough continues anyway so its results do not go stale. With Adaptive cleared, candidates run back-to-back without waiting for the trader. By default, Adaptive is selected.
• Symbol-List Loops: Controls how many full passes over the volume-ranked symbol list happen per run.
• Candidates Per Run: Controls the volume-ranked discovery slice. Current AI trading symbols are always included when they resolve inside the selected universe, so a run may evaluate more symbols than this setting.
• Symbol Assignment: Guarded automation for updating profile trading symbols after a completed run while Screener is enabled. Set the minimum Screener score, minimum edge over replaced symbols, maximum same-account profiles per symbol, and assignment slot count.
• Apart from Adaptive pacing, candidate evaluations run back-to-back with no intentional per-symbol delay.
• Screener Prompts: System and user prompt text for Screener-only evaluation.
• Screener Variables: A selectable subset of the Main model prompt variables, rendered in the same canonical order as the Main model. Screener also adds the read-only screener_volume_context variable for the current candidate's volume rank and exchange context.

Screener Page

Open the Screener page to monitor the runtime.

The page shows:

• Current enabled and runtime status.
• Current and next candidate progress, current run time, current symbol time, next-run countdown, last symbol time/cost/tokens, and last run time/cost/tokens.
• Run counters use three dot-separated values: prompts, symbols, and loops. For example, 125/125 · 25/25 · 5/5 means 125 of 125 prompt calls succeeded, 25 of 25 symbols were covered, and 5 of 5 symbol-list loops were completed.
• Run counters and results use the effective queue, including current AI trading symbols that were added beyond Candidates Per Run.
• Evaluated symbols sorted by displayed tradability descending, then recent evaluation time, then volume rank. Single-loop runs show the latest score; multi-loop runs show the average score plus spread, such as 7.0 ±0.8.
• Current AI trading symbols are shown in bold in the evaluated-symbol list.
• The symbol-assignment panel appears near the run summary while Screener is enabled. It shows a scrollable history table with assignment date/time, starting symbols, and ending symbols.
• Full reasoning for the selected/latest candidate.
• Recorded raw prompt and response context for your profile.

The Screener page is monitoring-only and does not expose separate Start or Stop controls. Enable Screener on AI Configuration arms the schedule, while AI Trader remains the master runtime control: Screener cannot start or continue after AI Trader stops.

Execution Mode

In Server Mode, VTX Macro servers run the Screener loop and model calls while AI Trader is running.

In Client Mode, your browser or desktop app runs Screener execution while AI Trader is running. VTX Macro prepares the candidate list and records status/results, but model-provider calls run from your active app session using your device-local provider keys. If AI Trader is running but no Screener owner is active, the page shows that it is waiting for a runtime owner instead of silently falling back to Server Mode.

Navigating between Trade and Screener in the same app session resumes the existing Screener run. You do not need to restart the trader when opening the Screener page.

Screener model calls are additional provider calls in both modes. Client Mode uses your local device/account provider keys and does not add a VTX Macro platform fee. Server Mode uses the configured server-side model/provider path and qualifying calls can use the same configured server-mode platform fee as other server-side trader model calls.

Candle History

Screener verifies closed candle history when a candidate needs it, including the history required for its enabled market statistics. Missing candles and older snapshots that have not been verified after close are refreshed from Hyperliquid. Verified history is reused across profiles and later scans, and unfinished updates cannot replace it. Screening does not keep every discovered symbol subscribed after the scan.

History loading uses available market-data capacity and yields when trading needs that capacity. A scan can take longer when history is cold or the shared capacity is busy. Pending candidates wait and resume; incomplete or insufficient exchange history remains unscored instead of being treated as poor tradability. An Insights assistant receives a retry delay when a candidate is still loading.

Data Scope

Screener state, runs, candidate evaluations, and assignment history are scoped to the authenticated user and active profile. Scan history is retained according to the configured Screener retention settings.

Symbol Assignment

When Screener is enabled on the AI page, assignment runs after Screener runs complete. If a candidate qualifies, VTX Macro writes the new symbol list back to that same profile's AI trading symbols. That means the AI Trader for that profile may evaluate different symbols on later runs.

Assignment controls:

• Minimum Assignment Tradability: The candidate must reach this same-run Screener score before it can be assigned. Default: 7. Range: 1-10.

• Minimum Assignment Edge: The candidate must beat the replaced current symbol by at least this many score points. Default: 1. Range: 0-9. The minimum value allows equal-score replacements when the other safeguards pass.

• Max Profiles Per Symbol: Limits how many active profiles under the same account may use the same symbol, including the current profile. Default: 1. Range: 1-10.

• Minimum Symbols: Controls how many profile trading symbols Screener should keep even when same-run scores are weak. Default: 1. Range: 1-3.

• Maximum Symbols: Controls how many profile trading symbols Screener may add or manage. Default: 1. Range: 1-3. The app's maximum trading-symbol limit still applies.

• Reset Symbol Assignment: Restores only the Symbol Assignment controls to their default values.

• Assignment compares candidate symbols and current AI trading symbols using only scores from the completed Screener run.

• Multi-loop runs use the average Screener score from that run. Single-loop runs use the latest completed score from that run.

• Trade-page tradability, Main model output, Review model output, and trading prompt scores are not used.

• If your trading symbols changed after the run started, assignment is skipped so an older run cannot overwrite newer changes.

• Symbols with open positions can prevent assignment from removing them.

• Assignment still respects the app's maximum trading-symbol limit.

• The Screener page shows recent assignment changes with date, start symbol metadata, end symbol metadata, tradability, and 24h volume. Runs with no symbol change are hidden by default; use the panel checkbox to include them. The table has search, sort controls, and loads additional rows as you scroll inside the panel.

VTX Insights

VTX Insights connects your agent app to bot trade-chain investigations, connected-harness bot inference, and approved actions on profiles you own. It links settings and decision context to reasoning, executions, fills, positions, and PnL.

Open VTX Insights for setup, permissions, bundled skills, capabilities, examples, troubleshooting, and connection management. Agent apps can read the same guide in machine-readable form.

Bundled skills help your agent answer common questions such as what changed after a settings update, why a campaign won or lost, whether gains were given back, whether fills or fees hurt the result, and which symbols suit your bots.

Insights starts with complete compact summaries and opens full row-level evidence only when a claim needs it. Analyses cover your full stored history; context rebuilt from older prompts is labelled reconstructed. Missing evidence stays unavailable, not zero, and every selected profile stays visible. Replay and excursion calculations run when requested; they are not an always-running simulator or an exact alternate-PnL forecast.

You can analyze public profiles, but changes and trades are limited to profiles you own. Client Mode agent trades are signed by the profile's open VTX app on its device; if none is open, nothing is sent. Private data and actions require VTX sign-in and the matching permission. A requested start is not a running bot until current runtime evidence confirms it.

Insights is the single source for agent setup. Use VTX Help for other guidance or Telegram for community help.

Platform Features & Configuration

The following section covers the core platform settings, defaults, and analysis tools available in VTX Macro.

The navigation shows a profile selector when the page displays or changes a specific bot. This includes Models, Calendar, and Leaderboard: their pricing, AI filters, or copy actions use the selected profile. Billing, Security, Referrals, Insights, Help, Download, and Start do not require a profile selector. Your selected profile is remembered when you visit these pages and return to Trade or other bot pages.

Global Platform Defaults

The following values represent the server-side default configuration. These settings are used as the baseline for the AI Trader unless overridden by your personal strategy settings.

AI Execution

• Default Model: gemma-4-31b-it
• Max Tokens: 8192
• Loop Interval: 60s
• Timeout: 90s
• Unit Size: 20 USDC

In Client Mode, each native model receives its configured request timeout after context preparation, with a separate allowance for saving and confirming the decision. If confirmation is delayed, VTX checks whether that same decision was saved. It does not place a trade after the decision settlement deadline, even when the saved decision is found later.

Preparation remains bounded. A native model timeout can advance to the next saved model when no output was accepted; stopping the runtime cancels the whole chain. When no eligible model remains, VTX ends the analysis and tries again automatically on the next cycle. This does not by itself mean the provider returned a timeout or the trader was paused. Error durations show measured elapsed cycle time when available; older errors without a measured duration omit it.

If an analysis reports that VTX could not obtain Hyperliquid request capacity, it could not start a required account-data read within its deadline. A running bot tries again automatically at its next scheduled analysis. The message does not mean that the AI model failed or that an order was placed.

Trading Safety & Defaults

• Max Units (Global): 10
• Max Units Per Asset: 10
• Max Units Per Cycle: 10
• Max Slippage: 8.0%
• Leverage: 3x (Max 50x)
• Margin Mode: Cross

Small Account Optimization

For accounts with small balances ($10-50), Isolated Margin operations can sometimes fail due to exchange-level dust limits and collateral fragmentation. To ensure your leverage updates always succeed, the system employs an Auto-Recovery mechanism: If an Isolated Margin update fails due to insufficient margin/balance, the system automatically retries the request using Cross Margin. This ensures you can always adjust your leverage without manual intervention, even on small accounts.

Desktop App

VTX Macro Desktop gives Windows, macOS, and Linux users a native app window for the same VTX Macro experience available in the browser.

• The desktop installer is free. Account access and billing stay tied to your normal VTX Macro login.
• In a browser, open Download to install VTX Macro Desktop or continue using the web app.
• Inside VTX Macro Desktop, the Download navigation item is hidden because you are already using the installed app.
• To sign in on desktop, choose Continue in browser on the desktop login screen. Your browser opens and shows which app is asking to sign in; choose Continue and it sends you back to the app signed in. If the browser is not signed in to VTX Macro, sign in there first, with a saved password or Google.
• The desktop app uses the same Trade, AI, Screener, System, Security, History, Billing, and Help pages as the browser.
• Desktop-only behavior, such as Start at login, Start minimized, and Close to tray, is available from the System page while you are using the desktop app.
• Hover over the Windows tray icon to see running/total bots across your fleet, followed by running/total Client and Server Mode bots. Modes with no profiles are omitted. If status cannot be confirmed, the tooltip shows “Bot status unavailable”.
• Client Mode runtimes are owned per profile. Take Over transfers the current profile's runtime to the current window, while Take Over All transfers the other active Client Mode profile runtimes to the same window or desktop app.

Snapshots & Sharing

Snapshots allow you to save your entire AI strategy configuration (Model, Prompts, Parameters) into a reusable profile. This is useful for switching between different trading personalities (e.g., "Conservative Scalper" vs "Aggressive Trend Follower").

How Snapshots Work

• Save: Click the "Save" icon in the Snapshot menu to store your current settings.
• Match: The system automatically detects if your current settings match an existing snapshot or the system defaults.
• Sync: When a matching snapshot is found, it is automatically selected, helping you keep track of your active strategy.

Sharing & Importing

You can share your strategy updates with other users or discover successful strategies from the community.

1. Leaderboard: Browse the Leaderboard to find top-performing users. Click the Copy icon next to a trader's name to instantly import their latest snapshot.
2. Direct Import: Alternatively, search for a specific user by their @handle or Wallet Address in the "Copy User" menu on the AI page.
3. Activating: After importing, the snapshot appears in your library. Select it, then click the Reset button (counter-clockwise arrow) in relevant panels (e.g., Model, Prompts) to apply the settings.
4. Modifying: Once loaded, you can tweak the settings to fit your needs and save it as your own version.

Link Previews

Published update previews show the title and opening content that fits the image. Open the shared link to read the full article. Older News links redirect to Updates.

Public VTX Macro links can show a moment-in-time image of the actual page when a social or messaging service first loads the link. Analytics links keep the selected timeframe and explicitly identify scope=profile, scope=account, or scope=platform; Changelog links use profile or account scope, and Leaderboard keeps its timeframe and page. Marketing, Help, Models, Calendar, Download, Insights, Updates, and published update links use their own page previews instead of a shared logo image. Capture runs without a signed-in session, so it never includes private account state. Shared links include a preview version so a new preview design does not reuse an older service cache. If a preview is temporarily unavailable, VTX asks the service to retry instead of returning an unrelated image. Existing messages can retain the preview that LinkedIn, Telegram, or another service cached when the message was created.

Decision History

History defaults to the last 30 days unless you have a saved selection or open a link with another timeframe.

The History page provides a complete, searchable log of all AI trading decisions and analysis. This is your primary tool for auditing the AI's behavior over time, including both executed trades and "HOLD" decisions.

Features & Filtering

• Search Reasoning: Quickly find specific decisions by searching for keywords within the AI's reasoning text (e.g., "RSI", "bullish", "liquidation").
• Timeframe: Filter decisions by the last 24 hours, 7 days, 30 days, 90 days, 365 days, or view all history.
• Decisions: Toggle between BUY, SELL, and HOLD decisions to isolate specific actions.
• Model & Overrides:
  • Filter by the specific AI model used for the decision.
  • Check Review to see decisions that were processed by the Review Model.
  • Check Fallback to see decisions where the primary model failed and the Fallback Model took over.
• Units: Use the slider to filter decisions based on the number of units traded.
• Blocked: Select Blocked to audit decisions rejected by the Tradability control. The Prompts count updates to the filtered total.

History Feed

The new notification follows the filters currently shown on the page. Incoming decisions that do not match the selected timeframe, decision, model, Review, Fallback, Units, Blocked, or search filters do not increase the notification. Select the notification to refresh the filtered feed.

Each entry in the history feed displays:

• Timestamp & Model: When the decision was made and which model made it.
• Latency & Cost: The time it took for the AI to respond and the cost of the prompt.
• Reasoning: The full natural-language explanation generated by the AI, which includes the final decision.
• Provider Reasoning Trace: When a provider returns a separate reasoning trace and trace capture is enabled, VTX Macro stores it with the decision, shows it automatically in History and Trade Analysis, and keeps it available for the full retained history. Providers do not guarantee a trace on every response.
• Tradability: When available, decision headers append the model's 1-10 tradability score, such as SOL: HOLD - 7 or BTC: BUY (2 units) - 8. Older rows without the score still display normally.
• Blocked Outcomes: If VTX rejected an Open or Add action, the entry keeps the original model decision and shows the score, applicable minimum, and confirmation that no order was placed.

Clicking on any history card that contains an analysis key will open the detailed Trade Analysis page for that specific decision.

Trade Analysis & Decision Transparency

VTX Macro provides complete transparency into every action the AI takes. The Trade Analysis page allows you to inspect the exact "thought process" behind any AI decision, whether it resulted in a trade or a "HOLD".

Accessing Analysis

• Trade History: Click the Sparkles icon next to the timestamp on any trade row.
• AI Logs: Click on any log entry in the AI Activity feed to view the decision context.

Decision Context

• Trade Details: The precise execution price, size, fees, and PnL for the resulting trade (if execution occurred). Entry fills and fills from linked protective orders appear on the same decision page. A confirmed automatic exit is labeled Automatic stop-loss or Automatic take-profit beneath its direction; it does not require another model decision. Fills without a recorded protection link keep their original direction without an inferred exit cause.
• Model Info: The specific AI model used, response latency, and cost.
• Reasoning: The full natural-language explanation generated by the AI (e.g., "Holding because RSI is overbought").
• Tradability: The model-authored integer score from 1 (lowest) to 10 (highest). If the model's system prompt defines Tradability or explicitly makes it a decision constraint, the model should follow that instruction; otherwise the score is useful advisory context. Tradability never replaces the required decision, units, or reasoning, and hard account, risk, capacity, and execution constraints always take precedence.
• Technical Inspection: AI Configuration, the recorded System Prompt and raw User Prompt, and the recorded Last Execution Context used for that decision. These non-secret decision inputs are part of the public Trade Analysis record.

Interactive Chat

Every analysis page includes a dedicated Chat Interface. This allows you to interact with the specific historical context of that decision.

• Ask Follow-ups: "Why did you think the trend was bearish here?"
• Challenge Decisions: "Given the RSI was 30, shouldn't you have bought?"
• Memory: The AI replies using the PAST state data it had at that exact moment.
• Call Details: Each new assistant reply keeps its own inference-call details, including retries and token availability, attached to that exact reply.

Inference-call details and retained provider response/reasoning content are part of the public decision record when they were captured.

Sharing Decisions

Every Trade Analysis page is public. Click Share to copy its canonical /analysis/{profile-handle}/{decision-id} link. The profile handle and decision ID in that one link make it useful for another person or a connected AI agent, such as Codex or Claude Code, without a separate share token.

Analytics & Performance

The Analytics page provides a comprehensive dashboard to visualize and understand your trading performance over time.

The Profile tab shows only the selected profile, Account combines the profiles owned by one account, and Platform pools the current-wallet trading results and completed prompts from every non-test VTX bot. Platform loads only when selected, and all three scopes use the same persisted VTX history, wallet-generation boundary, balance-flow-adjusted calculations, metrics, and charts. Analytics data is built on demand and reused briefly, so opening the page does not add Hyperliquid requests or a background refresh timer. Analytics keeps the selection in the URL as scope=profile, scope=account, or scope=platform, including links copied with the Share button. Changelog remains profile/account scoped.

Account and Platform show Running bots only below the Profile, Account, and Platform tabs. It defaults to on and filters the complete Analytics cohort before VTX calculates cards, charts, prompts, trades, volume, fees, and the symbol table. Profile always remains the selected bot and therefore does not show this control. The setting is shared with Leaderboard: changing it on either page carries the same state to the other page. The emoji button left of it narrows the same cohort to the bots showing one emoji: in Account, that account's bots with it; in Platform, every bot on the platform with it. It offers the emoji the scope's bots show, clicking the selected emoji again clears it, and it shares its choice with the Leaderboard's emoji filter. Signed-in users keep it in their account preferences, while signed-out visitors keep it in their browser. On wide screens, Analytics action buttons appear beside the Analytics heading, the scope tabs stay on the right with running-only beneath them, and the timeframe selector sits below the heading. On narrower screens, the compact scope tabs, running-only switch, and timeframe stack into separate left-aligned rows with consistent spacing.

Profile, Account, and Platform use the same rules for percentage context: VTX needs complete account-value and deposit/withdrawal history for every included profile within the same freshness limit. Percentages use the latest available capital history and can be approximate while that history catches up with trading activity. An Account containing only the selected profile uses the same percentage calculations as Profile. If the required history is unavailable or too old, Analytics keeps showing the current persisted trades, prompts, dollar PnL, and charts and simply hides the unavailable percentages; it never displays n/a in their place.

Key Metrics

• Prompts Processed: Completed AI trading decisions for the selected period. Provider, network, market-data, and legacy failure records remain available for troubleshooting but do not increase this total.
• Total PnL: Your net profit or loss for the selected period.
• Win Rate: The percentage of profitable trades.
• Profit Factor: The ratio of Total Net Profit to Total Net Loss (> 1.0 is profitable).
• Trades: Total number of executed trades.
• Volume: Total trading volume generated.
• Avg Trade: Average PnL per trade.
• Fees Paid: Total trading fees incurred.

Visualizations

• Equity Curve: A chart showing the growth (or decline) of your account balance over time. This helps visualize consistency and drawdown.
• PnL Distribution: A bar chart (histogram) showing the distribution of your trade results. It helps identify if your profits come from many small wins or fewer large wins, and how your losses are distributed.
• Advanced Stats: Click the Sigma button in the Analytics header to open a deeper stats panel for the current filters. It summarizes net return per closed trade, including mean, standard deviation, median, percentile range, min/max, skew, tail ratio, average win/loss returns, payoff ratio, downside deviation, return buckets, sigma bands, and 0.25 sigma resolution inside the central -1 to +1 sigma range. The panel follows the same timeframe and Analytics scope as the rest of the page.

Public Profiles

Every bot has a public analytics profile at its handle (e.g., /analytics/@username). You can view transparency insights and performance history for any trader on the platform. To share a bot, use the short link vtx.run/@handle; it opens that bot's public Analytics page and works as your referral link too.

Tax

The Tax page provides profile-scoped tax-year reporting for your trading activity.

Generating Documents

• Tax Year: Isolate all trade data to a specific, complete calendar year.
• Timezone Selection: The platform uses your designated timezone to calculate exact end-of-year boundaries, ensuring no offset trades bleed into the wrong tax year.
• CSV Export: Produce a clean, formatted CSV download with FIFO tax lots, execution prices, sizes, trading fees, funding, ledger activity, and realized gains/losses for the selected period.

Billing & Payments

Client Mode is free, forever. Server Mode is optional and uses account credits for VTX platform fees. Manage credits and payments on the Billing page. Payments are processed through Stripe. You do not need to purchase credits to use Client Mode.

Usage & Model Pricing

The Models page shows the public model catalog, provider count, and token prices. When your selected profile is in Server Mode, it also shows the flat trader call fee used by server-side trader and Screener model calls. The Billing page is where logged-in users manage credits, subscriptions, invoices, and payment methods.

Server Mode vs. Client Mode Fees

• Server Mode: VTX Macro runs trader and Screener model calls on VTX servers. This is the premium paid runtime and bills the configured platform fee of $0.0025 per qualifying call. Per-prompt and per-run cost displays remain raw model/source cost and do not include the flat fee.
• Server Mode trades: $0.25 per successful Server Mode trade, regardless of whether AI Trader, Copy Trading, the Trade page, an agent, or Insights places it. Exits and SL/TP orders also count. Each distinct exchange order with any confirmed fill is charged once: additional partial fills do not add a fee, while each filled child of a scale, batch, or flip counts separately. Submission alone is not a fill.
• Reserved credit: Before each potentially fillable Server Mode order, VTX reserves its trade fee from your account's shared credit. Billing shows available credit separately from reserved credit. Reservations cannot fund other orders or prompts. Rejected, canceled, expired, or otherwise conclusively unfilled orders release their reservations; uncertain outcomes keep credit reserved until resolved. A partially filled order still incurs one fee if its remainder is canceled. Insufficient available credit can block new orders, including new exits and protective orders. Already admitted protective orders retain their reservations.
• When fees apply: The order's mode when it is admitted determines its trade fee, even if you later switch modes. Historical orders are not charged retroactively. Client Mode execution, tests, dry runs, leverage changes, and cancellations do not incur this trade fee. Trade fees are separate from the qualifying model-call fee and never enter per-prompt or per-run cost displays.
• Client Mode: VTX Macro is free forever and never charges a platform fee for browser- or desktop-app-owned trader and Screener model calls. Your browser or desktop app owns the runtime and initiates model requests. BytePlus browser requests pass through VTX for provider browser compatibility; this does not change Client Mode billing. If you use a paid external BYOK provider, that provider may still bill your provider account directly; VTX Macro does not add a client-mode fee.

The model pricing table shows per-token prices only when VTX Macro has a safe serverless or pay-as-you-go token price for that exact provider model. A - price does not mean the model is free; it means the model may be unpriced, provider-billed through a dedicated endpoint, or billed through another unit such as hosted minutes, hardware, replicas, images, audio, video, or reserved capacity.

For subscription-backed inference, including native BytePlus Coding Plan and connected Codex subscriptions, prompt cost estimates what the recorded token usage would cost at the corresponding published per-token rates. The provider may cover that usage through your subscription. The estimate does not report your subscription charge or remaining quota, and VTX does not convert subscription fees or request allowances into invented token prices.

BytePlus Pay as you go charges usage to your BytePlus account balance. It is selected separately from Coding Plan in System settings: wallet credits do not activate the subscription. In Server Mode and browser Client Mode, placing a Pay as you go key entry after a Coding Plan entry permits fallback to wallet billing for models supported by that route. Without that explicit entry, VTX does not create a pay-as-you-go fallback. Both options use the same VTX platform-fee rules for your execution mode.

Models listed with both $0.00 input and $0.00 output are treated as free by the app's model filters only when both token prices are confirmed as zero. Free models can be useful for evaluation, but they may have lower reliability, weaker performance, stricter rate limits, or changing availability compared with paid models. If you use BYOK providers, review the provider's current terms and free-tier limits before depending on a free model for trading automation.

Referrals

Invite friends to VTX Macro from Referrals. Client Mode is free, forever. Server Mode is optional.

Share your personal referral link. When a new user signs up through that link and completes their first successful prompt, you both receive $100 in Server Mode credits as a thank-you. The prompt can run in Client Mode or Server Mode, including an Assistant dry run. No purchase or trade is required. Failed prompts do not count. Credits cover VTX Server Mode fees; they are not withdrawable cash or trading capital and do not pay your external model provider.

While logged in, open More → Referrals or the link on Billing to copy your link, see your referred signups, and track credits earned. Each signup appears as Pending first prompt until both rewards are credited. The list shows public usernames when available, not email addresses. Each referred signup earns one reward for each person, regardless of how many prompts they run.

Your account's share link uses vtx.run/code, with a randomly generated code made from two short words and a number, such as bluefox42. Choose Edit on the Referrals page to change the code directly in the link, then save it and copy your new link. Codes must be unique; the editor shows the allowed characters and length. Previously shared links keep working after a change and still credit you. The code belongs to your account and is independent of your trading profiles. Opening vtx.run without a code takes visitors to the VTX Macro homepage. A bot link, vtx.run/@handle, opens that bot's public Analytics page and credits the bot's owner exactly like their referral link, so sharing any of your bots also refers friends. Referral links also open the homepage, so your friend can explore before signing up. When they sign up in the same browser, the signup page identifies who referred them and explains the credit reward after their first successful prompt. Client Mode remains free, forever; Server Mode is optional. Sharing the public Referrals page shows its invitation in the link preview; your personal referral link previews the homepage where your friend will land.

Leaderboard & Rankings

The Leaderboard ranks users based on their trading performance across 24h, 7d, 30d, 90d, 365d, and All Time windows. Leaderboard and Analytics default to 30 days unless you have a saved selection or open a link with another timeframe. The homepage leaderboard also shows 30-day results.

Leaderboard snapshots refresh automatically, with running bots updated first, so a row can briefly lag the account's live value.

Leaderboard places search before the emoji filter and the Running bots only and My bots only filters. The emoji filter and Running bots only work without signing in; My bots only needs an account. On phones, Prompts, Trades, and Volume continue the left-aligned reading flow beneath the timeframe; wider layouts keep the compact summary on the right.

The next page loads in the background, and recently viewed pages can appear immediately when you return to them. The leaderboard rechecks the results as you navigate so running status and rankings stay current.

ROI and PnL Calculations

• Total PnL: VTX uses Hyperliquid's aggregate wallet portfolio history for the selected period. This includes the changing value of open positions without inserting today's entire floating PnL into every timeframe, and covers both regular and HIP-3 perpetual accounts in the wallet total.
• ROI (Return on Investment): ROI divides the selected period's PnL by capital at risk, with deposits accounted for and a small-account denominator floor.
• Trades & Volume: The leaderboard also displays the total number of executed trades and total trading volume generated during the timeframe.

Advanced Strategies & Risk Management

This section covers advanced configuration for scaling, market context, and event-based risk controls.

Multi-Trade Execution & Scaling

The AI Trader supports advanced position management strategies, allowing it to scale in and out of positions. This behavior is controlled by three key settings in the AI page:

Max Units (Global)

Limits the total absolute exposure units held across all selected assets.

• Prevents aggregate exposure from growing beyond the configured capacity.
• Reaching the limit blocks additional exposure. Reducing, closing, or reversing without increasing absolute exposure remains available, subject to the cycle budget.
• Example: With a global limit of 10, positions across all assets may use at most 10 exposure units in total.

Max Units Per Asset

Controls the maximum absolute exposure units the AI can hold for one asset.

• Allows Dollar Cost Averaging (DCA).
• Stops additional exposure in that asset when its limit is reached.
• Example: Set to 5 → AI can hold up to 5 separate entries of BTC.

Max Units Per Cycle

Controls the total BUY/SELL order units the AI may execute across all symbols in one decision cycle.

• Acts as a "speed limit".
• Higher values allow faster entry, reduction, closing, or reversal.
• units is the order quantity to execute now, not the desired final position size.
• Example: Set to 2 → the cycle may execute BUY 2 for one asset, or BUY 1 for one asset and SELL 1 for another.

{behavior_state} always reports an explicit compact risk-increase state. ri.s="a" includes ri.tf (the shortest configured candle timeframe), ri.cb (the closed-candle boundary at the latest entry or add execution), and ri.nc (later fully closed candles). ri.s="n" means no risk-increase boundary applies because the symbol is flat, while ri.s="u" means the symbol is open but exact boundary evidence is unavailable. Reductions do not move an available boundary, a direction flip starts a new campaign, and ri.nc=0 remains real observed data. This is informational context for the AI, not a VTX order block; the prompt does not attach any instruction to it.

AI candle context keeps fully closed rows separate from a current live row. When a live row is unavailable, both that field and its format guidance are omitted from the model prompt.

Strategy Examples

• Slow Accumulation: Set Max Units Per Asset to 10 and Max Units Per Cycle to 1. The AI can change positions by at most 1 total BUY/SELL unit per cycle.
• Faster Trading: Set Max Units Per Asset to 3 and Max Units Per Cycle to 3. The AI can move one asset from flat to its full 3-unit capacity in one cycle if the signal is strong.

Market Regime & Performance Guardrails

The system acts as a real-time coach and risk manager for the AI. It analyzes both your account's trading habits (Performance) and the current market regime to inject context directly into the AI's prompt via two key variables: {performance} and {market_regime}.

Performance Panel ({performance})

The Performance Panel monitors HOW the AI is trading to prevent inefficient behavior. It provides a profile-level view of the trader's recent actions over two distinct time horizons: Short-Term (e.g., 6h) and Long-Term (e.g., 24h). This data is injected into the prompt via the {performance} variable.

Performance guidance governs the actions each message states. Drawdown, account-loss, and repeated-loss warnings restrict new risk; they do not by themselves invalidate or require closing an existing position. The AI manages open positions using their market thesis, configured exits, and position-specific risk. Fee, flipping, and holding-time guidance discourages unnecessary turnover and noise-driven exits. Soft guidance is advisory; Hard restrictions are mandatory prompt instructions, not automatic liquidation rules.

• Directional Flip Rate: Detects rapid direction changes on the same market, such as BTC Long -> BTC Short. Activity in another market cannot create a flip. Short-Term and Long-Term each use their own Flip Window, so changing one does not change the other.
• Median Hold Time: Ensures trades are given time to play out. Detects "scalping noise" where the AI exits before a thesis can mature.
• Fee to Equity % (Fee Burn): Calculates the total trading fees paid as a percentage of your total account equity over the rolling window. When fees are elevated, guidance calls for less unnecessary turnover and stronger expected returns after costs. (Note: The system uses an institutional-grade FIFO matching engine to accurately track roundtrip trades, partial fills, and complex scaling in/out strategies for all performance metrics).
• Max Drawdown %: Uses a Peak-to-Current calculation to measure dynamic account loss. The system continuously tracks your highest market equity (including both realized and unrealized PnL) during your configured look-back window. For default Hyperliquid perps this is the default Perps account equity; for HIP-3 DEX markets it is the selected DEX-specific Perps equity, such as Perps (xyz). Warning guidance calls for smaller, better-confirmed new commitments. Critical Hard guidance forbids opening or increasing risk. Existing positions remain governed by their individual thesis, configured exits, and risk; the account-level threshold alone is not a liquidation signal.
• Max Loss %: Measures account loss from the first available market-equity snapshot in the same rolling window to the current market equity. Unlike Max Drawdown %, it does not re-anchor to an intra-window peak; it answers, "how far down are we over this short-term or long-term window?"
• Max Loss Count: Tracks repeated losing closes while the rolling window is net negative. Each losing close increments the count; once rolling net PnL recovers to breakeven or better, the count resets to 0. Threshold checks are inclusive (>=), so hitting the exact warning or critical value triggers that level immediately.

Prompt Injection:

{performance} will contain a JSON summary of these metrics for both time windows, plus a clear instruction if a threshold is breached (e.g., "WARNING: Flip Rate High (Short-Term). Stop reversing direction.").

Market Regime ({market_regime})

The Market Regime system analyzes MARKET CONDITIONS across all your selected timeframes. It provides an "External" view of the environment. This data is injected into the prompt via the {market_regime} variable.

Older Main and Screener templates using {guidance} are converted to {market_regime} when copied into a new bot, saved, or restored. The original saved snapshot is preserved.

• ADX (Trend Strength): Warns if the market is non-trending (Dead). Prevents breakout entries in ranges.
• Chop Index: Detects consolidation. Warns if price action is sideways and dangerous.
• ATR % (Volatility): Measures expected move size. Warns if the range is too small to cover fees.
• RVOL (Relative Volume): Compares recent fully closed candle dollar volume with the 75th percentile of the prior 30 days for the same asset and timeframe. That is a busy level, so most windows read below 1.00x. Low RVOL warns the AI that participation is thin, which is especially useful for avoiding low-liquidity entries outside an asset's active market hours. If there is not enough closed history to calculate RVOL, the snapshot shows - and no RVOL warning is added to the prompt.

Prompt Injection:

{market_regime} will contain a JSON summary of ADX/Chop/ATR/RVOL for each asset, plus a synthesized instruction (e.g., "Market is CHOPPY. Avoid breakout strategies.").

Multi-Timeframe Sync

The system automatically synchronizes with your Candle Timeframes configuration.

• If you select 5m, 1h, and 4h candles, the Market Regime Engine analyzes ADX, Chop, ATR, and RVOL for all three intervals.
• This allows the AI to see nuanced context (e.g., "The 5m chart is choppy and dangerous, but the 4h chart is in a strong uptrend").
• You do not need to configure a separate "Market Regime Timeframe"; it is fully automatic.

Enforcement Modes

Performance and Market Regime guardrails are controlled per metric. Each metric has its own on/off switch and "Soft" or "Hard" enforcement mode; neither panel has a panel-wide enable/disable or enforcement setting.

• Soft Mode: Injects warnings as advice. The AI is told the guardrail is elevated but can decide to trade anyway if it sees a specific setup.
• Hard Mode: Injects warnings as prohibitions. Critical hard-mode breaches can explicitly forbid opening new positions while still allowing the AI to manage or close existing risk.

Market News Context

Market News Context is optional prompt context. Each news source has its own prompt variable and its own AI-page panel (Telegram News, Benzinga News) and appears only when the active prompt includes that variable: {news_telegram} for headlines from configured public Telegram news channels, and {news_benzinga} for Benzinga news, which is empty while VTX has that source turned off. Saved prompts that used the retired {news} variable now use {news_benzinga}.

• What the AI receives: Each source arrives in its own block. Telegram rows carry the timestamp, channel, and headline: every post from the channels the bot reads, newest first, as written. Benzinga rows carry the timestamp, topic, headline, and a short snippet.
• Symbol relevance: Telegram headlines are not filtered by market: a bot gets every post from the channels it reads as general market context. A Benzinga article tagged with a market symbol is included only for bots trading that market; untagged articles are included as general market context.
• Headline limit: Each panel's Max Headlines control caps how many headlines its variable sends, so the model still has room for candles, positions, performance, and risk data.
• Channels: The Telegram News panel's Channels control picks which channels a bot reads; with none picked it reads every channel VTX listens to.
• Timespan: Each panel's Timespan control caps headline age and can be set from 1 hour through 7 days. Telegram News starts with a short window, because recent posts are what explain a sudden move; there the Timespan is the main limit and Max Headlines is a ceiling for an unusually busy stretch.
• Feed freshness: VTX omits a source's block when its feed is missing or stale, even if a retained row carries a recent headline timestamp.
• How to use it: The prompt labels headlines as unverified context, not trading instructions. How much weight the AI gives news is up to your trading prompt; describe it there if you want news handled a particular way.

Calendar Risk Management

The Calendar Risk Management system allows you to control how the AI behaves during high-impact economic events (e.g., FOMC, CPI, NFP). By configuring these settings, you can prevent the AI from trading during volatile windows or use the events as advisory context.

Enforcement Modes

• Soft Mode: Events are advisory volatility context. They do not by themselves justify opening, increasing, reducing, reversing, or closing a position.
• Hard Mode: Opening new positions or increasing exposure is forbidden during the configured risk window. Existing positions remain governed by their own thesis, configured exits, price structure, and position-specific risk.

In both modes, an upcoming or recent event is not an automatic exit signal. The calendar changes how the AI evaluates new risk; it does not invalidate an otherwise valid position.

Risk Configuration

• Impact Levels: Select which events trigger the risk gate (High, Medium, Low, Holiday).
• Currencies: Filter by relevant economies (e.g., USD, EUR).
• Lookahead Window: Define how many minutes before (Pre-Buffer) and after (Post-Buffer) an event the risk rules apply. Fractional configured choices such as 0.5 minutes retain their full precision.

Stale Data Protection

The system automatically checks the freshness of the economic calendar data before every AI execution cycle.

• If the calendar data is outdated (stale), the system will flag it and prevent the AI from making decisions based on incorrect event times.
• This ensures the AI never reacts to "ghost" events or misses a critical release due to data lag.

The Tuning Lifecycle: Scientific & Surgical

Great traders treat their bots like science experiments, not slot machines. The goal is to be intentional: make one surgical change at a time and let the bot run long enough to gather significant data. Randomly turning dials every hour is a recipe for noise, not signal.

1. The Bleeder (Cut Fast)

If a bot executes consistently negative trades and bleeds PnL day after day, it is a bad configuration.

• Reality Check: It will not magically "get better" with more time.
• Action: Kill the profile or revert the settings immediately. Do not fall in love with a losing idea.

2. The Grinder (Tweak It)

If the bot makes trades but PnL hovers around break-even—some wins, some losses, mostly flat—it is promising. It survives the market but hasn't found its edge yet.

• Diagnosis: This is the prime candidate for optimization. Look at the losers: are stops too tight? Is it entering too late?
• Action: Make one small adjustment (e.g., widen stops by 1% or switch from Soft to Hard enforcement). Then wait 24-48 hours.

3. The Winner (Protect It)

If a bot has positive PnL over multiple days or weeks, it is a Winner.

• The Trap: The urge to "perfect" it is dangerous. Any change you make has a high probability of breaking the delicate balance that is working.
• Action: Be ultra-wary of changes. If you must experiment, clone the profile and test your "improvements" on the copy, leaving the original Winner to keep printing.

Disclaimer

Not Financial Advice: The content, tools, and algorithms provided by VTX Macro are for informational and educational purposes only. Nothing on this platform constitutes financial, investment, legal, or tax advice. You are solely responsible for your trading decisions.

Risk Warning: Cryptocurrency trading, especially with leverage, involves a high level of risk and may not be suitable for all investors. You could lose some or all of your initial investment. Do not trade with money you cannot afford to lose.

No Warranty: VTX Macro is provided "as is" without any warranty of any kind. We do not guarantee the accuracy of market data, the performance of trading algorithms, or the uptime of the service. We are not liable for any financial losses incurred while using this platform.