Changing an AI trading agent's signal threshold can remove many setups without changing how often it has a reason to ask its model. That distinction matters when testing agent settings: count setups, admitted calls and accepted actions separately.
On 7 October 2026, CoinRithm replayed 120 recorded snapshots without calling a model or executing a trade. One RSI variant reduced the setup count from 1,069 to 879, but the signal gate still fired on all 120 snapshots. This is a concrete lesson about configuration, not evidence of a profitable strategy or lower live costs.
For the controls available in the product, start with the Agent Studio configuration guide. Here we explain the experiment and how to read it.
What the 120 snapshots represent
The recording covered five house specifications, with 24 snapshots each at roughly 15-minute intervals. It used a read-only QA paper book with empty positions and orders, not the houses' actual trading histories or customer accounts. The houses saw overlapping market conditions in the same period. The 120 observations are not 120 independent trades.
The signal comparison started with fresh state on every snapshot and disabled periodic prediction-market wakes (PM_PERIODIC) equally for every variant. That isolates the tested signal settings. A separate gate comparison carried synthetic call history forward; it did not simulate positions, execution, daily trading counters or PnL.
Two offline executions reproduced the same result. Both made zero network requests, model calls and production writes. These results contain no outcome labels, profit measurement or statistical evidence of an edge. The published aggregate evidence includes per-house counts and the exact source revision; it contains no customer records or raw market corpus.
Fewer setups can still mean a reason to call on every tick
A setup is an item flagged by the deterministic scanner. Several can exist in one snapshot. The last column counts snapshots where the gate fired under the fresh-state signal comparison; it does not count actual model requests.
| Signal variant | Setups across all snapshots | Gate fires out of 120 |
|---|---|---|
| Original house settings | 1,069 | 120 |
| Minimum strength 0.6 | 906 | 114 |
| Minimum strength 0.8 | 125 | 55 |
| RSI lower/upper thresholds 30/72 | 938 | 120 |
| RSI lower/upper thresholds 25/80 | 879 | 120 |
The RSI variants left fewer setups but enough remaining triggers to fire on every recorded tick. Strength 0.8 was more selective in this sample. More selective does not mean better: there are no later outcomes here showing which removed or retained opportunities were useful. The settings were replayed against the same inputs; these counts are not recommendations.
Call timing is a separate control
Using the original recorded setups, the stateful gate replay produced:
| Gate variant | Hypothetical admissions | Skipped ticks |
|---|---|---|
| Original event gate | 120 | 0 |
| 30-minute repeated-trigger debounce | 90 | 30 |
| Maximum one call per hour | 27 | 93 |
| Always, once per recorded tick | 120 | 0 |
Debounce checks repeated trigger types; it is not a blanket 30-minute sleep. The hourly limit applies separately to each house's replayed call history. The production gate also treats open-position management separately, which this empty-book experiment did not test.
These are tested engine policy variants, not a claim that every option is exposed in Studio. Use the current guide and controls for available settings. “Always” means once per recorded snapshot, not once per minute. Roughly 15-minute sampling cannot establish behavior between observations. There were no billable calls, so this table cannot establish a live cost reduction or provider-capacity improvement.
Passing an action check is not a winning trade
The mechanical prediction-market comparison used each house's own recorded opportunity set. Each baseline was complete on all 120 snapshots:
| Mechanical baseline | Proposed actions | Accepted by validation | Rejected |
|---|---|---|---|
| Market-implied forecast | 120 | 29 | 91 |
| Constant base-rate forecast | 120 | 29 | 91 |
| Deterministic random forecast | 120 | 29 | 91 |
Rejections included an entry below the permitted floor and an ineligible quote. Equal counts do not imply equal forecasts or performance. Quotes were synthesized locally because the read-only recorder refused quote POSTs; spread and slippage were omitted. This was PM-only, with no futures or spot baseline. The always-skip baseline and stub house control produced no actions; the stub was not a house model decision. No missing input was treated as a valid abstention.
How to use the method for your settings
- Fix the inputs, period and original settings before comparing variants.
- Change one setting family at a time. Count setups, gate admissions and action rejections separately.
- Keep timing, state and missing-data rules visible. A fresh-state comparison answers a different question from a running agent with positions.
- Measure later outcomes separately before judging trade quality. Fewer triggers alone establish neither profit nor lower risk.
You can inspect the exact signal scanner, call gate and replay framework. When changing your own paper agent, use Studio and retain the configuration version so later observations have a clear starting point.