cuteoptionstrats: A Public Research Note on a Curated Intraday Options Model

Repository examined: cutemarkets/cute-intraday-option-strats
Primary source document: README.md
Related engine: cutemarkets/cutebacktests

Abstract

Most public trading repositories publish either toy signals or opaque backtests. The cuteoptionstrats repository takes a different approach. It does not claim to be a full research platform, and it does not pretend that one public strategy is the whole portfolio. Instead, it exposes one curated intraday options strategy, c36_quality, as a thin public wrapper around the larger cutebacktests research engine. That design choice is scientifically interesting because it reveals not only the strategy family, but also the causal assumptions, option-quality filters, and evaluation framework used to judge whether a model deserves attention.

The central model in the repository is a quote-aware 0-2DTE VWAP mean-reversion strategy on liquid U.S. index ETFs, with a target expiry of 1DTE and a default universe of SPY and QQQ. The package makes a narrow promise: it packages one public alias, preserves the model metadata, exposes a small CLI and Python API, and maps local environment variables into the underlying runtime. The README is unusually explicit about the signal lineage, entry conditions, stop and target construction, exit hierarchy, option microstructure constraints, and the metrics used to evaluate the strategy in the wider research stack. That transparency is more valuable than a generic “AI trading” claim because it lets readers inspect what is actually being standardized.

This post summarizes what the public repository tells us, what the strategy is really doing, where the public artifact ends and the research engine begins, and why the published results are more interesting for their methodological honesty than for headline performance alone.

Research Question

What exactly is being published in cuteoptionstrats, and what can a technically serious reader infer from it about intraday option strategy design, packaging, and evaluation?

A second question matters just as much. If the public repository only packages one model, does it still reveal enough to be scientifically useful? In this case, the answer is yes. The package is small, but the public README and code surface reveal five things clearly:

1. the strategy family and profile lineage
2. the exact signal and exit logic at a meaningful level of detail
3. the option-side quality assumptions
4. the metrics used to judge robustness in the larger stack
5. the distinction between a public wrapper and the underlying research engine

That last point is important. A large share of retail-facing quant content confuses packaging with research. This repository does not. It says directly that cutebacktests remains the source of truth for the generic engine, profile definitions, option selection, quote handling, and persistence, while cuteoptionstrats acts as an opinionated public entrypoint.

The Public Artifact: What The Repository Actually Contains

As inspected on April 21, 2026, the repository is intentionally compact. The public package consists of:

• a README.md
• a pyproject.toml
• a single source package under src/cuteoptionstrats
• one public test file under tests/test_public_surface.py

The source package itself is only a small set of files:

• models.py
• runtime.py
• cli.py

That structure matters because it tells us this is not a “public from scratch” backtester. It is a packaging layer over a deeper research system. The dependency list in pyproject.toml confirms the design: the only runtime dependency is cutebacktests>=0.2.0. In other words, the public package deliberately exports one stable research lane rather than duplicating the entire internal engine.

Scientifically, this is a strong choice. It reduces the surface area for public drift. If the public package reimplemented the strategy logic separately, it would create two risks: divergence between the “real” research profile and the public version, and silent differences in fill logic or data handling. By pinning the public package to the same engine, the authors reduce those risks. The tradeoff is that readers must understand the public repository as a control surface, not the full machinery.

What Model Is Actually Being Published?

The repository exposes one default model:

• default model id: c36_quality
• backing profile: c36_vwap_mr_option_native_quality_v1
• signal family: VWAP residual z-score mean reversion
• instrument expression: single-leg options
• DTE window: 0-2DTE
• target expiry: 1DTE
• default universe: SPY, QQQ

The lineage described in the README is especially important:

1. c4_mr_vwap_zscore_v2
2. c4_mr_vwap_zscore_v2_fast
3. c18_vwap_mr_balance_v1
4. c18_vwap_mr_quality_v1
5. c36_vwap_mr_option_native_quality_v1

This is not cosmetic naming. It implies that the public strategy is the result of iterative refinement along two dimensions. First, the signal family was shaped around VWAP residual mean reversion. Second, the execution layer evolved from a more generic underlying-driven setup into an option-native implementation with explicit quote and contract quality assumptions. A reader should not think of c36_quality as a single inspired idea. It is a descendant of a branch-and-filter research process.

The Core Signal: VWAP Residual Mean Reversion

At the signal level, c36_quality is conceptually simple and structurally disciplined. The strategy computes an intraday VWAP, defines residuals as close - VWAP, estimates a rolling standard deviation of those residuals over a 20-bar window, and converts that deviation into a z-score. The strategy then looks for excursion and reclaim behavior rather than raw breakout continuation.

The active timing parameters are not arbitrary:

• opening range context uses the first 5 bars
• signal evaluation begins at 09:35
• new entries stop at 12:00
• hard exit is at 15:55
• maximum hold is 25 minutes
• opposite-candle exit can trigger after 3 minutes

This makes the strategy a morning-to-midday reversion system rather than an all-day mean-reversion engine. That distinction is important. Intraday VWAP reversion strategies degrade quickly if they are allowed to chase late-session noise, especially in options, where spread conditions and gamma exposure can worsen as the day progresses.

The public README also makes clear that the strategy is not a blind z-score trigger. Several filters are active before a trade is accepted:

• relative opening volume must be at least 1.05
• residual volatility must remain within a bounded range
• VWAP slope over the recent lookback must not be too steep
• the signal bar must close as a reversal candle in the trade direction
• the setup must still support a valid stop and next-bar entry

That filter stack reveals a practical insight. The strategy is not trying to fade every excursion from VWAP. It is trying to fade excursions in sessions that are active enough to matter, calm enough to avoid chaos, and not trending so hard that “mean reversion” is really just stepping in front of directional flow.

Why Next-Bar Entry Matters

One of the strongest features of the public README is that it calls out the causal assumption explicitly: signals are detected on one bar and entered on the next bar open. That sounds modest, but it is a major difference from many retail backtests, which often let the model detect and fill on the same bar in a way that is not realistically executable.

For short-horizon intraday options strategies, that distinction is even more important than it would be in equities. The option leg inherits both underlying timing error and option microstructure error. If the strategy were allowed to “teleport” into the signal bar, its performance would be structurally overstated. By documenting next-bar entry, the repository makes a strong methodological statement: the signal bar is for detection, not for fantasy execution.

Stop, Target, And Exit Design

The stop logic combines three pieces of information:

• the signal bar extremum
• the previous bar extremum
• a VWAP residual z-score envelope

That combination is then widened by a buffer tied to opening-range width. The target is expressed in VWAP residual space, with additional normalization when the raw z-score target would otherwise be economically trivial or sit on the wrong side of entry.

This is a good example of strategy engineering rather than indicator worship. The repository is not saying “buy when z-score crosses X and sell when z-score crosses Y.” It is saying that entry and exit need to respect market structure, local volatility, and the economics of the trade. The target normalization rule is particularly telling. It acknowledges that a mathematically valid target can still be too small to matter after costs and slippage.

The exit hierarchy is also explicit:

1. stop loss
2. z-score target
3. opposite-color candle after minimum hold
4. max hold time
5. time exit at or after 15:55
6. session-close fallback

For a public research artifact, this is a high-quality disclosure. Exit logic often hides a large share of the actual edge or overfitting in intraday systems. Here, the exit stack is clear enough for a reader to understand the behavioral profile: fast reversion capture if available, controlled damage if wrong, and a strict intraday time budget.

Option Expression: Why This Is Not “Just An Equity Signal”

The repository states that c36_quality is the option-native version of the c18 signal family. That phrase deserves attention. The signal may originate on the underlying, but the monetization happens through the generic options runner in cutebacktests. That means the real trade is not complete until contract selection and option execution assumptions are applied.

The public option-side assumptions are:

• single-leg options only
• target expiry around 1DTE
• allowed expiry window 0DTE to 2DTE
• quote-aware execution
• option microstructure filter enabled
• minimum option entry volume 25
• minimum option premium 0.60
• maximum option entry-bar range 35%
• minimum quote coverage 35%
• minimum chain coverage 35%

These filters are not ornamental. They are the difference between a tradable intraday options model and a chart-driven paper strategy that assumes infinite liquidity. Very short-dated options can look attractive on the underlying chart while being practically unusable because of sparse quotes, unstable spreads, tiny premiums, or incomplete chain data. By requiring quote coverage and chain coverage floors, the package signals that data sufficiency is part of the strategy specification, not a separate operational cleanup step.

The Evaluation Framework Is More Important Than The Headline PnL

The README is unusually strong in its discussion of evaluation metrics. Instead of reducing the model to “win rate” or “return,” it surfaces a broader research vocabulary:

• Sharpe_yearly
• Sortino_yearly
• DSR
• PBO
• ROIC_peak
• CAGR_ROIC_peak
• trades per week

Two aspects stand out.

First, the repository emphasizes capital efficiency through ROIC_peak, which it defines as out-of-sample PnL divided by peak deployed capital. That is a more informative metric than raw PnL when comparing intraday option strategies with different capital footprints.

Second, it explicitly frames DSR and PBO as tools for penalizing multiple testing and overfitting. That is rare in public trading content. The broader message is methodological: the stack does not want to rank strategies by raw Sharpe or raw return alone. It wants to know whether the apparent edge survives reasonable skepticism about data mining.

That choice aligns with the rest of the repository. The package is not presenting c36_quality as a perfect model. It is presenting it as a model that survived enough of the internal process to deserve a public wrapper, even though it is not the strongest internal baseline.

The Most Important Result Is Actually A Negative Result

The public README publishes three strategy-level evidence points:

The interesting point is not that c36_quality made money in one artifact set. The interesting point is that the repository says plainly that it is not the best model, and then explains why. The quality variant appears to retain signal strength but fails a trade-density gate. The opportunity variant increases activity but loses quality. That is a classic model-development tradeoff, and it is exactly the kind of negative result that many public repositories hide.

This is why the repository is useful even though it only packages one model. It shows the reader a live tension between edge quality and trade frequency. In portfolio construction, a strategy can fail not because it is false, but because it is too sparse to fill the intended portfolio role.

Published Figure: Capital Efficiency And Drawdown

The repository now also includes a visual summary of the public c36_quality branch:

This figure is useful because it emphasizes the metric vocabulary described in the README. The strategy is not being framed only in terms of raw return. It is being framed in terms of capital efficiency through ROIC_peak and the path-dependent pain visible in drawdown. That is the right pairing for an intraday options model. A strategy can post positive aggregate PnL and still be operationally unattractive if the capital footprint is inefficient or the drawdown path is too unstable for the intended portfolio sleeve.

What The Public Tests Tell Us

The public test file is small, but it is informative. It does not test “alpha.” It tests stability of the public contract:

• default model metadata remains stable
• the default profile resolves to the expected c36 alias
• default config generation applies profile values and user overrides correctly
• repo-scoped environment aliases map cleanly onto the underlying runtime settings

That testing choice is rational. Since the package is a wrapper, its public promise is not “we prove strategy profitability in unit tests.” Its public promise is “the selected model alias, configuration plumbing, and runtime mapping behave consistently.” This is another sign that the repository understands what it is and what it is not.

Reproducibility Surface

The repository offers both a CLI and a Python API. That is useful because it supports two different public workflows: a lightweight evaluation path and a more programmable research path.

CLI example

python -m cuteoptionstrats.cli show-model

python -m cuteoptionstrats.cli run-backtest \
  --ticker SPY \
  --start 2025-01-01 \
  --end 2025-01-31 \
  --return-trade-log

Python example

from datetime import datetime

from cuteoptionstrats import build_default_config, build_default_model, load_settings
from cuteoptionstrats.runtime import build_backtester
from cutebacktests.storage import DataStore

settings = load_settings(".env")
model = build_default_model()
store = DataStore(settings.db_path)

try:
    backtester = build_backtester(settings=settings, store=store)
    result = backtester.run(
        build_default_config(
            start=datetime(2025, 1, 1),
            end=datetime(2025, 1, 31),
            ticker="SPY",
            return_trade_log=True,
        )
    )
    print(model.model_id, result.get("trades"))
finally:
    store.close()

The environment model is also worth noting. The package defines repo-scoped path aliases:

• CUTEOPTIONSTRATS_DATA_DIR
• CUTEOPTIONSTRATS_DB_PATH

These are then mapped into the underlying cutebacktests runtime configuration. That is a practical public-interface choice. It lets users work inside the public package namespace without needing to think first about the deeper engine namespace.

Scientific Interpretation

From a scientific point of view, the repository supports four conclusions.

First, the authors are publishing a strategy wrapper, not a toy backtester. That is more honest and more useful. It avoids reimplementation drift and makes the public artifact easier to reason about.

Second, c36_quality is a real research branch rather than a marketing label. The README provides enough detail on lineage, active parameters, signal logic, stop/target design, option constraints, and evaluation metrics to make the strategy intelligible.

Third, the repository treats option microstructure as part of the model, not as a post-hoc excuse. Quote coverage, chain coverage, option premium floors, and entry-bar range limits are central design choices.

Fourth, the public result that matters most is not “this strategy made money.” It is “this strategy survived enough methodological filtering to be published, but it still failed one portfolio gate because it was too sparse.” That is the kind of statement that builds credibility.

Limitations

The repository is useful, but it has clear limits.

• It does not contain the full research engine.
• It does not expose every internal model, only one curated branch.
• It depends on cutebacktests, which means some implementation detail remains outside the public repo.
• The published results are summary evidence, not a full public artifact pack with every fold and every equity curve.
• The default universe is narrow, which is reasonable for this strategy family but limits generalization.

These are not hidden weaknesses. They are explicit boundaries. In practice, that makes the repository more trustworthy than a broader but less disciplined public release would be.

Conclusion

cuteoptionstrats is a small repository, but it is not a trivial one. Its value lies in the combination of narrow scope and high disclosure. It packages one intraday options model, documents the signal family precisely, makes causal entry and option-quality assumptions explicit, and frames performance inside a research vocabulary that includes overfitting penalties and capital-efficiency measures.

For public readers, the most useful lesson is methodological. A credible intraday options repository does not need to publish every internal model. It does need to be clear about what is being wrapped, where the real engine lives, how trades are detected and executed, what option constraints are active, and why a model can still be interesting even if it is not the strongest portfolio anchor. On that standard, cuteoptionstrats is a strong public artifact.

References

1. cutemarkets/cute-intraday-option-strats repository
2. Repository README
3. Public package metadata in pyproject.toml
4. models.py
5. runtime.py
6. cli.py
7. tests/test_public_surface.py
8. cutemarkets/cutebacktests repository