open-nof1.ai: an LLM trading agent for Gate.io and OKX

The agent makes the trade calls, the config sets the limits

open-nof1.ai is described as an AI driven cryptocurrency automated trading system that merges large language model intelligence with quantitative trading practice, built on an agent framework that gives the AI full autonomy over market analysis and trade decisions. The stated design philosophy is minimal human intervention, dropping hard coded trading rules so that the model works from raw market data and decides for itself.

The stack is documented in a table. VoltAgent is the framework, used for AI agent orchestration and management. The model provider is any OpenAI compatible API, so OpenRouter, OpenAI and DeepSeek are all candidates. The exchange layer is Gate.io or OKX, with testnet and live environments. The database is LibSQL, which is SQLite, for local persistence. The web server is Hono. The language is TypeScript and the runtime is Node.js 20 or newer.

The naming in the README and the configuration file is worth reading closely, because the system is not a single mode. The trading strategy is a named value, and the .env.example file lists the choices: ultra-short, swing-trend, conservative, balanced, aggressive, aggressive-team, rebate-farming, ai-autonomous and multi-agent-consensus. The comments there say a lot about what each one does. The swing trend strategy uses a twenty minute cycle and its exit and take profit are controlled by code, while other strategies let the AI handle exits. The ai-autonomous strategy gives the AI full control with no strategy suggestions at all. The multi-agent strategies run a lead agent plus specialist agents, and the file warns that multi agent collaboration consumes more tokens.

So the split is between hard coded execution logic and model judgement, and which side a given strategy sits on is a per strategy decision rather than a global one.

VoltAgent sits between the model, the tools and the exchange

The architecture diagram in the README describes four layers, and the wiring between them explains most of the behaviour.

At the top sits the trading agent, with the README naming DeepSeek V3.2, Gork4 and Claude as the models shown in the diagram. From there three responsibilities branch out: market data analysis, position management and trade execution decisions. Below that is the VoltAgent core, described as the agent orchestration and tool routing layer, which is what decides which tool a given model request maps to.

On one side of the core is the trading tools group, listed as market data, news data, account info and trade execution. On the other is the exchange API client, with order management, position query and a market data stream. The exchange client talks to the trading tools, so the model never touches the exchange directly; it asks for data or for an action, and the tool layer performs the exchange call.

The database sits under the tools, and it stores three kinds of record: account history, trade signals and agent decisions. That last one is the interesting artifact for anyone evaluating the system, since it is a written record of what the model decided and why, and it is what the consistency checking scripts work against.

The messaging side has its own path. A Gate MCP news configuration is documented with a GATE_NEWS_MCP_ENABLED flag, defaulting to true, and a GATE_NEWS_MCP_URL pointing at a default MCP endpoint, which is where the news data in the tools layer comes from. The README says these have default values and need no extra configuration.

Risk limits are configuration, and the shipped defaults are hard

Everything that bounds the downside sits in the .env file, and the values that ship by default are the first thing an adopter should read.

PORT=3100
TRADING_INTERVAL_MINUTES=20
MAX_LEVERAGE=25
MAX_POSITIONS=5
MAX_HOLDING_HOURS=36
EXTREME_STOP_LOSS_PERCENT=-30
DATABASE_URL=file:./.voltagent/trading.db
EXCHANGE=gate

Read as a set, that is a twenty minute trading cycle, up to twenty five times the account value, no more than five positions at once, a thirty six hour maximum holding period, and an extreme stop loss at minus thirty percent, described in the README as the last line of defence against liquidation. INITIAL_BALANCE of 1000 is the number used to size positions, and ACCOUNT_STOP_LOSS_USDT of 50 is an account level stop at which trading halts, against an ACCOUNT_TAKE_PROFIT_USDT of 20000.

A separate drawdown mechanism works off the account's peak value rather than the initial one, and it is configured in three steps. ACCOUNT_DRAWDOWN_WARNING_PERCENT at 20 issues a warning, ACCOUNT_DRAWDOWN_NO_NEW_POSITION_PERCENT at 30 stops new positions and allows only closing them, and ACCOUNT_DRAWDOWN_FORCE_CLOSE_PERCENT at 50 closes everything automatically to protect what is left. The README explains the semantics of each threshold, and the values in the .env file are the documented behaviour rather than a suggestion.

One detail is easy to miss and it changes the numbers: the maximum leverage setting ships at 25, while the .env.example comments advise beginners to use 3 to 5. The comment and the default disagree, and the default is what runs.

Two exchanges, two credential sets, one switch

The exchange is selected by the EXCHANGE variable, which takes gate or okx and defaults to gate, and each exchange has its own credential block.

GATE_API_KEY=your_api_key_here
GATE_API_SECRET=your_api_secret_here
GATE_USE_TESTNET=true
OKX_API_KEY=
OKX_API_SECRET=
OKX_API_PASSPHRASE=
OKX_USE_TESTNET=true
CLOSE_POSITION_PASSWORD=
OPENAI_API_KEY=your_api_key_here

The OKX block needs three values, including a passphrase, which the README lists as required when EXCHANGE is okx. The testnet flags on both sides default to true in the example file, and the README is emphatic about the first run, instructing the user to test in a testnet environment and to make sure the API keys match the selected exchange when switching.

The model side is configured the same way, with an OpenAI compatible key and a model name, and an optional OPENAI_BASE_URL pointing at an OpenRouter style endpoint. The API key list in the README links to the key pages for OpenRouter, OpenAI, DeepSeek, and to the Gate.io testnet and live sites, which tells you which providers the author expected to be used.

CLOSE_POSITION_PASSWORD is a different kind of credential. It protects the manual close position function in the web interface, so the dashboard is not a way to liquidate a position without a second secret. That is worth noting for anyone who intends to expose the dashboard beyond a local machine.

A first run is a database, a process and a browser

The quick start is short. The prerequisites are Node.js 20.19.0 or newer, npm or pnpm, and Git. The install is a clone followed by a dependency install.

cd nof1.ai
npm install

Then the database is created, and there is a dedicated script for it.

npm run db:init

After that the system can be started in development mode with hot reload, or in what the README calls production mode, and the second form is the one that runs the trading loop.

npm run dev
npm run trading:start

The dashboard is then reachable on port 3100, which the PORT variable sets and the Dockerfile exposes, and the README notes a specific failure mode: if the contract account is zero, trading cannot start, and the fix is to transfer funds from the spot account, which applies to the testnet as well.

The package scripts show how much of the operation is scripted. Alongside the start and stop commands there is a restart that stops the port first, a setup script, a set of database commands for initialising, resetting, closing and restarting, checking status, syncing from the exchange, syncing positions and checking consistency, two migrations for adding a peak PnL column and partial close support, and an analyse:trades command that groups trades by symbol. The db:sync and db:check-consistency pair is the safety net for a system that keeps its own state next to the exchange's state.

Docker runs it on a 200 MB memory budget

The repository ships a Dockerfile and two compose files, and the container constraints are the interesting part.

The Dockerfile is based on node:20-alpine, installs bash and sqlite, copies the package files and runs npm ci so that dev dependencies are present for the build, copies the project, runs the build, prunes to production dependencies, and creates the .voltagent directory. It sets NODE_ENV and TZ, exposes port 3100, and defines a health check that hits the health endpoint of the application on that port every thirty seconds with a ten second timeout, a forty second start period and three retries, and the container is started with npm run start.

The compose file is where the constraint shows.

    container_name: open-nof1.ai
    restart: unless-stopped
    mem_limit: 200m
    memswap_limit: 200m
    ports:
      - "${PORT:-3100}:3100"

Two hundred megabytes of memory, with swap capped at the same figure, for a process that runs a language model client, a trading loop and a web dashboard in one container. That is tight for a Node.js service holding market data in memory, and it is a reasonable signal that the intended deployment is a small instance rather than a busy machine.

The compose file also sets the timezone to Asia/Shanghai, mounts the database directory and the logs directory as volumes for persistence, puts the service on its own bridge network, and caps the json log file at ten megabytes with three files kept. The start script itself passes a memory flag to node, which is a second place the same budget is expressed.

AGPL terms, one release, and repository metadata that was never updated

The project is licensed AGPL-3.0, with the LICENSE file at the top of the repository and the package.json license field reading the same. The AGPL is the copyleft licence with a network clause, so a modified version offered over a network has to offer its source to users. For a self hosted trading system that is not usually the deciding factor, but it matters for anyone who plans to fork it into a service for others.

The version is 0.1.0 in the package.json, and the release list shows a single GitHub release, v0.1.0 with a Gate.io edition label, dated 2025-10-28. The last push was on 2026-05-15 and the repository is not archived, so work continued after that tag, but there is no newer published version to install.

One small sign of an early stage project is worth flagging. The repository, bugs and homepage fields in package.json all point at a placeholder address rather than the project it is actually in. That does not affect the code, but it tells you the packaging metadata was not maintained alongside the source.

For an adopter the practical consequences are modest. The upgrade path is to pull the branch and re-run the install, the scripts cover the database migrations that a schema change needs, and the risk settings live in configuration rather than in code, so the two things most likely to need adjusting, the risk parameters and the strategy, are the two things you can change without touching TypeScript.

Editorial conclusion

open-nof1.ai fits a developer who wants to study or prototype LLM driven trading on a testnet with a documented risk configuration, and it does not fit anyone who wants a strategy that behaves predictably in live markets. Before running it, set GATE_USE_TESTNET or OKX_USE_TESTNET to true, start from a low position size setting, and confirm that the account and the agent decision log line up through the db:check-consistency script.

Frequently asked questions

Official sources

1. 195440/nof1.ai on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases