Operational case study · By CoinNudge Research · · Guide updated 2026-10-03 · 20 min read
Why Is My AI Crypto Trading Bot Not Placing Orders?
An AI crypto bot can be online without placing orders because a scheduled review did not run, the input was stale, the model deliberately waited, a response failed, a hard control rejected it, or an accepted limit order never filled. Trace one decision ID to its last completed stage before changing the strategy. CoinNudge's frozen September 23–25, 2026 paper sample recorded 1,410 waits among 1,714 persisted reviews, but it does not establish a desirable trading frequency or whether waiting made money. Use this guide to identify the fault, recover safely and avoid duplicate trades.
Watch AI paper trading · Inspect 1,714 decisions
How to diagnose an AI bot that has stopped trading
- Check the recorded state before changing a strategy: wait, provider unavailable, hard-control rejection and unfilled order need different remedies.
- Follow a single decision ID from scheduled run to fresh candle, model response, validation, venue order and fill; a healthy chart does not prove this chain completed.
- Across 1,714 recorded reviews, the model chose wait 1,410 times (82.3%); this is a short paper sample, not a target trading frequency or proof the model should have traded.
- An accepted long or short proposal is not a fill. The same cutoff contains 83 accepted entries, 70 created pending orders and 38 paper trades opened; those figures are not a conversion funnel because a proposal can manage multiple positions or follow different execution paths.
- Do not loosen risk limits merely to raise trade count. Diagnose stale data, provider errors and invalid order parameters first.
Where can an AI crypto trading bot stop between market data and a fill?
Find the last completed stage of one scheduled review: scheduler, fresh data, calculated features, model response, parser, risk gate, order acknowledgment and fill. A moving chart or running process does not prove the later stages completed.
Start with the last scheduled slot, not a vague 'no trades today' complaint. If no run was due, inspect schedule and paused state. If a run occurred but the latest candle was late, do not ask the model to guess with stale inputs. If the model returned wait, check the full market and account snapshot it saw; if the response failed parsing or timed out, record unavailable rather than inventing a wait. Only an accepted order followed by a fill belongs in the trade ledger.
Create a trace record with decision ID, due time, actual run time, closed-candle cutoff, response/error ID, validator result, client/venue order ID and filled quantity. Expected success is a continuous trace ending in a justified wait, explicit unavailable/rejection, or reconciled order state. A missing link identifies the investigation point; it is not a new trade signal.
| Last observed stage | What it means | Next safe check |
|---|---|---|
| No scheduled review | Bot may be paused or the clock/job failed | Schedule, timezone, queue and heartbeat |
| Data unavailable or stale | No valid current decision input | Closed-candle time, quote age and missing fields |
| Model wait | A valid choice not to propose an order | Permitted actions, account exposure and market snapshot |
| Provider or parser unavailable | No trustworthy model decision | Request ID, response format, retries and provider status |
| Risk or venue rejection | A proposal failed a hard rule or exchange requirement | Exact rejection code, size, price, permissions and balance |
| Accepted but unfilled | A live pending order, not a trade | Order type, limit distance, expiry and later venue status |
Verify: Coinbase order status definitions · Binance Spot API security and errors
How do you fix an AI bot that says wait, times out or gets orders rejected?
Fix the class of failure you observed: review evidence for valid waits, recover a bounded provider/parsing failure, correct an invalid parameter, or reconcile an unfilled order. These are different remedies, and no-trade count alone cannot choose between them.
For missing or malformed model replies, use bounded retries, a structured response schema, explicit unavailable status and a safe no-trade fallback. Retrying should be idempotent: the same decision ID must not send two orders after a delayed first response. Track provider errors separately from model opinions and check whether requests are too large or exceed the venue/model time budget.
For rejected orders, inspect the exact venue or local-validator reason. Common classes are insufficient balance, an expired or disabled key, disallowed trade permission, symbol not tradable, size/price increments, minimum notional, maximum position, stop/target geometry and account risk cap. Fix bad parameters or permissions only when appropriate. Never bypass a real risk limit to make the dashboard look busy.
Use a reproducible fault record: input timestamp plus requested action, exact error/validator code, attempted recovery and final order state. Re-check on a paper or restricted test path before restoring entries. Success means fresh validated input and one known order outcome, not simply seeing a new position on the dashboard.
| Visible symptom | Likely class | Do this before changing the strategy |
|---|---|---|
| All decisions missing | Scheduler, queue or authentication | Confirm due slots and service health |
| Many deliberate waits | Policy or valid no-trade choice | Review input completeness and later outcomes |
| Empty/invalid JSON or timeout | Provider transport or response contract | Bounded retry, schema validation, no duplicate order |
| Local risk rejection | Size, stop or portfolio rule | Read exact failed rule; preserve hard limits |
| Exchange rejection | Key, balance, market or exchange filter | Use venue error code and current symbol metadata |
| Accepted limit order never fills | Price and lifecycle, not necessarily AI failure | Inspect open/expired/cancelled status and market distance |
Verify: Binance Spot API permissions and error handling · Coinbase order lifecycle
Why is my AI trading bot online but not placing trades?
Being online is not evidence that an AI bot can currently place orders. In the dated CoinNudge example, 1,714 persisted reviews separate waits, unavailable responses, rejected proposals, accepted entries and management actions; each category answers a different troubleshooting question.
This case study counts persisted reviews, not every planned schedule slot. Its observation period spans roughly September 23–25, 2026 and includes accounts that started at different times. We use it to demonstrate diagnosis, not to compare model talent or estimate long-run entry rates.
The table is an operational denominator, not a profitability or provider-reliability experiment. It excludes unrecorded planned slots and accounts had unequal active periods. Compare the latest trace with the category definitions before applying this two-day distribution to another bot or today's accounts.
| Recorded outcome before 07:00 UTC | Count / 1,714 reviews | What to check next |
|---|---|---|
| Model chose wait | 1,410 · 82.3% | Inspect the supplied market snapshot and the model's allowed actions; do not assume the API failed. |
| Provider/response unavailable | 118 · 6.9% | Check timeout, malformed response, retry result and source freshness. |
| Hard risk/control rejection | 62 · 3.6% | Read the exact failed validation: margin, stop/target, reward/risk or pending-order fields. |
| Entry proposal accepted | 83 · 4.8% | Find the corresponding immediate fill or pending-order status; accepted is not executed. |
| Order/position management accepted | 41 · 2.4% | A reduce, close, cancel or adjustment can be useful without opening a new trade. |
Verify: Frozen classified observations · Counts and coverage
Did the model wait, propose a trade, or leave an order unfilled?
A wait, an unavailable response, a rejected proposal and an accepted pending order are distinct states; only actual filled quantity creates exposure. 'Accepted' does not mean a trade completed.
For 70 pending-order records created before the decision cutoff, the status at the separately timestamped publication extract was 25 filled, 36 expired and 9 cancelled. Those are operator-reported current statuses, not a reconstructable order-transition history or an exchange fill-rate study. The same source had 38 opened paper trades, 36 closed and 79 fill-ledger rows before the cutoff; these tables have different units and must not be divided into a fabricated conversion percentage.
For an order accepted with no fill, query the venue by its known client/venue ID and inspect open, partially filled, cancelled, expired or rejected status. A partial fill requires managing actual filled quantity and remaining order quantity separately. If the venue state is unknown, pause new entries and reconcile rather than assuming nothing happened and submitting again.
| Stage | Evidence needed | Mistake to avoid |
|---|---|---|
| Market input | Last complete candle, quote age, missing higher-timeframe fields | Treating stale context as a bearish model decision |
| Model response | Valid structured action or explicit unavailable/error status | Counting a timeout as a deliberate wait |
| Hard controls | Validation result and limit that failed | Removing a stop or increasing leverage to force a trade |
| Order lifecycle | Accepted, open, filled, expired or cancelled status | Calling an accepted limit order a completed trade |
| Paper ledger | Entry/exit, fees and current mark | Calling simulated fills real account performance |
Verify: Frozen classification protocol
Why do some AI trading models wait more than others?
Different wait counts may reflect account start times, schedules, input versions or provider failures rather than model skill. The nine rows below are the frozen September 23–25 account histories, including retired Grok, not today's active model list or a profitability ranking.
Gemini recorded one accepted entry among 172 reviews, while DeepSeek recorded 21 among 286; that does not establish which is better. Hy4 had 40 unavailable outcomes in 95 reviews, pointing first to provider/response reliability. Read each model's evidence and time period before modifying the strategy.
Management actions are not a column in this shortened table, so wait + unavailable + rejected + accepted-entry need not equal each row's recorded reviews; the remaining accepted actions belong to position/order management. Use the full grouped public JSON/CSV to recount all categories. Compare healthy common opportunities before treating one model's lower entry count as a defect.
| Paper model account | Recorded reviews | Wait | Unavailable | Rejected | Accepted entry |
|---|---|---|---|---|---|
| DeepSeek | 286 | 241 | 6 | 16 | 21 |
| MiMo | 286 | 224 | 34 | 4 | 15 |
| GPT-6 Sol | 203 | 179 | 1 | 5 | 12 |
| GPT-6 Luna | 203 | 184 | 1 | 4 | 10 |
| GLM | 196 | 164 | 3 | 7 | 12 |
| Qwen | 196 | 141 | 30 | 11 | 7 |
| Gemini | 172 | 170 | 1 | 0 | 1 |
| Hy4 | 95 | 32 | 40 | 15 | 5 |
| Retired Grok | 77 | 75 | 2 | 0 | 0 |
What should you check before changing an AI bot's trading rules?
Check due runs, fresh inputs, parseable responses, allowed actions, the validator and venue state—in that order—before changing an AI bot's strategy. A more aggressive prompt cannot repair a missing provider response or bad order parameters.
Only after the pipeline is healthy should you test whether a more permissive decision policy improves user outcomes. Prespecify the change, keep risk limits constant, measure net returns and drawdowns after costs, and compare the same market windows. More trades can simply mean more fees and losses; our separate authored BTC backtest made 819 trades and still lost money after modeled costs.
For a claimed missing signal, preserve the exact snapshot and ask whether the original permitted policy could act on it. If a wording error is reproducible, version a revised prompt on the same inputs and hard limits. The next test must evaluate costs and later outcomes, not just increase entry count; do not change research results or hidden risk settings to manufacture activity.
When is doing nothing the safer result—and when is it a fault?
A valid wait can be appropriate under unclear evidence or exhausted exposure, while stale inputs and invalid replies are faults requiring visible diagnostics. Neither should be judged solely by whether price subsequently moved.
The control layer may reject an otherwise coherent model action if margin, leverage, stop placement or order-trigger constraints fail. The correct response is to fix malformed instructions or data if warranted; do not bypass a real capital limit. A pending order that expires may also be ordinary order behavior rather than a model refusing to trade.
If prices rally after a wait, that one outcome does not establish that entering was permitted or superior under the policy. Record the available input, risk budget and intended action first, then evaluate repeated prospective opportunities. If a stop monitor or order reconciliation fails while exposure is open, escalate that operational risk independently of the model's entry opinion.
When should you restart an AI trading bot or change its prompt?
Restart only after identifying the fault and reconciling orders and positions; change a prompt only for a reproducible interpretation defect after the data/provider path is healthy. A blind restart or retry can duplicate a delayed accepted order.
Change the prompt only when a specific, reproducible interpretation problem remains after data, provider and order-path checks. Version the old and new prompts, run them on the same frozen snapshots without changing risk limits, and compare not just entry frequency but net outcomes, rejected orders and drawdown. If repeated waits are rational under the existing mandate, an aggressive prompt merely manufactures more exposure.
For live money, set a fail-closed path: stale data, malformed output, unknown venue order state or exhausted risk budget stops new entries and alerts a human. Existing positions still need an independently defined exit and reconciliation policy. An AI model's confidence score is not a substitute for these controls.
Distinguish a model-request timeout from an exchange-order timeout. The former may have produced no proposal; the latter can leave a live order despite no local acknowledgment. Keep the same decision/client-order identity, query the venue where an order may exist, and enforce one intended effect across retries. A retry budget is an engineering safeguard, not permission to reuse a now-stale trading snapshot.
| Situation | Safe response | Unsafe shortcut |
|---|---|---|
| Provider timeout after order attempt | Reconcile order ID and position before retry | Blindly place a second order |
| Repeated valid waits | Review policy on identical snapshots and later outcomes | Remove stops to increase activity |
| Venue order unknown | Pause new entries and query exchange state | Assume no fill because dashboard is blank |
| Prompt change proposed | Version and compare under unchanged hard limits | Rewrite until one backtest looks profitable |
Verify: NIST AI risk management framework · Coinbase order status endpoint
How reliable is this two-day AI bot audit?
This two-day paper audit verifies public category arithmetic, not source completeness, live-money execution, long-run reliability or the quality of waits. Private prompts, reasons, detailed fills and transitions are not available in its export.
The nine account histories do not share identical start times; their actions may be serially dependent and exposed to the same BTC market. No confidence interval or performance ranking is appropriate from this short window. A future release should keep the same category contract and add a longer forward period, response-latency distributions and versioned changes rather than silently replacing the snapshot.
To reproduce the bounded result, keep observations.csv, grouped CSV, research.json and reproduce.py from the same edition, verify the manifest and run the independent counter. Expected output matches 1,714 rows and five category/per-account totals. That success does not validate the private 70-order or 38-trade counts; report those as operator aggregates, not externally reconciled outcomes.
| Audit item | Publicly checkable? | Boundary |
|---|---|---|
| Decision category totals | Yes | 1,714 coarse row-level observations and grouped CSV |
| Original prompts or private reasons | No | Withheld to avoid exposing private operational inputs |
| Trade/order source completeness | No | Operator-reported table counts only |
| Long-run strategy edge | No | Two-day window, paper execution and no matched control |
Take the next step with this evidence.
Choose ongoing Telegram monitoring or inspect structured data in your own research workflow.
Receive qualifying events in Telegram.
Use the ready-made alert checklist, message explanations and daily briefing. Check the supported categories and coins before subscribing; every Research page is not a separate alert category.
Check the alert list · View alert plans
Inspect the data before choosing a pack.
Prepared research packs supply scoped features, separate outcomes where available and quality flags. Buy a fixed edition once and download directly; API use is optional.
Check data pack samples · Explore the full data catalog · Compare data plans
Each purchased pack includes its specified fields and published date range. This page's full dataset is not automatically included. Other data families require coverage, date, field and source-use confirmation before purchase. Telegram Pro is a separate 30-day service; historical packs are one-time purchases.
Frequently asked questions
Why does my AI trading bot say wait all day?
Wait can be an intentional model output. In this short CoinNudge paper sample, 1,410/1,714 recorded reviews were waits. First check the input, response and risk state; frequency alone does not tell you whether those waits were good decisions.
Is an accepted AI trade already filled?
No. An accepted entry proposal can create a pending order or immediate paper fill. Inspect order status and fill ledger separately; this study does not calculate a fill rate from unlike units.
Why does my AI bot show a trade signal but no exchange order?
A model proposal can fail local risk checks, exchange filters, API-key permissions, balance checks or order submission. Trace the decision ID to the exact rejection code instead of assuming the model did not trade.
What if the bot's order is accepted but not filled?
Check the venue's open, partial, expired and cancelled statuses, the limit price distance and order expiry. Accepted is not equivalent to filled; reconcile the exchange order ID before retrying.
Can I restart an AI bot safely after a timeout?
First query open orders and positions so a delayed first request does not turn into a duplicate trade. Preserve a unique decision or client-order ID, then use a bounded idempotent retry or fail-closed alert.
Should I make the prompt more aggressive so the AI trades more?
Not before ruling out stale data, provider errors, invalid output and hard-control rejection. More proposals do not imply better net performance.
Are these real-money trades?
No. CoinNudge's displayed model accounts are forward paper simulations. The page reports coarse decision categories, not exchange execution or guaranteed returns.
Can I reproduce the numbers?
Yes, the 1,714 coarse observation rows, daily grouped CSV, summary JSON, protocol and independent arithmetic checker are public. The private source database is not, so source completeness and the separate order/trade totals cannot be externally proven from this export.
What if my AI bot order is partially filled?
Reconcile filled quantity and the still-live remainder by venue/client-order ID. Manage actual exposure separately; do not count a partially filled order as either no position or a fully completed trade.
Does a rising chart prove the AI decision pipeline is working?
No. Chart data, scheduled decisions, provider responses, risk validation and fills are distinct paths. Trace one due decision to its final status before changing the trading policy.
Can I use the two-day wait rate as the right trading frequency?
No. The 82.3% describes 1,410 waits among 1,714 persisted September reviews with unequal account lifetimes. It is not an optimal rate or evidence that those waits were profitable.
Sources and verification
- CoinNudge classified decision observationsCoarse public rows only; no prompts or private reasons.
- CoinNudge fixed audit protocolCategory order, cutoff, units and verification limits.
- CoinNudge independent arithmetic checkerRebuilds public aggregates; cannot inspect private source completeness.
- Binance Spot API documentationOfficial API permissions and error handling.
- Coinbase Exchange order statusOfficial order lifecycle fields, including pending and done reasons.
- NIST AI risk management frameworkOfficial framework for dependable monitoring and risk controls.
See the live paper accounts and their actual visible positions before concluding a model is broken.
For your own strategy, test fixed rules and costs separately from model calls.
Watch AI Live Trade