Kronos AI trading bot: build, backtest and turn it into a business

Kronos describes itself as the first open-source foundation model for financial candlesticks, also called K-lines. It was trained on more than 12 billion candlestick records from 45 exchanges around the world, and the accompanying paper, Kronos: A Foundation Model for the Language of Financial Markets, was accepted at AAAI 2026. You give it a table of past open, high, low, close and volume values, and it returns a forecast of the candles that come next.

When we checked on 17 October 2026, the repository had 40.9k stars, 6.8k forks, 213 open issues and 18 contributors. The last change to the main branch was in April 2026, about six months earlier. That matters for a business: you are adopting research code with an active community, not a product with a support contract, so plan to read the code, pin versions and fix problems yourself.

The repository is honest about its limits. Its README says the fine-tuning pipeline is a demonstration and not a production-ready quantitative trading system, that its signals are raw predictions, and that a real workflow needs portfolio construction, position sizing, risk management and realistic modelling of costs, slippage and market impact. That is the gap this guide fills, and it is also where paid work lives.

Kronos is also not a crystal ball. It produces a sampled guess at future prices, and two runs on the same data can differ unless you fix a random seed. Markets react to news, liquidity and other traders' behaviour, and none of that is guaranteed to repeat. Treat every forecast as one input to a rule you have tested, never as an instruction.

Large language models work on tokens, the small pieces of text they predict one after another. Kronos applies the same idea to price data, in two stages.

Stage one: the tokenizer. A specialised tokenizer takes each candle's open, high, low, close, volume and amount and compresses it into discrete codes. Each code has a coarse part and a fine part. The coarse part captures the broad shape of the movement and the fine part adds detail. The diagram's decoder shows the reverse trip: tokens turned back into candlesticks, which is how forecasts become prices you can read.

Stage two: the predictor. A decoder-only transformer, the same family of architecture as GPT-style models, is pre-trained to predict the next token from all the tokens before it. To forecast 24 hours ahead on hourly data, it predicts one candle, adds it to the context and repeats. Sampling settings control how adventurous that guess is: temperature (T) and nucleus sampling (top_p) work as they do in text models, and sample_count runs several paths and averages them.

What the paper reports. The authors report a 93% improvement in RankIC over the leading general time-series foundation model on price forecasting, and 87% over the best model trained without pre-training. They also report 9% lower error on volatility forecasting and 22% better fidelity when generating synthetic candlesticks. RankIC measures how well forecasts rank assets against each other. It is a useful research metric, but it is not profit. Your own backtest, on your market, with your costs, is the only result that counts.

The released models differ mainly in size and context length. More parameters can capture more patterns but need more memory and time per forecast. Start with Kronos-small; it is the best balance for a CPU server.

"Grok" now means two different things, and a trading project can use both.

The Grok API is xAI's developer platform. You send text and get a reply, priced per million tokens. The xAI models page listed grok-4.3 at $1.25 per million input tokens and $2.50 per million output tokens, and grok-4.7 at $2.00 and $6.00, when we checked. The API accepts the OpenAI Python SDK pointed at https://api.x.ai/v1. In a bot, its sensible job is reading headlines and flagging unusual risk: an exchange outage, a hack, a delisting, regulatory action.

Grok Bot is xAI's always-on agent product, launched in beta in August 2026. According to xAI's design notes, each Bot has its own memory, tools and cloud computer, so it keeps working when your laptop is closed. Skills and routines let a Bot repeat a task on a schedule or after an event. Routines must be at least five minutes apart, and xAI's own guidance says to require approval for purchases, publishing and changes to production systems. Launch coverage reported access through SuperGrok Heavy and certain Cursor plans, such as Cursor Ultra at $200 a month. Check current plans before budgeting.

Those limits tell you where Grok Bot belongs: as the operations teammate, not the trading engine. Good jobs for it are reading the trade journal every morning, comparing live results with the backtest, chasing a failing data feed, drafting a weekly performance report and alerting you when something looks wrong. Order placement should stay inside your own code, with hard limits that no language model can talk its way around.

We found no established open-source project called "GrokBot" for trading. Several crypto tokens use the name, and they have nothing to do with xAI. Ignore anything that asks you to buy a token to use a bot.

Most people who search for a Kronos trading bot want a machine that makes money while they sleep. That product does not exist, and selling it as if it did is how traders lose money and builders end up in regulatory trouble. The durable opportunities are in tooling, infrastructure and services around forecasting, where you get paid for work you can actually deliver.

The table compares seven routes. The difficulty and regulatory notes are editorial judgements to help you shortlist, not legal advice.

Sell tools, not returns. A dashboard, an API or a backtesting service charges for software and compute. The customer makes their own decisions. A service that promises profits, pools customers' money or trades on their behalf is a different business: it is regulated, it carries liability, and one bad month can end it.

Sell honesty as the feature. Most trading products show cherry-picked charts. A product that shows every forecast beside what actually happened, including the bad weeks, is rare, and that makes it easier to trust. Keep a public, timestamped track record from the day you launch, and never edit it.

Custom builds are the fastest route to revenue. One prop desk or fund that wants Kronos fine-tuned on its own markets, with a clean data pipeline and a research notebook, can pay for months of development. That money also funds a later SaaS. Write scope, data ownership and confidentiality into the contract.

Synthetic data is the quiet opportunity. The paper reports that Kronos can generate realistic synthetic candlesticks. Risk teams and educators need realistic market scenarios that are not just copies of history. It is a narrower market, but there is little regulatory exposure and it uses a capability most people ignore.

Avoid: signal groups that charge for buy and sell calls, 'guaranteed' copy-trading, managing other people's exchange accounts, and any token tied to your bot. These invite fraud complaints and regulatory action, and they turn a technical project into a trust problem.

Before writing code, decide what each part is allowed to do. Bots that blow up accounts usually fail at the boundaries between parts: a forecast that is trusted blindly, a risk check that can be skipped, or an order that gets sent twice after a network error. Keep these six parts separate, so each can be tested and replaced on its own:

You need Python 3.10 or newer, Git and about 2 GB of free disk space for the models and libraries. A normal laptop is enough to learn on. Kronos detects whether you have an NVIDIA GPU (CUDA), an Apple Silicon chip (MPS) or only a CPU, and its web UI supports all three. A GPU only becomes important when you fine-tune or run thousands of forecasts.

Create a virtual environment so this project's libraries cannot conflict with anything else on your machine. The extra packages are CCXT for exchange data (MIT licence), alpaca-py for paper trading (Apache 2.0), the OpenAI SDK for Grok's compatible API, and python-dotenv for keeping secrets out of your code.

If you would rather click than code at first, the repository includes a web UI. Run python run.py inside the webui folder, open http://localhost:7070, load a CSV and see forecasts drawn against actual candles. It is a quick way to build intuition before automating anything.

Kronos needs a table with timestamps, open, high, low and close columns. Volume and amount are optional, but use them when you have them. Crypto is the easiest place to learn, because exchanges publish candles for free and trade around the clock. US stocks through Alpaca are a second option: free paper accounts get IEX market data.

The script below downloads the last 1,000 hourly BTC/USDT candles from Binance's public endpoint. Public market data needs no API key. Check the exchange's terms before storing or redistributing data in a commercial product. Data rights are a real cost for a SaaS, even when the API is free.

Check three things before trusting any dataset. Make sure the last candle is closed (a candle that is still forming will mislead the model). Look for missing hours, which usually mean an outage. And check for duplicate timestamps. Bad data produces forecasts that look confident and are wrong.

This follows the official README: load the tokenizer and Kronos-small from Hugging Face, build a predictor with a 512-candle context, then call predict. The first run downloads the weights, which can take a few minutes.

Use 400 candles of history to forecast 24 ahead. For future periods you have not seen yet, you must create the timestamps yourself, which the date_range line does. Setting sample_count to 5 averages five sampled paths, which smooths out randomness at the cost of five times the computation. Time this script on the server you plan to use, because that number decides how many markets and timeframes you can afford to cover.

Plot the forecast against what actually happens next a few dozen times before automating anything. You will see that forecasts are often directionally sensible and rarely precise. That is normal, and it is exactly why the next two steps exist.

A forecast is not a trade. You need a rule that says when the predicted move is big enough to be worth the costs. Every round trip pays a fee to enter, a fee to exit and some slippage, so a predicted rise of 0.1% is worthless if the trade costs 0.3%.

The rule below buys only when the expected move clears the round-trip cost plus a safety margin. It is long-only and spot-only on purpose: no shorting, no leverage and no borrowed money. Leverage turns a modelling mistake into a margin call. Learn on the simplest version that can lose only what you put in.

Fix the fee, slippage and margin numbers before you backtest, and do not tune them afterwards until the results look good. Tuning settings to fit past data is called overfitting, and it is the most common way a beautiful backtest becomes a losing bot.

A backtest replays history to see what your rule would have done. Done carelessly, it lies. The script below is a walk-forward test: at each step, Kronos sees only the 400 candles before the decision time, makes a forecast, and the trade is scored on the real candles that followed. Trades do not overlap, and fees and slippage are subtracted from every trade.

Read the output against four questions. Did it beat buy-and-hold after costs, over the same period? What was the maximum drawdown, the largest fall from a peak, and could you live through it without switching the bot off? How many trades were there? Twenty trades prove nothing. Did direction agreement beat a coin flip by a clear margin, or is the profit coming from one lucky stretch?

Then try to break it. Re-run with a different random seed, double the fees, test a different year and a different asset, and hold back the most recent three months completely until the very end. A real edge survives these changes. An accidental one disappears. If it survives, look at the trade log by hand: losing trades often reveal problems with data, timing or costs that summary statistics hide.

Common backtest lies: look-ahead bias (using any information that would not have existed at decision time), survivorship bias (testing only assets that still exist today), ignoring fees and slippage, assuming you trade at prices nobody would have offered you, and testing a hundred variations and reporting the best one. The Kronos README's own warning about costs, slippage and market impact applies here.

Licence note for SaaS builders: popular backtesting libraries carry different licences. backtesting.py is AGPL-3.0, which can require you to publish your source code if users access it over a network. Freqtrade is GPL-3.0. Kronos and CCXT are MIT. The simple loop here avoids that question, and for a commercial product you should get the licence mix reviewed early.

Paper trading runs your bot against live prices with fake money. It catches the problems a backtest cannot: delayed data, rejected orders, time-zone mistakes, crashes at 3am, and duplicate orders after a network error. Run it for at least a few weeks, long enough to see a range of market conditions.

Alpaca's paper trading is free and open to anyone worldwide with an email address. It starts with a simulated $100,000 balance, uses the same API as live trading, and also covers crypto. Alpaca notes that paper trading does not model market impact, slippage from latency or several fees, so expect live results to be worse. For crypto, the Binance Spot Test Network gives virtual balances through the same API. It is reset about once a month without notice, so keep your own records.

The sketch shows the habits that matter. Keys are loaded from a .env file and never written into code. The position size has a hard ceiling. A file named STOP halts all new orders instantly. Stale data is skipped instead of traded on. Every outcome is written to an append-only journal. Compare the paper journal with your backtest every week: if the hit rate or average trade differs a lot, find out why before going further.

Going live is a risk decision, not a coding milestone. Only use money you can afford to lose completely, and start with a small fraction of what you eventually intend to run. Increase it only after weeks of live results that match the paper results. Before the first live order, work through this checklist:

Candlesticks cannot see news. A forecast made one minute before an exchange announces a hack is still based on yesterday's pattern. A language model reading recent headlines can catch some of that, as long as you limit what it is allowed to do.

In the script below, Grok receives recent headlines and must answer with a fixed JSON shape: normal or elevated risk, plus a reason. Elevated risk vetoes new trades for that cycle. Grok cannot size or place a trade. If its reply cannot be read, the code treats it as elevated, so a broken API fails safe rather than open. Temperature 0 keeps answers consistent.

The cost is small. Suppose each hourly check sends about 20,000 input tokens and receives 2,000 output tokens. That is 480,000 input and 48,000 output tokens a day, or about $0.60 plus $0.12 at grok-4.3 prices: roughly $22 a month for one asset checked every hour. Check fewer times, or send fewer headlines, and it drops quickly.

Grok Bot routines for supervision. Give a Bot a skill such as: every weekday at 08:00 East Africa Time, read the last 24 hours of the journal, compare hit rate, average trade and drawdown with the backtest, check that cycles ran every hour, and draft a short report. Add a second routine that alerts you if no cycle ran for two hours. Require approval for any change to configuration. That gives a solo operator a second pair of eyes without giving an AI the keys to the account.

A trading bot needs a computer that never sleeps, so your laptop is fine for research but not for running live. The good news is that hourly Kronos-small forecasts for a handful of markets do not need a GPU. A small Linux virtual private server (VPS) is enough. Here is how the pieces map to infrastructure:

For an hourly strategy, it makes no practical difference whether your server is in Frankfurt, Singapore or the US: a few hundred milliseconds of network delay is irrelevant when you trade once an hour. Choose a provider with a reliable track record, easy backups, and a region allowed by your exchange's terms. Some exchanges block certain countries' IP addresses, so check before you rent.

Location does matter for strategies that trade every few seconds, but Kronos is not designed for that. Each forecast runs a transformer, and high-frequency trading is a competition decided by microseconds and specialised hardware. Do not try to win it with a foundation model on a $12 server.

Secure the server like it holds money, because it does: SSH keys instead of passwords, a firewall that only allows SSH, automatic security updates, a separate non-root user for the bot, and API keys readable only by that user. Never commit the .env file to GitHub.

The figures below use prices from DigitalOcean, RunPod and xAI as listed on 17 October 2026. They exclude your time, taxes, exchange fees and trading losses, which are usually the largest costs. Treat them as planning ranges, not quotes.

A SaaS version lets many users get forecasts, run backtests or watch their own bots without installing Python. The core design decision is whether you ever touch customers' money. Our strong recommendation for a first product is no: a non-custodial tool that informs decisions and never holds funds or trading keys is far simpler to secure, explain and license.

Product shape. Start with one job done well. A good example is a backtesting and forecast-tracking dashboard: the user picks a market and timeframe, sees Kronos forecasts beside actual results, uploads simple rules and gets an honest walk-forward report with costs. That is valuable, demonstrable and not trading on anyone's behalf.

Architecture. Keep the web app (Next.js or similar), the API and the forecasting workers separate. Put forecast and backtest jobs on a queue so a burst of users cannot crash the site. Cache forecasts: if 200 users want hourly BTC/USDT, run Kronos once and serve it 200 times. Store candles once and share them. Rate-limit expensive backtests by plan.

Pricing ideas. Tier by compute and coverage, not by promised returns. For example: a free tier with delayed forecasts for two markets; a paid tier with live forecasts, more markets and a set number of backtest hours; and a team or API tier for developers. The numbers depend on your costs and market, so test them with real customers before fixing them.

If you later offer automated trading, let users connect their own exchange accounts with trade-only, IP-restricted keys stored encrypted, and give them their own limits and kill switch. Before that point, get legal advice, because in Kenya and most other jurisdictions it changes what licence you need.

Licences and attribution. Kronos code and weights are MIT, so keep the copyright notice in your distribution and credit the authors. Check every other dependency, especially AGPL and GPL code in anything you offer over a network or distribute.

A trading engine is the reusable core underneath many strategies: it receives market data, runs strategies, enforces risk, manages orders and keeps the books. Building one is a serious engineering project, and it is also a sellable asset to funds, prop desks and fintech companies. The parts that make it an engine rather than a script are:

We are not lawyers, and this is not legal advice. It does show where the lines now are.

Automated advice is licensed. Kenya's Capital Markets (Licensing Requirements) (General) Regulations, 2025 replaced the 2002 framework. Law-firm summaries from Bowmans and ENS report that the definition of investment adviser now covers digital platforms that give automated, algorithm-driven advice, and that a separate intermediary service platform licence covers apps that channel users to capital markets products. Reported requirements include documented methodologies, risk management, client onboarding and long record retention. A product that tells Kenyan users what to buy may therefore need a Capital Markets Authority licence.

Crypto has its own law. The Virtual Asset Service Providers Act, 2025 came into force on 4 November 2025, according to the Central Bank of Kenya. It makes the CBK and the CMA the licensing authorities for virtual asset service providers. In late 2025 both regulators said no provider had yet been licensed under it, and that licensing would begin once Treasury issued the implementing regulations. Check the current position before offering any crypto service.

Data protection applies too. Exchange keys, trading history and identity details are personal data under Kenya's Data Protection Act. Encrypt them, collect only what you need and have a clear privacy policy.

The safest first product is software that analyses public market data, shows its full track record, avoids personalised recommendations and never holds customer funds or keys. Talk to a capital markets lawyer before adding anything closer to advice or execution.

Most of these mistakes come from moving too quickly. The slow path (research, backtest, paper trading, small live trading, then scale) feels tedious, but each stage is cheap compared with the losses it prevents.

Days 1 to 5: install Kronos, run the README example and the web UI, and read the model code until you understand the inputs and outputs. Download a year of hourly data for one market.

Days 6 to 12: write the walk-forward backtest with costs. Record the results, then try to break them with different seeds, periods, assets and doubled fees. Keep a written log of every variation you try, including the failures.

Days 13 to 15: if a rule survives, set up a VPS with backups, the kill switch, journal logging and silence alerts. If nothing survives, that is a valid result. Move on to a forecasting dashboard or synthetic-data idea rather than forcing a trading strategy.

Days 16 to 28: paper trade continuously. Add the Grok news veto and a Grok Bot morning-report routine. Compare paper results with the backtest every week.

Days 29 to 30: decide, using written criteria set on day 1, whether to go live with a small amount, keep paper trading or change direction. Download the checklist below to keep the plan in one place.