trading-terminal turns a chart drawing into a validated Freqtrade strategy

The loop: draw a level, ask a question, get a plan back

The entry point is unusual enough that it deserves a description before any technical detail. You open the terminal, draw on the chart, and ask a question in ordinary language. The example in the README is a mean reversion question on HYPE at the 15 minute timeframe. The agent then reads your actual chart, which means your drawings, the visible range, the indicators you have plotted and a screenshot of the chart, and it answers with a plan rather than with prose. The plan has a fixed shape. An entry with the condition that triggers it, a stop with the percentage distance, a target with the percentage distance, and an invalidation expressed as a close below a level on the stated timeframe. In the README example the entry is a close crossing back above the band at 38.20, the stop is 36.90 at minus 3.4 percent, the target is 41.05 at plus 7.5 percent, and the invalidation is a 15 minute close below 36.50. The README says the agent then ranks more setups beside the one you drew, each with entry, stop, target and an R multiple. So the drawing is a way to propose, not a way to commit. You get alternatives, and you pick one. That design choice is what makes this worth an engineer's attention. A chart annotation is a compact, unambiguous statement of intent, and it sidesteps the prompt engineering that most chat interfaces rely on.

The validator is the part that matters

The README is explicit about where the real work is. The interesting part of this repo is not that a model writes Python, it is what happens between the model wrote it and it is trading your funds. Every generated strategy is parsed and checked before it can be submitted. The checks are listed in a table, and they are the kind of rules that only exist because someone got hurt without them. The README says it plainly: most of these are scars, they exist because a strategy reached production without them. No shift(-N) in populate_* is the first one, and it prevents reading future candles, because the backtest looks superb and live behaves nothing like it. Stops must be scaled for the position multiplier, because a 3.7 percent price stop written raw at 10x is ten times tighter than intended, and the bot churns fees until the balance is gone. Entries must gate on volume greater than zero so signals do not fire on dead candles. Two of the checks are subtler and worth reading twice. startup_candle_count must be at least three times the longest lookback, because indicators are NaN live, so the bot silently never trades while the pod stays healthy and nothing happens. And TA-Lib tuples must be indexed by position, because bollinger['upperband'] raises on every candle, and one live strategy did this for ten hours while its entry condition was met seven times. Both of those are failure modes where the system looks fine and does nothing, or looks broken and does something wrong. That is exactly the class of bug a static validator catches and a backtest does not.

Rejection is not an error, it is a repair loop

How the validator is wired to the model is what separates this from a lint step. A rejection is not an error you see. The complaints go back to the model, which rewrites the strategy, and the loop repeats until it passes. The complaints are therefore not diagnostics for a human, they are feedback for the model. The generated artefact is a Freqtrade strategy, and the README shows what one looks like.

def populate_entry_trend(self, dataframe: DataFrame, metadata: dict) -> DataFrame:
    dataframe.loc[
        (
            (dataframe['volume'] > 0) &                      # no signals on dead candles
            (dataframe['close'] < dataframe['bb_lower']) &
            (dataframe['rsi'] < 40) &
            (dataframe['close'] > dataframe['ema_50'])
        ),
        'enter_long'
    ] = 1

Note that the volume guard and the comment explaining it are already in the generated code. The rule set has shaped the output, and the comment is part of the artefact. The validator's rule set and the repair loop are written up in docs/strategy-pipeline.md, which the News section of the README says has the full set and explains the loop. The August 2026 note frames it as an accumulated history: every rule exists because a strategy once reached production without it. That is a different philosophy from a one-shot prompt. The system treats the model as a fallible generator and puts a deterministic gate in front of it, and the gate is allowed to send work back rather than failing the request.

Self-hosted versus hosted, and what changes for your keys

There are two ways to run it, and the README is careful to describe the difference in terms of who runs the process rather than what you get. The hosted build at terminal.superior.trade is this repository with a login in front of it. Both talk to the same Superior Trade API and trade the same accounts. Running your own copy means your keys stay on your machine, and every prompt and safety rule is yours to change. It also means no login, per SECURITY.md, withdrawals that stop one hop short per docs/withdrawals.md, and getting your own TradingView access before the chart will build. That last point is a real operational dependency for the self-hosted path. The README's news section records that as of 2026-08-21 a fresh clone runs without TradingView, because the bundled Lightweight Charts preview boots first, and Advanced Charts drops in later through npm run setup:charts. So the chart is available from the start, but the full TradingView Advanced Charts experience needs the extra step and your own access. The features table separates the two builds explicitly. Self-hosted only means an embedded Postgres, no login, no telemetry unless you turn it on, and every prompt editable. There is also a path for people who do not want a UI at all. The README says that if you want an agent trading directly, with no UI and no clone, hand it one line, Read https://superior.trade/SKILL.md and register, which works from Claude Code, OpenClaw, Codex and Cursor. Pointing a coding agent at the repository instead is handled by AGENTS.md, which exists at the root of the tree.

Running it yourself: clone, install, add two keys

The setup section is titled Run it yourself and its subtitle is Two keys. Nothing else to sign up for.

git clone https://github.com/Superior-Trade/trading-terminal.git
cd trading-terminal
npm install
cp .env.example .env.local     # add the two keys below

The .env.example file names those two keys. SUPERIOR_TRADE_API_KEY executes backtests and runs live strategies, and you create one at superior.trade under Account and API keys. OPENROUTER_API_KEY powers the chat agent and setup detection, created at openrouter.ai/keys. The environment file also documents a set of optional settings that are worth knowing about, because they tell you where the vendor draws its defaults. AGENT_MODEL, DETECT_MODEL and COMPACT_MODEL override the compiled in defaults, and the comment says to trade cost against quality. FALLBACK_MODEL is retried automatically when the agent model errors or rate limits. NEXT_PUBLIC_CONTEXT_WINDOW_TOKENS sets the context budget the chat compactor works to in tokens, and the default suits roughly 200k models. The database is optional in the same way. DATABASE_URL unset, the default, runs an embedded Postgres stored in ./.data/pglite with no server to install and no account to create, and PGLITE_PATH says where it keeps its files. Point DATABASE_URL at any Postgres URL to use one instead, and a *.neon.tech host automatically uses the Neon HTTP driver. DB_AUTO_MIGRATE applies migrations on boot for a database URL you supplied, while the embedded database always migrates itself. The package.json tells you the rest. Node 20.9 or later, Next.js 16, dev on port 3200, and scripts for db:generate, db:migrate and db:push through drizzle-kit, plus test, lint and check-types.

The stack under the interface

The dependency list in package.json is where the real design shows. The chart is TradingView Advanced Charts with the bundled Lightweight Charts as the fallback, and lightweight-charts is a direct dependency. The data feeds are Hyperliquid and Lighter, with @nktkas/hyperliquid as the client library. Order flow footprint, liquidation heatmap and tier ranked indicators are part of the Chart row of the features table. The agent side uses the ai package from the Vercel AI SDK with @ai-sdk/react and the OpenRouter provider, which is why OPENROUTER_API_KEY is one of the two required keys. The model choice is per task, with agent, detect and compact models separately overridable, which is the shape you want when setup detection is a cheaper job than conversation. Persistence is Drizzle ORM on Postgres, with drizzle-kit for migrations and both @electric-sql/pglite and pg in the dependency list, matching the embedded or external database choice. The generated strategy targets Freqtrade, and the repository topics also list Nautilus-Trader, so the execution layer is not limited to one framework. The strategies row of the features table says Freqtrade code generation with deterministic safety validation, automatic repair and historical backtests. The execution row covers live deployments, bracket orders for one shot plans, position sizing, position size caps and a time boxed auto stop, and the loop describes live PnL with an auto stop timer if the edge is time boxed plus an inbox that tells you when something happened. Observability is there too, with @sentry/nextjs and sentry.edge.config.ts and sentry.server.config.ts at the root.

Licence, versioning and what is not promised

The licence field on the repository says Apache-2.0, with a LICENSE file and a NOTICE file at the root of the tree, and the README carries an Apache 2.0 badge. A permissive licence with an explicit patent grant, which is the easy case for a commercial team to accept. The version in package.json is 0.1.0, and the repository has no GitHub releases at all. The last push was on 2026-10-09 and the repository is not archived. A version of 0.1.0 with no release tags means you install from the default branch and you pin to a commit, not to a version number. Two gaps are worth naming. First, the README does not say what the agent's prompts look like by default, only that every prompt is editable in the self-hosted build and that the validator rules live in docs/strategy-pipeline.md. If the model behaviour matters to you, that documentation is where you look, and the repository is where you change it. Second, the repository describes a tool that trades real funds on a perpetual futures venue. Nothing in the README is a performance claim, and there is no backtest result published, so any evaluation has to start with your own history rather than with numbers from the project. The last thing to check before going live is the execution configuration, because the features table names position sizing and position size caps as terminal features rather than describing fixed limits, and the environment file makes it clear that the vendor's defaults are compiled in and overridable.

Editorial conclusion

Adopt trading-terminal if you run Hyperliquid strategies and want a chart driven way to author them, and you are prepared to run an agent loop and a local database yourself. Do not adopt it if you want a signal service you can trust blindly, because the strategy it produces is model written code and the validator only covers the rules listed in the documentation. Before going live, read docs/strategy-pipeline.md and confirm the two API keys are set with the drawdown and position size limits you intend, since the defaults are the vendor's choice.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. Superior-Trade/trading-terminal on GitHub