Base config
Base config is the shared risk and management layer that sits under each model and keeps model-specific logic from drifting into risk chaos.
How the Models menu organizes separate entry modules, enables or disables them, and keeps each one on dedicated config.
Section video
The Models menu is where the actual entry engines live. A single plan can contain one model or many, each with its own type, timeframe, configuration name, and shared Base config connection. This is what turns Lazy Trader into a scenario framework rather than a single-pattern advisor.
Operationally, each row in the model list is a unit with its own visibility state, on/off state, config, and removal control. That makes it possible to compare models inside one plan, keep weak ones disabled while preserving the broader scenario, and iterate without rebuilding the whole structure from scratch.
There is no meaningful hard limit on how many models can live inside one plan. You can keep one, two, or many variations as long as each one has a clear role and a defensible place inside the broader risk layer.
The Models menu helps you manage:
What one model row means
Workflow value
Once a plan contains several models, the tester and journal become much more informative. You can observe not only the plan result, but which model family actually contributed to it.
That is a practical advantage over informal discretionary execution, where several ideas often blend together and become hard to evaluate separately.
Use this page when the main question is not “which button do I press”, but “what role does Lazy Trader play in the workflow at all”.
PLAN is the root canvas: it is where risk, entry/stop/take, and the links to every other menu become one executable scenario.
END AT defines when the plan stops looking for new positions, which is different from instantly flattening every already-open trade.
TIME is where session logic lives: windows, overnights, weekday permissions, daily close, Friday close, and broker-specific timing constraints.
This section explains the combined logic of Direction plus Start After, which is where many users actually shape the market bias of the plan.
Direction defines whether the plan is fixed long-only, fixed short-only, or dynamically biased through box, MA, or swing logic.
Start After does not pick the side of the trade; it defines what must happen before the plan is allowed to begin evaluating entries at all.
Status canvas merges Direction, Start After, End At, Time, and Models into one live state map, so you can see what is aligned, what is still pending, and why the plan is running or waiting.
Position Manager gives each open trade its own chart-level button and lets you adjust takes, breakeven, stop-loss, and level sizing without leaving the Lazy Trader workflow.
Base config is the shared risk and management layer that sits under each model and keeps model-specific logic from drifting into risk chaos.
Box-Fractal uses a confirmed fractal range as the structural base for entry and stop placement rather than entering at the first raw extremum.
Larry-Williams works with range extremes and supports both direct breakout continuation and return-entry logic after a raid back into the range.
Classic Structure is the shared logic layer for three related pages: trend continuation, primary liquidity sweep, and reversal structure.
Classic Trend participates on a pullback inside the active structure without requiring the structure direction itself to flip.
This variation opens on the first important structural violation and reads it as a sweep rather than as a full structural reversal.
Classic Reversal becomes relevant only when structure itself turns; it is not just a pullback model with a different stop.
The MA model does more than “touch the fast average”: it also validates the nearest eligible fractal to the left before opening.
BPR is the imbalance-compression model: it works with the overlap between opposite inefficiencies and lets you choose how deep into that balance zone entry should happen.
Optimization is where the guide stops being descriptive and becomes operational: save several plan configs, iterate them in the tester, and read the journal by model contribution.