An AI trading research assistant is a persistent agent that writes, backtests and stress-tests trading strategies on a remote machine while you send instructions from Telegram. This build uses the Hermes agent with a GPT-6 model, the Jesse framework for Python strategies, and a VPS so the research continues after your computer is off.
What the AI trading research assistant setup actually does
An AI trading research assistant is a persistent agent that writes trading strategies, backtests them, optimizes parameters and stress-tests the results on a remote machine, while the operator sends instructions from a chat app. The build shown here pairs the open-source Hermes agent with a GPT-6 model through an OpenAI subscription and the Jesse framework for Python strategy code. The machine runs continuously; the human does not.
The loop has four stages. The agent installs the research stack on a VPS, imports historical candles, writes and backtests strategy code through Jesse's MCP integration, then runs optimization and Monte Carlo simulations to check whether the results survive randomization. Telegram is only the control surface; the work happens on the server.
The video this article is based on was published in 2025 (transcript source: GPT-6 + Hermes: I made a 24/7 AI Trading Research Assistant). It reconstructs that setup, then examines the strategy it produced. That last part matters more than the installation, because the agent's own output failed the criteria its operator set, and the failure is more instructive than the tutorial.
How the Hermes agent connects to GPT-6 and Telegram
The Hermes agent connects to a model provider through a single command, hermes model, which lists providers including an OpenAI ChatGPT subscription option alongside direct API access. Choosing the subscription path opens a browser authorization flow and returns a code to paste into the terminal. The agent then detects the credential automatically.
Model selection and reasoning level are separate steps. In the transcript the operator selects a GPT-6 variant (labelled Astro) and sets reasoning to medium, noting that high or extra-high are available for heavier work. Reasoning level is a cost and latency dial, not a capability switch, and the video treats medium as sufficient for research loops where the agent runs unattended.
Telegram connects through hermes gateway setup, which supports a long list of messaging platforms. Two paths exist for Telegram: scanning a QR code, or creating a bot through Telegram's BotFather and pasting the token into Hermes. The second path also requires the operator's own Telegram user ID, so the gateway can reject messages from anyone else who finds the bot.
That second step is the security boundary of the whole build. Without an allowlisted user ID, any Telegram user who discovers the bot can issue commands to an agent that has shell access to the server. The bot token authenticates Hermes to Telegram; the user ID authenticates Telegram users to Hermes.
Why a VPS beats a home machine for unattended research
A VPS keeps the research loop running when the operator's computer is off, which is the difference between an assistant and a script. In the transcript the presenter already runs two Hermes instances at home, on a Mac mini and a Raspberry Pi in an office, and adds a hosted server for this build so the workload does not depend on his main machine staying awake.
Server sizing in the video is deliberately modest. The chosen plan (Hostinger's KVM2) provides two CPU cores, one reserved for the operating system and one for the agent's work, which is the reasoning the presenter gives for skipping the smallest tier. Memory and SSD on that plan are described as more than sufficient for importing candles and running backtests. The presenter also picks a European or Asian server location over North America because some crypto exchanges exclude those users, which can block data access for the strategy research.
The hosted option also ships a one-click Hermes deployment, which shortens the boring part. The presenter's agent finished installing Python, PostgreSQL, Redis and Jesse in about six minutes without manual configuration, then created a project and started importing candles.
Installing Jesse and importing crypto data by instruction
Jesse is installed by pasting its Ubuntu setup documentation into the agent's chat rather than by typing commands. The presenter copies the existing-installation instructions, asks the agent to follow them, and adds a request to use a Python environment manager (Miniconda) so dependencies stay isolated. The agent executes the instructions on the server.
The same message includes the first substantive research task: create a Jesse project, connect its database, and import BTC/USDT data from Binance futures covering three years. Data import runs in the background while the agent handles other requests, and ETH/USDT import is queued afterward.
Two obstacles appear in the transcript and both are worth expecting. First, the Jesse dashboard binds to localhost by default, so on a VPS it is unreachable from a browser until the agent is told to expose the external IP and the container port mapping is opened. In the video, port 9000 on the host is mapped to port 9000 inside the container so the dashboard becomes reachable. Second, the default dashboard password is a placeholder, and the agent changes it in the project environment file and restarts the service.
Jesse's MCP integration requires a Jesse account and an API key placed in the project environment file. The presenter generates the key, hands it to the agent, and never opens the file. That pattern, where credentials move through chat into config, is convenient and also the part of this setup most worth reconsidering for anything beyond a tutorial.
How the research prompt defines success and failure
The research prompt specifies the strategy family, assets, time frames, risk and stopping condition. It asks for a trend-following strategy on BTC/USDT and ETH/USDT, a Sharpe ratio of at least 1.5 over the requested period, 3% account risk per trade, optimization to improve results, Monte Carlo simulation to check for overfitting, both long and short trades, futures mode rather than spot, hourly trading time frame with a four-hour anchor, and a hard budget.
That budget is the part the presenter calls essential. The agent is told to continue until it either meets the criteria or has tried at least 200 strategy variations. Without a stated limit, the presenter says the model tends to stop early and return whatever it has. With a limit, each variation runs a full backtest, optimization and Monte Carlo cycle. The presenter notes that a stricter budget is easy to set: 2,000 variations instead of 200 or 300 is realistic because the remote machine absorbs the load.
The specification deserves scrutiny. A Sharpe threshold of 1.5 on a two-year crypto sample is a demanding target, and search budget plus a stop condition turn the task into an optimization problem where the agent can keep generating variations until something clears the bar. The presenter acknowledges at the end that his criteria were too harsh, which is a reasonable summary but not the whole issue.
The agent's search budget and escalation are worth stating as concrete steps:
- Run 200 trend-following variations per asset on the hourly frame with a four-hour anchor, each with backtest, optimization and Monte Carlo.
- If no finalist clears the Sharpe threshold, run 200 more per asset and switch the trading frame from hourly to 30-minute.
- If that still fails, run 300 more per asset on the 30-minute frame.
- Stop when the criteria are met or the budget is exhausted, then report the best candidate and its Monte Carlo screens.
What the agent found after more than 1,000 strategy variations
The agent exhausted its search budget without meeting the Sharpe criterion. After the first 200 variations it reported no qualifying strategy, with ETH results near a Sharpe of 1.34 and BTC weaker. The presenter then instructed it to run 200 more variations per asset, switch from hourly to 30-minute time frames, and try 300 more per asset.
In total the agent ran more than 1,000 variations and reported that both requested stages were exhausted with no finalist clearing a Sharpe above 1.5 together with the robustness requirements. The best result it surfaced was ETH/USDT on the 30-minute time frame, and the presenter opened the backtest on the Jesse dashboard to inspect it.
Reported metrics for that best run: 99 trades, P&L of 149% over roughly two years, maximum drawdown of 21%, maximum underwater period of 227 days, annual return of 57%, win rate of 39%, average holding time of 37 hours, Sharpe of 1.47 and 4.13 trades per month. These are the agent's own backtest outputs inside Jesse, not an independent verification, and the dashboard showed the returns improving partly as a benchmark-relative result against a choppy ETH market. The presenter also notes that the worst year was the current one at around -2.5%, because the year was not finished.
The agent also tested the two strategies as a combined portfolio. It reported that running BTC and ETH together smoothed returns but still missed the Sharpe criterion, and every URL in the generated report pointed at localhost (127.0.0.1) until the agent was asked to substitute the VPS external address.
Monte Carlo results: where the backtest looks weaker
Monte Carlo simulations test whether a backtest result holds up under randomization, and Jesse runs two relevant variants. Monte Carlo trades reshuffles trade outcomes to estimate position-sizing risk. Monte Carlo candles perturbs price series to estimate how sensitive the strategy is to the specific historical path.
On trades, the original backtest maximum drawdown was about 20%. Across simulations the median drawdown was about 30%, the worst 5% reached roughly 57%, and the best 5% was about 18%. The presenter argues the median is the realistic planning number and that 30% is acceptable for his risk tolerance, while treating the best 5% as luck he will not rely on.
On candles, the gap is sharper. The original Sharpe of 1.47 sat well above the simulated median of 0.80, and the presenter notes it was closer to the best 5% figure of about 1.74 than to the median, which he reads as a warning that the strategy may be partly fitted to the specific ETH price path. Net profit shows the same pattern: 149% in the original backtest against 53% at the simulated median.
His conclusion, stated plainly in the video, is that the strategy is acceptable but not robust. A separate out-of-sample backtest on the two years before the main test period produced a similar verdict: a high headline return of about 153% with an equity curve that does not support the headline.
Monte Carlo trades versus Monte Carlo candles at a glance
| Simulation | What it randomizes | Original backtest | Median | Best 5% |
|---|---|---|---|---|
| Monte Carlo trades (drawdown) | Trade outcomes | -20% | -30% | -18% |
| Monte Carlo candles (Sharpe) | Price series | 1.47 | 0.80 | 1.74 |
| Monte Carlo candles (net profit) | Price series | 149% | 53% | not reported |
Costs, slippage assumptions and what the numbers leave out
The transcript reports trade counts and P&L but not an explicit fee model in the article's terms, which limits how much the 149% figure can be compared with anything. The presenter notes that trading fees in the Jesse configuration were set higher than typical exchange rates on purpose, to approximate slippage, and that enabling per-trade execution slows the engine.
The distinguishing evidence in the video is not the strategy. It is the cost and latency profile of running the loop on a rented machine. Overnight runs, thousands of variations and continuous data imports cost nothing on the operator's own hardware, and the presenter's point about scaling from hundreds to thousands of attempts is about time, not money. A VPS with two cores handled the whole research cycle, including PostgreSQL, Redis and the Jesse engine.
What the video does not show is live trading. Every result is a backtest or simulation inside Jesse, the strategy failed its stated criteria, and the presenter says explicitly that the point of the exercise was the research setup rather than a finished strategy.
Risks worth naming before you copy this build
An agent with shell access, an allowlisted chat interface and stored exchange data is a small production system, and it deserves the same care. The transcript's own sequence shows the failure modes: a dashboard password that started as a placeholder, a localhost URL that needed external exposure, a container port that needed opening, and an API key pasted through chat.
The research risks are separate. Iterating until a Sharpe threshold is met, with a large search budget, increases the chance that the surviving strategy is fitted to the sample regardless of Monte Carlo screening. The presenter's own candle simulation, where the backtest Sharpe sits near the optimistic tail rather than the median, is the clearest evidence for that concern inside the video.
A few practical warnings that the transcript itself demonstrates:
- The Jesse dashboard password is a placeholder (the transcript shows "test") until you change it in the project environment file.
- The dashboard binds to localhost (127.0.0.1) by default; you must expose the VPS external IP and open the matching container port.
- The Jesse MCP API key should be treated as a secret; pasting it through chat is convenient but leaves it in message history.
- The Telegram gateway needs your own user ID as an allowlist, not just the bot token.
Nothing in the transcript supports running this configuration with real funds on the strength of these results. The presenter says he is not a financial adviser and frames the video as a tutorial.
FAQ: practical questions about the Hermes and Jesse research loop
Do I need an OpenAI subscription to run this?
The Hermes agent supports multiple providers through the hermes model command, including an OpenAI ChatGPT subscription path and direct API access, so the agent is not tied to one vendor. Model choice and reasoning level are selected separately after the provider is connected. The presenter uses an existing OpenAI subscription because he found it the most affordable way to run repeated experiments.
Why does the Jesse dashboard not open from a browser on a VPS?
Jesse binds its dashboard to localhost by default, which is unreachable from outside the server. Exposing it requires telling the agent to use the VPS external IP and opening the matching container port, which is what the transcript demonstrates when it maps port 9000 on the host to port 9000 inside the container.
Is the Telegram bot safe once it is created?
The bot token alone is not enough; anyone who finds the bot could message it. The Hermes gateway setup asks for your own Telegram user ID so it only accepts messages from that account, which is the allowlist boundary for an agent with shell access. The presenter creates the bot through Telegram's BotFather and pastes the token into the terminal.
What is the difference between Monte Carlo trades and Monte Carlo candles?
Monte Carlo trades reshuffles trade outcomes to estimate drawdown and position-sizing risk, while Monte Carlo candles perturbs price series to test sensitivity to the historical path. In this build, trades gave a median drawdown of about 30%, and candles gave a median Sharpe of 0.80 against a backtest Sharpe of 1.47.
Did the agent find a strategy that met the requirements?
No. It ran more than 1,000 variations across two assets and two time frames and reported that no finalist met the Sharpe target of 1.5 together with the robustness requirements. The best result was ETH/USDT on the 30-minute time frame at a Sharpe of 1.47, which the presenter describes as acceptable but not robust.
What is the YOLO mode and should I enable it?
YOLO mode lets the agent run terminal commands without asking for confirmation each time, which fits an isolated VPS where the whole point is unattended work. The presenter enables it for the session because the machine is dedicated to this task. On a shared or sensitive server, leaving confirmation prompts on is the safer choice.
Can I run more than 200 variations?
The presenter considers 200 or 300 variations a light budget and suggests 2,000 is realistic, because the remote machine absorbs the load and the operator's own hardware stays free. More variations raise the chance of finding something that clears the bar, and also the chance of fitting to the sample, so pair a larger budget with out-of-sample and candle-simulation checks.
Where does the strategy source code live?
The presenter shares the prompt source code in the video description. There is also a community strategy index inside Jesse where members and the presenter have submitted strategies; from the dashboard or the Jesse website you can inspect metrics for other periods, symbols or time frames, download the source with one click, and adapt it. See the video at https://www.youtube.com/watch?v=OSaEdG_y_lU.
How long does the whole setup take?
The install itself is fast: the agent installed Python, PostgreSQL, Redis and Jesse in about six minutes, then created the project and began importing candles. The research phase is the slow part, running for hours to days depending on variation count and time frames.
Why the failed search is the useful result
The value of this setup is not the strategy it produced. It is that an unattended agent can install a research stack, import three years of crypto data, write and backtest over a thousand strategy variations, and return a report with Monte Carlo screens attached, while the operator works on something else. That changes the scale of experimentation available to a solo researcher.
It also changes the failure mode. A search budget of 1,000 variations with a fixed target is a specification for finding something that clears the bar on the tested sample. The presenter's own Monte Carlo candle results show the backtest Sharpe sitting near the optimistic tail of the simulated distribution, which is the honest signal about how much to trust the 1.47.
If you build this, treat the agent as a fast generator of candidates and the dashboard as the arbiter. The out-of-sample test and the candle simulation did more to qualify the strategy than the headline return did.
Turn your own trading research video into a written article
The core lesson from this build is that a research process only counts when someone can read the evidence: the variation count, the out-of-sample test, the Monte Carlo tail. The same is true of the explanations you record. If you have already walked through a setup, a backtest or a post-mortem on YouTube, that reasoning is sitting in a video where search engines cannot index it and readers cannot skim it.
Skalablog takes a YouTube URL, transcribes the video, and generates a structured article you can review and edit before publishing. The steps you demonstrated on screen, the numbers you quoted and the caveats you added become a page your audience can actually find and quote. Builders who publish their own trading or data projects, such as Dev Doido do canal do youtube, face the same choice between a searchable article and a video that only viewers can reach.
Other resources: CrazyStack
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits