EXECUTION#
On the introductory page I closed with a joke: what could possibly go wrong with having a live trading account run by a bot that sells puts on margin, written with AI, on a Chinese headless mini PC at home? This section is the long answer to that joke. Four pages in which I climb down from the level of strategies to the level of cables, logs and orders that go out at 16:01 New York time while I, in my South American time zone, am busy doing something else entirely. It is the most personal section of the site — I describe my setup, not the setup — and also the most perishable: hardware, libraries and APIs age faster than risk premia. The principles don’t, though, and it’s the principles I want to nail down before the details.
Why automate (and why not)#
Let me start with the misconception to dismantle: the bot is not there to make more money. Both strategies are low frequency by construction — ten minutes a day for the TRPS, an evening ritual for the DHCS — and no millisecond of latency saved adds a cent of alpha: the edge (Edge page) is a premium for risk held, not for speed. The bot serves three different purposes.
First: encoding discipline. I wrote it on the TRPS page: the long-run killer of the TRPS is not the crash, it’s the temptation to “optimize” — the slightly closer strike after a good month, the extra contract after a quiet quarter. A bot executes the written rule, identically, on the evening of day 1 and on the evening of day 1,000, including the evening after a stop got eaten, when the human version of me would want to “make it back”. Automation is ergodicity (Ergodicity page) applied to psychology: it removes the operator from the chain of repetitive decisions, which is exactly the point where the operator breaks strategies.
Second: covering awkward hours. The TRPS’s critical window — the 15 minutes after the NYSE close, mounting the night guard right after the fill, the changing of the guard half an hour after the open — falls when it falls, US holidays and my own commitments included. A process that must happen 252 times a year at a fixed time is the operational definition of “a machine’s job”.
Third: producing a record. Every order, every fill, every broker rejection ends up in a journal on a database: it’s the raw material for the PCR (Risk measures page), for the weekly risk dashboard and, not least, for the tax return. The manual version of this record is called “I’ll do it on the weekend” and lasts three weeks.
And the why not, just as honest: automation converts psychological risk into operational risk. The bot doesn’t panic, but it can crash at 16:02 with half the orders sent; it doesn’t chase losses, but it executes a bug to the letter. The Risk management page said it already: the bot is a junior employee with access to the account — supervision, hard limits, kill switch. In my system the leash takes the form of a two-way messaging channel (Setup page): every action taken by the trading bots reaches my phone in real time, and from the phone a single command can stop them instantly — the junior employee works with the boss on the line, always. This section is, in large part, the manual for supervising that employee.
Then there is a risk that automation creates out of thin air and that needs naming right away: security. An always-on machine with an authenticated session into my account is a target, and the attack surface must be shrunk with the same seriousness with which you size leverage. The rules I follow: no ports open to the internet on the home router; the broker’s API bound to accept connections only from the local machine; credentials never in the code but in an encrypted store, and in any case an API user that cannot withdraw funds — the separation between “can trade” and “can touch the money” is the computing version of the distinction between loss and ruin from the Ergodicity page; automatic security updates and nothing else automatic; and the most banal and most neglected discipline of all, two-factor authentication on everything that matters. An attacker who gets into the mini PC can at worst make me sell puts badly for one evening; they must not be able to do more.
The four design principles#
Everything in the design that follows flows from four principles. I state them here because on the The TRPS bot and The DHCS bot pages you will find them applied everywhere, and because they hold whatever your stack is.
Principle 1: the broker’s servers are part of the system. The single most important insight of the whole section: stop-limit orders (TRPS page) do not live on the mini PC — once transmitted, they reside on IBKR’s servers and get executed even if my house is dark, the router fried and the bot dead. The correct design exploits this fact to the fullest: the bot places the protections first, and from that moment its survival becomes desirable but not necessary. The critical part of the system runs in a datacenter with redundancy I could never afford; the mini PC is just the clerk who delivers the envelopes.
Principle 2: fail-static, not fail-operational. I don’t demand that the system keep operating through a failure (that costs as much as hedge-fund infrastructure): I demand that a failure leave it in a safe state with no further action required. And this is where the choice of strategies pays off twice: a TRPS with a dead bot is a set of 1DTE puts with their night guard already on the broker’s and exchange’s servers, which at worst expire worthless the next day; a DHCS that skips a rebalance accumulates a bit of tracking error, not a catastrophe (The DHCS bot page). Neither requires the bot to be alive in order to be safe. Compare with an intraday strategy that must close its positions by the evening: there a process crash is an emergency; here it’s a nuisance.
Principle 3: the human is the backup, and must be equipped. When fail-static isn’t enough — the overnight gap with open positions, the partially executed order, the margin screaming — the last line is me with the IBKR mobile app, which talks directly to the broker’s servers, bypassing my entire home infrastructure. But to intervene you have to know, and this is where the notification channel comes in: every fill, every rejection, every state change reaches my phone the moment it happens, and the same channel accepts commands in the other direction — query the state, or shut the bot down. The runbook from the Risk management page becomes literal here: a laminated page with the cases (bot silent for N minutes, orphan position, stop executed at an absurd price) and the actions, written in calm seas.
Principle 4: the truth lives at the broker, not in the database. At every startup and at fixed times, the bot reconciles: it queries IBKR for actual positions and orders and compares them against its own journal. Any discrepancy freezes trading and alerts me — never, under any circumstances, does the bot “fix” on its own a difference it doesn’t understand. The journal is the memory; the broker is the reality; when they diverge, the human decides.
The hierarchy of responsibilities: the protections live at the broker, the routine on the mini PC, and the human — equipped — can override everything by talking directly to IBKR’s servers. This single principle eliminates the most insidious class of incidents in retail automation: the bot convinced it holds positions it doesn’t (or vice versa) that “fixes” things by doubling the damage.
What stays manual#
Not everything gets automated, and the dividing line is conceptual, not technical. You automate what is rule: the TRPS daily routine (fixed-premium strike selection, submission, stops), the DHCS rebalance and roll, the surveillance, the journaling. What stays manual is what is judgment: the tactical leg of long puts at high VIX (TRPS page), discretionary by its very nature; the morning-after decision following a night in which the futures guard has fired — close puts and futures together or keep the hedge until expiry — which the bot flags with a critical notification and never takes on its own (The TRPS bot page); every change of leverage or parameters, which goes through a version-controlled configuration file and never through a 23:40 idea; and every intervention on the exceptions raised by reconciliation. The rule I’ve given myself: the bot may only do less than planned (skip a sale if a safety condition is not met), never more. The asymmetry is deliberate: a missed opportunity costs 15 cents per contract; one initiative too many can cost the account.
The map of the section#
The Setup page describes the setup: the account and permissions on the broker side, the hardware (the embedded mini PC, the UPS, the network with failover), the base software (operating system, IB Gateway and its tamer IBC, the API library, the surveillance services) and a note on market data and the journal’s tax side. The The TRPS bot page is the architecture of the TRPS bot: a state machine living on New York time, with the 9:25 reconciliation, the 10:00 changing of the guard, the 16:00 selling window, the night guard in its two variants — conditional buyback and futures hedge — and its ways of failing gracefully. The The DHCS bot page is the DHCS bot: simpler in rhythm (a single evening appointment), more delicate in the math (where you take the delta from, when you rebalance, how you round the Micros), and structurally more fault-tolerant — the comparison between the two is also a comparison between philosophies of automation, and it closes the discussion opened on the TRPS vs DHCS page.
One last warning, the same as the Strategies page but squared: everything that follows gets tested in paper trading for months, on the simulated account IBKR provides for exactly this purpose, before a single real contract leaves a script. Paper doesn’t test the edge — that is established in the Derivatives and Strategies sections — it tests you and your code: the timeouts, the time zones, the holidays, the Gateway errors at 16:01. It’s the junior employee’s probation period. Let me start with the office I built around him.