the algo optimizer takes the manual work out of finding good algo settings. instead of running the algo analyzer over and over with different inputs, you give the optimizer the ranges you want to test — and it sweeps every combination, ranks the top 20, and shows you which versions of your strategy actually held up.

this article walks through what the optimizer does, every setting in the configuration sidebar, how holdout validation protects you from overfit results, and how to read the results panel — including the strategy health card that flags overfit setups before you trade them.

who gets access: the algo optimizer is included with the all access plan only. essential members don't have optimizer access — upgrade from manage account → membership.

a 5-minute walkthrough of the algo optimizer — the configuration sidebar, running a sweep with hundreds of thousands of combinations, reading the ranked results, and pulling the winning settings into tradingview.

prefer to read? everything in the video is covered below — and a few extras (overfit guards, holdout validation, the strategy health card) the video doesn't go deep on.

the optimizer runs your algo across every combination of the settings you choose — up to 10,000,000 combinations in a single run — and ranks the top 20 performers with detailed reports for each one.

think of it as the difference between trying one setup and trying every setup at once. you pick the boundaries (max loss between $200 and $500, profit target between 20% and 60%, ORB duration of 5, 10, 15, or 30 minutes), and the optimizer tests every version inside those boundaries against historical data.

every supported edgeful algo can be optimized — ORB, the strategies in your algo templates, and any algo you've built yourself.

edgeful algos run on per-weekday settings. the optimizer tests every combination on every weekday, then merges the winners into a single result — so each top-20 entry represents the best setting per weekday, not a single configuration applied to the whole week.

the optimizer is for all access members who already have an algo idea — or an existing algo from the algo templates — and want to find the version of it that performs best on historical data.

if you're brand new to algos, start with the algo analyzer to see how a single configuration behaves. once you've got a feel for the inputs that matter, come to the optimizer to test variations at scale.

the workflow is 3 steps:

a counter in the sidebar shows you the estimated combinations as you adjust ranges, so you can see exactly how big your test is before you run it.

the left sidebar is where you set up the run. it's organized top-to-bottom — basic algo info first, then the period and validation mode, then the constraints, then the algo-specific settings you want to sweep.

every label has an ⓘ icon next to it. click it for an inline definition without leaving the page.

the top section is the foundation of the run.

choose how far back the optimizer reaches for historical data:

longer periods give the optimizer more data to find patterns. shorter periods reflect more recent conditions. running the same algo on multiple periods and comparing the winners is the fastest way to spot which settings hold up over time vs. which ones only worked in one regime.

this is the most important toggle in the sidebar — and the one that separates a useful optimization from an overfit one.

standard runs the optimizer on the full period you selected. every trade in that window is used to find the top 20 — there's no walk forward and nothing held back. it's fast, it uses all your data, and it's what you reach for while you're still iterating on ranges and constraints.

holdout does something different. it splits the period into two slices — the optimizer finds the winners on the first slice (the training set), then re-runs those exact winners on the second slice (data they've never seen) and shows you how they held up there.

the easiest way to picture it: imagine a 10-month backtest at an 80% training split. the optimizer trains on the first 8 months, finds its winners, then lets them run untouched on the final 2 months — the same way the strategy would have to perform on dates that hadn't happened yet. that held-back stretch is your real-world dress rehearsal before you risk a dollar.

one note on vocabulary: you'll hear that held-back slice called a few different things — out-of-sample, walk forward, holdout, the test set. in the optimizer and across the help center we mostly say out-of-sample (OOS), but they all point at the same idea: settings tested on data the optimizer never got to see while it was searching.

the deeper holdout configuration and how to read the out-of-sample data comes a few sections down — for now, just know: standard is for fast iteration. holdout is for verifying winners before you trust them.

the candle resolution the algo uses to make decisions:

you can select more than one. if you turn on both 5m and 15m, the optimizer tests every combination on both timeframes — so chart timeframe becomes another dimension in the sweep. the results panel shows which timeframe each top combination used, which makes it easy to see whether the edge is timeframe-specific or whether it holds up across resolutions.

constraints are filters. they tell the optimizer to throw out any combination that doesn't meet your minimum standards — so the top 20 isn't cluttered with setups that have great win rates but only fired twice.

each constraint has a toggle next to it. flip it on, set the value, and the optimizer only returns combinations that pass.

the more constraints you turn on, the fewer combinations make it through. start with 2 or 3 — usually min trades plus one or two others — and add more if the top 20 still looks noisy.

if you turn on constraints that no version of the algo can satisfy, the optimizer doesn't just hand you an empty top 20 — it shows a feasibility panel that explains exactly which constraint blocked the run and by how much. this is what the "unreachable" status means: based on the filters you selected, the optimizer couldn't find any suitable setting combinations, and the panel calls out what's causing it.

the panel tests each constraint you set individually against every combination it ran, then reports a status per filter alongside your threshold (what you asked for) and the best achieved (the best value any single tested strategy actually produced):

worked example. say you set min win rate ≥ 55%, min profit factor ≥ 1.30, max drawdown ≤ $1,000, and min trades ≥ 30. across 2,600 tested strategies the optimizer reports:

the smallest drawdown any single strategy produced was $1.2k, so your $1.0k cap can't be met by anything — max drawdown is the blocker. the fix is to loosen it: use the "best achieved" number as your guide and set the cap just beyond it (e.g. $1.3k), then re-run.

one important nuance — "achievable alone" is not "achievable together." a gray status only means a constraint is reachable on its own, not that it's reachable in combination with the others. you can have four constraints that each pass in isolation but still return zero results combined, because no single strategy satisfies all four at once. that's why the panel's guidance is to loosen the unreachable (red) constraint first — and warns that even after that, the gray "achievable alone" rows may still conflict when combined.

the practical workflow when you hit an unreachable status: loosen the red constraint first (set the threshold just past its "best achieved"), re-run, and if the top 20 is still empty, ease off the gray constraints one at a time — or widen your sweep ranges and backtest period to give the optimizer more strategies to work with — until combinations start coming through.

overfit guards work in the opposite direction. instead of setting a floor, they set a ceiling — they help you catch setups that look too good to be real.

if a backtest is showing a 95% win rate on 30 trades, that's almost always a sign the combination fit the noise of that specific period. capping max win rate at something like 85% filters those out automatically.

overfit guards run before the results land in front of you. holdout validation (next section) runs after. combined, they're two independent checks on the same problem — one structural, one statistical.

holdout validation is the safety net that catches overfit setups before you put real money on them. when you flip the validation toggle to holdout, two things happen.

new to the concepts? understanding holdout, in-sample, and out-of-sample is the plain-english primer — read that first if terms like in-sample, out-of-sample, or training period % aren't clicking yet.

one common misread: a lower training % is not stronger validation. lowering the slider means the optimizer searches on less data and tests on more — the search gets weaker, the verdict gets harsher. the how to read your holdout results section below covers the three misreads we see most often.

a new field appears in the validation section: training period %. it defaults to 80, which means the optimizer is allowed to "see" the first 80% of dates in your backtest period. the remaining 20% is held back as a test set — the optimizer never touches it during the sweep.

once the top 20 winners are found on the training data, the engine re-runs each one on the held-back 20% and shows you how it performed there.

higher training % gives the optimizer more data to find winners but less to validate them on. lower training % does the opposite. 80/20 is a sensible default — it's enough validation data to mean something without starving the search.

once a holdout run finishes, the results table picks up two extra columns:

a combination with a high in-sample win rate but a heavily negative OOS Δ is overfit. one that holds up — small delta, or even positive — is the real candidate.

two filters in the holdout validation sidebar reject combinations whose performance falls off too far from training to out-of-sample. they're a stricter version of the OOS Δ columns — instead of just flagging the drop, they remove the combination from your top 20 entirely.

the OOS Δ columns show you the drop after the fact. these filters stop large-drop combinations from appearing at all. start loose on exploratory runs (e.g., 10pp on win rate, 1.0 on profit factor) so the top 20 isn't empty, then tighten once you've found a setup family worth refining.

click into any result row's report tab and you'll see a much deeper holdout view:

how to read edge decay — a worked example. edge decay takes your average return per trade on the training data and multiplies it by the number of trades the strategy took out-of-sample. that's what the held-back stretch should have produced if the edge held. then it compares that to what actually happened.

say the training data averaged about $626 per trade, and the strategy took 13 trades out-of-sample. the expected OOS P&L is roughly $626 × 13 ≈ $8,100. if the actual OOS result came in around $8,600, the edge didn't decay — it actually improved on data the optimizer never saw, which is exactly what you want to see. flip it around: if that same setup had only produced $4,000 against an $8,100 expectation, that's real decay — and a reason to be skeptical no matter how clean the training numbers looked.

a top combination that earns low overfit risk with all 7 checks passing and a small OOS delta is the one to trust. one that fails 2 or 3 checks or shows steep edge decay is a warning, not a winner.

three questions come up over and over once people start running holdout. here are the answers in one place.

is a lower training % stronger?

no. training % is the slice the optimizer is allowed to see while it's searching for winners. lowering it from 80 to 70 doesn't make the result more rigorous — it just shrinks the search and gives you more out-of-sample data to test against. 80/20 is the sensible default. anything below 60 starves the search and the top 20 starts fitting the small training slice. anything above 90 leaves so little out-of-sample data that the OOS Δ columns become noise. start at 80.

my strategy looks great at 70% but falls apart at 80% — is that a feature or a flaw?

a flaw. if your strategy only validates at one specific training %, it's leaning on a particular slice of recent data — not on a real, persistent edge. a strategy you can trust holds up across multiple training % values. run the same algo at 70, 80, and 90 and look at how the OOS Δs move. if the winners shuffle dramatically between runs, the algo is fitting noise. if the same setups stay near the top with small OOS Δs, that's confluence.

what does a big drop between in-sample and out-of-sample mean?

it means the combination found patterns in the training data that didn't repeat in the test data. concrete read on the OOS Δ columns:

always cross-check the OOS Δ columns against the strategy health card. the card runs 7 independent checks on top of the holdout — if it flags concentration risk or performance decay even when the OOS Δs look small, trust the card. the two systems catch different failure modes.

a worked example: what a strong holdout result looks like

here's an actual top-ranked result from an ORB strategy on ES, 5m chart, 30-minute opening range, NY session (09:30–16:00 ET), backtested 05/14/25 to 01/19/26:

every metric improved on the data the optimizer never saw. that's a strategy worth pushing live. if you'd seen the opposite — win rate dropping 10pp, profit factor cut in half — you'd skip it without hesitation, no matter how good the training numbers looked.

this is where you tell the optimizer which inputs to vary and how far to push them.

every input in this section takes a minimum, a maximum, and a step. the optimizer tests every value from min to max, moving by the step size each time. so a max loss of $200 to $500 with a step of $100 tests $200, $300, $400, and $500 — 4 values.

session time sets the start and end of the trading window the algo is allowed to operate in. defaults to 09:30 start and 16:00 end (NY session), but you can change either dropdown to test a different window — the NY session, the globex/overnight session, the london session, or a narrower slice like only the first 2 hours or only the afternoon.

the next group changes based on which algo you selected. for an ORB strategy, you'll see:

for other algos, this section will show the inputs specific to that strategy — defined either by edgeful's built-in templates or by however you configured your own algo.

filters are condition-based — only take the trade if a market condition is met. for ORB, the filters include:

filters are powerful because they let the optimizer find a setup that only fires under specific conditions — e.g., "this ORB strategy works great, but only on days where the opening range is between 0.3% and 1.2%."

running long-only and short-only separately and comparing winners often reveals that an algo has a strong directional bias on certain tickers.

once the configuration is set, click optimize. the top 20 combinations come back ranked in the optimization results panel.

the panel header shows a breadcrumb of the run config — ticker, algo, chart timeframe(s) selected, and lookback period — so you can always see what you're looking at. on the right are two action buttons:

if you change any sidebar setting after a run finishes, an inputs changed banner appears at the top of the results — listing how many settings were changed, with a re-run link to refresh the results. you'll also see was X badges appear next to each modified input in the sidebar — at a glance, you can see what's different from the run that produced the current results.

each row in the table is one combination, ranked by composite score. the columns:

the #1 ranked combination is not always the one with the highest P&L, the highest win rate, or the best profit factor. the composite score weighs all of those together along with drawdown and consistency — so a setup ranked #1 might post a smaller headline P&L than a setup ranked #3 or #5, but with a tighter drawdown, more trades, or a more stable equity curve. scan the whole top 20 rather than clicking row 1 by default.

each row has a star on the left — click it to favorite a combination for easy reference later.

click any row to load it into the detail view at the bottom of the screen. strategy details is the section heading above three tabs that let you slice the selected result different ways:

the report tab is where most of your time will go. it includes:

scan the strategy health card first. if it says low overfit risk with all 7 checks passing, the combination is worth a deeper look. if it flags concentration risk or performance decay, the wins might be coming from a narrow slice of the period rather than a real, persistent edge.

at the top right of the detail panel, you'll see a simple / advanced toggle (when the report tab is active) and a run this algo button.

the practical workflow once you've found a candidate: scan the strategy health card → confirm OOS Δs are tight → flip to the algo settings tab to review the exact configuration → click run this algo to push it live (or use how to run this in TradingView on the algo settings tab to copy the settings into your chart manually).

once the new settings are on your indicator, there's a specific handoff sequence — recreating your TradingView alert, SIM-testing the webhook, and scaling up to live size carefully. applying algo settings changes — what to do after you optimize and make algo setting changes walks through the full process step by step.

after you push optimizer settings into TradingView, the strategy tester won't show identical numbers. that's expected — and the gap usually has one of three explanations.

1. commissions aren't included in optimizer output. the optimizer reports gross P&L. TradingView's strategy tester can include commissions if you configure them. when you're comparing net P&L between the two, factor commissions in manually — a $5/round-trip commission across 200 trades is $1,000 off the optimizer's headline number, which can look like a large discrepancy if you're not aware of it.

2. contract rollovers are handled differently. TradingView uses continuous contracts that splice price data across expiries. the optimizer's historical data treats rollovers on its own schedule. expect small variance from this even when every other setting is matched — it's structural, not a bug.

3. decimal precision on some instruments. certain futures with 4-decimal pricing (HG and similar) currently round to 2 decimal places in the optimizer. engineering is investigating. if you're trading one of these, expect small distortion in entry/exit prices vs. TradingView until that's resolved.

how to get the results as close as possible: match the ticker symbol (the same specific contract on both sides, not a continuous symbol on one side), the date range, the chart timeframe, the session times, the weekdays-to-use, every algo setting (take profit %, stop loss %, max loss $, ORB duration or whichever sweep variables the optimizer used, filters, direction) — and account for commissions manually when comparing net P&L.

when the variance is too large to ignore: small differences are expected. if net P&L differs by more than ~15–20% after accounting for commissions, the trade count differs materially (e.g., 180 trades on the optimizer vs 150 on TradingView), or the direction of edge flips — recheck every setting in both systems first; that catches most cases. if everything matches and the gap is still significant, reach out through the in-app chat with a screenshot of both result sets and we'll investigate.

next to optimizer at the top of the page is the library tab. it holds two things side by side:

a run a new optimization button at the top right of the library takes you back to the optimizer tab to start a fresh sweep.

a few habits that turn the optimizer from a number generator into a real edge-finding tool:

finding a good algo takes customization, testing, and time. the optimizer compresses the testing part — but the work of refining your idea, validating winners on out-of-sample data, and knowing when to trust the strategy health card is still on you.