AlphaBot: The Trading Bot That Asks for Permission First

A real-time DRL trading system that turns machine signals into pending trades, pushes state through Redis and WebSockets, and lets humans veto the machine before money moves.

8 min read • View on GitHub • More from AbhinavBethi

A wide control room scene with three ticker monitors, a pending approval panel, and an emergency stop switch within reach. It explains the core idea that AlphaBot turns model signals into reviewable actions before execution. — AlphaBot is not just a signal generator. It is a trading loop with a human veto path built into the middle of it.

Key Takeaways

AlphaBot’s real innovation is not prediction accuracy. It is a supervised execution path that keeps machine output reviewable before capital moves.
The repo separates the trading brain from the browser-facing body, which makes live state easier to observe, interrupt, and trust.
Redis is doing more than caching. It is the short-term memory that keeps the dashboard live without turning PostgreSQL into a polling bottleneck.
The approval window turns trading into a state machine, which is a stronger product idea than a fully automated bot with no override path.

AlphaBot is interesting because it refuses the usual automation fantasy. The model can recommend a trade, but the system does not pretend that makes the decision safe. It stores the trade as pending, exposes the state to the dashboard, and leaves a human with a last look before execution.

That is the story worth telling. The repo is not trying to win on raw signal generation alone. It is trying to make machine-driven trading observable, interruptible, and hard to abuse.

Why AlphaBot’s Real Idea Is Not Automation, but Consent

The most distinctive part of AlphaBot is the approval window. A signal is not treated as an order. It becomes a pending action that can be approved, rejected, or allowed to expire after a fixed window.

That detail changes the product category. Most trading systems optimize for speed or autonomy. AlphaBot optimizes for trust, and it does that by making the machine wait.

The approval window is not a feature on the side. It is the core state machine that makes AlphaBot feel like a supervised system rather than a blind executor.

The Three-Part Loop Behind the Dashboard

AlphaBot reads like a system built around three jobs. The training engine produces signals. The backend persists and distributes state. The dashboard displays what is happening now, not what happened after a database query finished.

That separation matters. The trading brain can keep running while the API serves the operator view. The browser does not need to know how the model works to show that the model has produced a pending trade.

A close-up flow diagram with model, cache, database, and dashboard connected as a loop. It explains how AlphaBot separates training, durable state, and live operator visibility. — The repo’s architecture is less a stack than a loop. Each part exists to keep the others observable.

train.py  -> signal generation
Redis      -> live cache and pub/sub
PostgreSQL -> durable trade state
FastAPI    -> API and WebSockets
frontend/  -> operator dashboard

Why Redis Matters More Than It Looks

Redis is the invisible part of the design that makes the visible part feel alive. It keeps the latest signal, chart points, and status updates close to the surface so the dashboard can stay responsive without hammering the database.

In other words, Redis is the bot’s short-term memory. PostgreSQL is the record. The dashboard needs both, but it depends on Redis for the rhythm of the live interface.

Layer	What it is good at	What breaks if you rely on it alone
Redis	Fast state, pub/sub, rolling cache	You lose durable history if it is the only store
PostgreSQL	Audit trail, persistence, recovery	Polling it directly adds latency and UI lag
WebSocket dashboard	Live operator view	It is only as useful as the state feed behind it

Inside the Trading Brain

The model side is built to chase temporal structure from more than one angle. The repo describes a GRU, an ALSTM, and a Transformer feeding a DDPG actor-critic agent. That combination is less about novelty for its own sake and more about covering different kinds of sequence behavior.

The editorial question here is trade-offs. GRUs are compact and efficient. Attention layers can surface longer-range dependencies. DDPG gives the system a continuous action framework. Together they suggest a designer trying to keep the model expressive without collapsing the objective into raw profit chasing.

Model piece	Likely role	Why it matters here
GRU	Compact sequence memory	Handles shorter temporal patterns with less overhead
ALSTM	Attention over time	Helps the agent focus on relevant price history
Transformer	Long-range dependency modeling	Gives the ensemble another way to see context
DDPG	Actor-critic policy learning	Turns the features into continuous trading actions

The more interesting detail is the reward shaping. By leaning on risk-adjusted objectives like Sharpe ratio, the system is not only trying to make money. It is trying to make money with a sense of variance.

The Approval Window Is the Product

This is where AlphaBot becomes more than an ML demo. A PENDING, APPROVED, REJECTED, and EXPIRED flow turns the system into a workflow that can be supervised, audited, and interrupted.

That matters because trading failures are often failures of control, not signal quality. AlphaBot answers that with a state machine. The model can be right and still be overruled.

Generating illustration...

The approval window is where machine output becomes a human decision path. That is the repo’s clearest product idea.

What AlphaBot Is Choosing Not to Be

AlphaBot is not a pure signal engine, and it is not just a dashboard for discretionary trading. It sits in the middle. The machine proposes, the human can intervene, and execution happens only when the system and operator have both done their part.

Workflow	Strength	Weakness
Fully automated bot	Fast and scalable	Low trust when the model is wrong
Manual dashboard	High human control	Slow and inconsistent
AlphaBot hybrid	Reviewable and interruptible	More moving parts to maintain

That compromise is the point. The repo is not trying to remove the operator from the loop. It is trying to make the loop fast enough to be useful and visible enough to be trusted.

Why This Repo Feels Mature Despite Its Small Footprint

The engineering signals are the part that make AlphaBot feel serious. The repo separates services, uses durable and volatile stores for different jobs, adds authentication and logging, and treats emergency stop behavior as a first-class control path.

That is what a product system looks like. Not a notebook with a chart, but a system that expects failure, records state, and gives the operator a way out.