jesse 2.3.3__tar.gz → 2.3.4__tar.gz

{jesse-2.3.3/jesse.egg-info → jesse-2.3.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: jesse
-Version: 2.3.3
+Version: 2.3.4
 Summary: A trading framework for cryptocurrencies
 Home-page: https://jesse.trade
 Author: Saleh Mir

{jesse-2.3.3 → jesse-2.3.4}/jesse/candle_pipelines/moving_block_bootstrap.py

@@ -3,7 +3,7 @@ from .base_candles import BaseCandlesPipeline
 
 
 class MovingBlockBootstrapCandlesPipeline(BaseCandlesPipeline):
-    def __init__(self, batch_size: int, **_ignored) -> None:
+    def __init__(self, batch_size: int, seed: int = None, **_ignored) -> None:
         """
         Generate synthetic candles by moving-block bootstrap on multivariate
         tuples of (delta_close, delta_high, delta_low).
@@ -14,6 +14,10 @@ class MovingBlockBootstrapCandlesPipeline(BaseCandlesPipeline):
             Size of the internal regeneration buffer in minutes. The pipeline
             derives a reasonable bootstrap block length from this, so there is
             no separate block-size argument.
+        seed : int, optional
+            Seed for the internal RNG. Leave None for independent random
+            scenarios (the normal case); pass an int for reproducible output
+            (used by tests asserting the fast and full simulators are identical).
         """
         super().__init__(batch_size)
 
@@ -25,7 +29,8 @@ class MovingBlockBootstrapCandlesPipeline(BaseCandlesPipeline):
         self._block_size = derived_block_size
 
         # Independent RNG per pipeline instance to avoid identical scenarios
-        self._rng = np.random.default_rng()
+        # (seedable for reproducible tests).
+        self._rng = np.random.default_rng(seed)
 
     def _bootstrap_blocks(self, arr: np.ndarray, n: int) -> np.ndarray:
         """

{jesse-2.3.3 → jesse-2.3.4}/jesse/config.py

@@ -137,20 +137,28 @@ def set_config(conf: dict) -> None:
         config['env']['logging'] = conf['logging']
         # exchanges
         for key, e in conf['exchanges'].items():
+            # The dashboard sends each exchange entry carrying its own 'name', but the
+            # exchanges map is keyed by exchange name and scripted/MCP callers pass the
+            # entries without a redundant 'name'. Fall back to the dict key so both the
+            # dashboard payload and the natural dict-keyed config (what /config returns)
+            # work. Without this, a missing 'name' raised KeyError deep inside a spawned
+            # backtest/RST worker, which then exited silently (the traceback was lost on
+            # the os._exit() that follows), leaving the MCP/dashboard session stuck.
+            name = e.get('name') or key
             if not jh.is_live() and e['type']:
                 exchange_type = e['type']
             else:
-                exchange_type = get_exchange_type(e['name'])
-            config['env']['exchanges'][e['name']] = {
+                exchange_type = get_exchange_type(name)
+            config['env']['exchanges'][name] = {
                 'fee': float(e['fee']),
                 'type': exchange_type,
                 'balance': float(e['balance'])
             }
-            if config['env']['exchanges'][e['name']]['type'] == 'futures':
+            if config['env']['exchanges'][name]['type'] == 'futures':
                 # 1x, 2x, 10x, 50x, etc. Enter as integers
-                config['env']['exchanges'][e['name']]['futures_leverage'] = int(e.get('futures_leverage', 1))
+                config['env']['exchanges'][name]['futures_leverage'] = int(e.get('futures_leverage', 1))
                 # accepted values are: 'cross' and 'isolated'
-                config['env']['exchanges'][e['name']]['futures_leverage_mode'] = e.get('futures_leverage_mode', 'cross')
+                config['env']['exchanges'][name]['futures_leverage_mode'] = e.get('futures_leverage_mode', 'cross')
 
     # live mode only
     if jh.is_live():

{jesse-2.3.3 → jesse-2.3.4}/jesse/controllers/candles_controller.py

@@ -96,10 +96,29 @@ def get_candle_import_status(request_json: CancelRequestJson, authorization: Opt
         return authenticator.unauthorized_response()
 
     running = bool(is_process_active(request_json.id))
-    return JSONResponse({
+    response = {
         'import_id': request_json.id,
         'status': 'running' if running else 'finished',
-    }, status_code=200)
+    }
+
+    # Attach live progress (percent complete, ETA, date reached so far) when the import
+    # is still running so callers can see real movement instead of a blind "running".
+    # When finished, clean up any lingering progress key.
+    import json
+    from jesse.services.redis import sync_redis
+    from jesse.modes.import_candles_mode import candle_import_progress_key
+    progress_key = candle_import_progress_key(request_json.id)
+    try:
+        if running:
+            raw = sync_redis.get(progress_key)
+            if raw:
+                response['progress'] = json.loads(raw)
+        else:
+            sync_redis.delete(progress_key)
+    except Exception:
+        pass
+
+    return JSONResponse(response, status_code=200)
 
 
 @router.post("/existing")

jesse-2.3.4/jesse/mcp/USAGE_LIMITS.md

@@ -0,0 +1,147 @@
+# MCP Usage Limits
+
+The Jesse MCP server meters the *expensive* research-run tools so free-plan
+users get a generous DAILY credit budget while premium users are unlimited.
+
+## What is metered
+
+Each of these four "run" tools costs **1 credit** — no weighting:
+
+| Tool                     | Credits |
+|--------------------------|---------|
+| `run_backtest`           | 1       |
+| `run_significance_test`  | 1       |
+| `run_monte_carlo`        | 1       |
+| `run_optimization`       | 1       |
+
+Everything else (config/candle/strategy/indicator reads, *draft*
+creation/updates, status polls, `get_*_session`, logs, cancel/terminate,
+purge, …) is FREE and unmetered.
+
+Daily budgets (UTC day): **guests = 0** (no research runs without an account),
+**free (logged-in) = 100**; any paid plan is **unlimited**.
+
+All of the above are config constants in `jesse/mcp/usage_limits.py` and are
+overridable via environment variables:
+
+| Env var                              | Default | Meaning                          |
+|--------------------------------------|---------|----------------------------------|
+| `MCP_GUEST_DAILY_CREDITS`            | 0       | Daily budget for guests (no token); 0 = needs an account|
+| `MCP_FREE_DAILY_CREDITS`             | 100     | Daily budget for free (logged-in)|
+| `MCP_CREDIT_WEIGHT_BACKTEST`         | 1       | Credit cost of `run_backtest`    |
+| `MCP_CREDIT_WEIGHT_SIGNIFICANCE_TEST`| 1       | Credit cost of `run_significance_test`|
+| `MCP_CREDIT_WEIGHT_MONTE_CARLO`      | 1       | Credit cost of `run_monte_carlo` |
+| `MCP_CREDIT_WEIGHT_OPTIMIZATION`     | 1       | Credit cost of `run_optimization`|
+| `MCP_USAGE_METER`                    | local   | Meter backend: `local` or `remote` |
+
+## How a user's plan is determined
+
+Reuses Jesse's existing license system — a **read of an existing endpoint; nothing
+is added on the backend**. `get_user_plan()` calls
+`POST {JESSE_API_URL}/v2/user-info` with `Authorization: Bearer <LICENSE_API_TOKEN>`
+(the same endpoint `jesse.services.general_info.get_general_info` already uses) and
+reads the `plan` field (`free` / `guest` / `basic` / `pro` / `enterprise` /
+`lifetime` / `premium` / …).
+
+- Any PAID plan (anything that isn't `free`/`guest`) → always allowed (unlimited).
+- **`free`** (logged in, not paid) → metered at the free budget (100/day); the
+  over-limit message notes that premium has no daily limit.
+- **`guest`** — i.e. NO license token at all → guest budget is **0** by default, so
+  guests get **no research runs**; the message states that a free account is required.
+  A missing token means *guest*, NOT *error*, so this is deliberately not fail-open.
+- **Plan undetermined** — a real backend error (token present but `/v2/user-info`
+  is unreachable / non-200 / malformed) → **FAIL OPEN** (allow the run, log a
+  warning). We never block a legit user because our own metering plumbing is down —
+  a soft limit, not a hard wall.
+
+> The whole feature is **client-side**: the counter lives in the user's own Redis
+> (see below) and the plan comes from the existing license read above. No new
+> backend endpoint is required. A determined user can bypass a client-side limit;
+> that's an accepted trade-off for a lenient, client-side limit.
+
+## Limit-reached response
+
+When a user is over budget, the gated tool returns this structured dict (it does
+NOT raise — that would break the MCP client). The `message` and `is_guest` differ
+for guests (a free account is required) vs free users (premium has no daily limit):
+
+```json
+{
+  "status": "limit_reached",
+  "message": "Daily free-plan limit reached (X of 100 research runs used today). Upgrade to premium for unlimited runs. Resets at 00:00 UTC.",
+  "used": 100,
+  "limit": 100,
+  "is_guest": false,
+  "reset_at": "2026-06-06T00:00:00+00:00"
+}
+```
+
+## Meter backends
+
+The counter lives behind a small `UsageMeter` interface with two
+implementations, selected via `MCP_USAGE_METER`:
+
+### `local` (default) — `LocalUsageMeter`
+
+Redis-backed daily counter (reuses `jesse.services.redis.sync_redis`).
+One key per user/day: `jesse:mcp:usage:<user_id>:<YYYY-MM-DD>`, where
+`<user_id>` is the `LICENSE_API_TOKEN` (or `anonymous`). The key is `INCRBY`'d
+by the run's cost (1 credit) and given a TTL that expires at the next 00:00 UTC,
+so the counter self-resets daily.
+
+> **Security note:** the local meter is *bypassable* — the MCP server runs on
+> the user's own machine and they control Redis. It is a soft/honest limit
+> only. For a real, enforced limit use the remote meter below.
+
+### `remote` — `RemoteUsageMeter`
+
+Delegates check+consume to the license backend, which owns the counter and is
+authoritative (tamper-proof). **This backend endpoint does not exist yet** —
+the client is written against the contract below for the backend team to
+implement. Switch on with `export MCP_USAGE_METER=remote`.
+
+#### Backend contract (to be implemented)
+
+**Request**
+
+```
+POST {JESSE_API_URL}/mcp-usage/consume
+Authorization: Bearer <LICENSE_API_TOKEN>
+Content-Type: application/json
+
+{ "credits": 1 }
+```
+
+- The license token identifies the user. The backend looks up the user's plan.
+- `credits` is the cost of the run the user is about to do (always 1 today).
+
+**Behaviour**
+
+- `premium` users: always `allowed: true` (the backend may skip counting).
+- `free`/`guest` users: atomically check the user's daily budget and, if there
+  is room, consume `credits`. If consuming would exceed the limit, do NOT
+  consume and return `allowed: false`.
+- The counter resets at 00:00 UTC each day.
+
+**Response** (HTTP 200)
+
+```json
+{
+  "allowed": true,
+  "used": 15,
+  "limit": 100,
+  "reset_at": "2026-06-06T00:00:00+00:00"
+}
+```
+
+| Field      | Type    | Meaning                                                    |
+|------------|---------|------------------------------------------------------------|
+| `allowed`  | bool    | Whether the run may proceed.                               |
+| `used`     | int     | Credits used today (after this consume if allowed).        |
+| `limit`    | int     | The user's daily limit (omit/null for unlimited/premium).  |
+| `reset_at` | string  | ISO8601 timestamp of the next reset (next 00:00 UTC).      |
+
+**Fail-open:** if the backend returns a non-200, non-JSON, or is unreachable,
+the MCP client ALLOWS the run (and logs a warning) so transient backend issues
+never block legit users.
+```

{jesse-2.3.3 → jesse-2.3.4}/jesse/mcp/resources/backtest_management.md

@@ -30,7 +30,7 @@ Default Configuration:
     "export_json": false,
     "export_chart": true,
     "export_tradingview": false,
-    "fast_mode": false,
+    "fast_mode": true,
     "benchmark": true
 }
 ```

{jesse-2.3.3 → jesse-2.3.4}/jesse/mcp/resources/monte_carlo.md

@@ -125,7 +125,7 @@ Stages a draft you can then run.
 - `num_scenarios` — int (default **200**, recommend 200–1000)
 - `run_trades` — bool (default **False**)
 - `run_candles` — bool (default **True**)
-- `fast_mode` — bool (default False; skip charts/heavy outputs)
+- `fast_mode` — bool (default **True**; fast resampling-and-replay path, robust on synthetic candles — recommended)
 - `cpu_cores` — int (default: `cpu_count - 1`, capped at 4)
 - `pipeline_type` — str (default `"moving_block_bootstrap"`)
 - `pipeline_params` — optional JSON object string

jesse-2.3.4/jesse/mcp/resources/optimization.md

@@ -0,0 +1,222 @@
+# Hyperparameter Optimization via MCP
+
+Optimization tunes a strategy's `hyperparameters()` to maximize an objective
+(Sharpe by default) on a **training** window, and reports each candidate's
+**out-of-sample** performance on a separate **testing** window. The train/test
+split is the whole point: it lets you tell a genuinely good parameter set apart
+from one that's overfit to the training data.
+
+It answers: "what parameter values work best for this strategy, and do they hold
+up on data they weren't tuned on?"
+
+## Preconditions (read before creating a draft)
+
+1. **The strategy must declare a non-empty `hyperparameters()`** list — that list
+   is what gets optimized. A strategy with no hyperparameters cannot be optimized
+   and the run stops with an `InvalidStrategy` error. Each entry looks like:
+   ```python
+   def hyperparameters(self):
+       return [
+           {'name': 'fast_period', 'type': int, 'min': 5, 'max': 25, 'default': 10},
+           {'name': 'slow_period', 'type': int, 'min': 26, 'max': 60, 'default': 30},
+       ]
+   ```
+   Types: `int`, `float`, or `categorical` (with an `options` list). The strategy
+   reads the chosen values via `self.hp['name']`.
+2. **Candles must exist for BOTH windows** (training and testing), plus ~warm-up
+   candles before each start. Don't pre-check — run it; on a candle shortage the
+   session stops with a clear message telling you exactly what to import, then
+   `import_candles()` and `rerun_optimization()`.
+
+## Key concepts
+
+| Concept | What it means |
+|---|---|
+| **Training window** | `training_start_date` → `training_finish_date`. The in-sample period the optimizer tunes on. |
+| **Testing window** | `testing_start_date` → `testing_finish_date`. The out-of-sample period each candidate is re-evaluated on (not used for tuning). Conventionally `testing_start_date == training_finish_date` (contiguous), but any non-overlapping ranges are fine. |
+| **objective_function** | What to maximize. One of `sharpe` (default), `calmar`, `sortino`, `omega`, `serenity`, `smart sharpe`, `smart sortino`. |
+| **trials** | Trials **per hyperparameter**. Total trials = `n_hyperparameters × trials`. With 2 hyperparameters and `trials=200`, the optimizer runs 400 trials. Lower it (e.g. 20–50) for a quick exploratory run. |
+| **best_candidates** | The ranked top parameter sets, each with training AND testing metrics. |
+
+## Interpreting best_candidates (overfit detection)
+
+Each finished session exposes `best_candidates`, ranked best-first by the
+objective on the training window. The critical read is **training vs testing**:
+
+| Pattern | Verdict |
+|---|---|
+| Strong on training **and** testing holds up close to training | **Trustworthy.** The parameters generalize — this is what you want. |
+| Strong on training, **much weaker / negative on testing** | **Overfit.** Tuned to noise in the training window; don't deploy. |
+| Mediocre on both | No edge from these parameters — the strategy/idea may not work. |
+| Weak on training but strong on testing | Usually luck on the test window; treat with suspicion, prefer consistency. |
+
+Each candidate carries:
+- `rank` (`#1` is best by the training objective), `trial`, `params` (the tuned
+  values), `fitness` (the objective score), `dna` (a compact encoding),
+- `training_metrics` and `testing_metrics` (full metric dicts each),
+- `objective_metric` — a convenient `"<train> / <test>"` summary on the chosen
+  objective.
+
+**Don't just pick rank #1.** Rank is by *training* fitness; the right choice is
+the candidate whose **testing** metrics hold up best relative to its training
+metrics (smallest train→test degradation), among the strong performers.
+
+## Tool reference
+
+### create_optimization_draft()
+Stages a draft you can then run.
+- `exchange` (default `"Binance Perpetual Futures"`)
+- `routes` — JSON string array of route objects
+- `data_routes` — JSON string array (default `"[]"`)
+- `training_start_date`, `training_finish_date` — `YYYY-MM-DD`
+- `testing_start_date`, `testing_finish_date` — `YYYY-MM-DD`
+- `optimal_total` — int, target number of best candidates to surface (default 50)
+- `objective_function` — str (default `"sharpe"`; see list above)
+- `trials` — int, per hyperparameter (default 200)
+- `best_candidates_count` — int (default 20)
+- `warm_up_candles` — int (default 210)
+- `fast_mode` — bool (default True)
+- `cpu_cores` — int (default `cpu_count - 1`, capped at 4)
+- `title`, `description`, `strategy_summary`, `hypothesis`, `rationale` — optional
+  notes metadata; auto-generated if omitted
+
+Returns: `{ "status": "success", "session_id": "<uuid>", ... }`
+
+### update_optimization_draft(session_id, state)
+Replace the whole `state` on an existing draft (read-modify-write).
+
+### update_optimization_notes(session_id, title?, description?, strategy_codes?)
+Update notes — typically to record the chosen parameters and conclusion.
+
+### get_optimization_session(session_id)
+Fetch full details — the primary polling tool.
+```json
+{
+  "data": { "session": {
+    "id": "<uuid>",
+    "status": "running",
+    "completed_trials": 120,
+    "total_trials": 400,
+    "best_candidates": [
+      { "rank": "#1", "trial": "Trial 18",
+        "params": {"fast_period": 12, "slow_period": 35},
+        "fitness": 0.48, "dna": "...",
+        "training_metrics": {"sharpe_ratio": 2.13, "total": 38, ...},
+        "testing_metrics":  {"sharpe_ratio": 1.72, "total": 17, ...},
+        "objective_metric": "2.13 / 1.72" }
+    ],
+    "objective_curve": [...],
+    "exception": null, "traceback": null
+  } },
+  "error": null, "message": "Optimization session retrieved successfully"
+}
+```
+
+### get_optimization_sessions(limit?, offset?, title_search?, status_filter?, date_filter?)
+List sessions (most recent first). `status_filter`: `draft`, `running`, `paused`,
+`finished`, `stopped`, `terminated`.
+
+### get_optimization_logs(session_id)
+Fetch the log file content. Useful when `status == "stopped"` to find the
+underlying error, or to watch trial-by-trial progress on a long run.
+
+### run_optimization(session_id)
+Fire-and-poll. Returns `{ "status": "started", ... }` when the server accepts.
+Then keep checking `get_optimization_session` until a terminal status. See
+"Checking for results" below.
+
+### rerun_optimization(session_id)
+Reset (clears prior trials/best_candidates) and restart an existing session. Use
+this to run a finished/stopped session again — e.g. after importing missing
+candles or editing the strategy. Cancel a running session first.
+
+### cancel_optimization(session_id)
+Cooperative cancel — stops at the next trial checkpoint; completed trials are kept.
+
+### terminate_optimization(session_id)
+Hard stop — marks the session `terminated` and force-kills the worker. Prefer
+`cancel_optimization` unless the worker is stuck.
+
+### purge_optimization_sessions(days_old?)
+Delete old sessions. If `days_old` is omitted, deletes **all** sessions.
+
+## Checking for results
+
+Optimization is the **slowest** of the modes — it runs `n_hyperparameters ×
+trials` backtests, each on both the training and testing windows. Keep checking
+until a terminal status (`finished`, `stopped`, `terminated`); never ask the user
+to drive the loop. Watch `completed_trials / total_trials` for progress and ETA.
+
+Adaptive check schedule (when `status == "running"`):
+
+| Elapsed since fire | Check every |
+|---|---|
+| 0 – 1 min | 5 s |
+| 1 – 5 min | 20 s |
+| 5 – 30 min | 60 s |
+| 30 – 120 min | 2 – 3 min |
+| > 2 h | 5 min |
+
+If `completed_trials > 0`, estimate ETA as
+`elapsed × (total_trials / completed_trials)` and set the next check to roughly
+`min(remaining_eta / 5, max_interval)`.
+
+Status semantics:
+- `running` / `paused` → keep checking
+- `finished` → read `best_candidates`; report the train-vs-test verdict
+- `stopped` → run failed; read `exception` (e.g. missing candles, or the strategy
+  has no hyperparameters) and `get_optimization_logs(sid)`, then report it
+- `terminated` → user-initiated stop; report the partial state, don't retry
+  without the user's say-so
+
+User-facing language: say **"checking for results"** in chat, not "polling".
+
+## Standard workflow
+
+```python
+# 1. Stage the optimization (train then test, contiguous windows)
+draft = create_optimization_draft(
+    exchange="Binance Perpetual Futures",
+    routes='[{"exchange":"Binance Perpetual Futures","strategy":"MyStrategy","symbol":"BTC-USDT","timeframe":"4h"}]',
+    training_start_date="2023-01-01", training_finish_date="2024-06-01",
+    testing_start_date="2024-06-01",  testing_finish_date="2024-12-01",
+    objective_function="sharpe", trials=100,
+    hypothesis="MyStrategy's EMA periods generalize out-of-sample.",
+)
+sid = draft["session_id"]
+
+# 2. Fire it
+run_optimization(sid)
+
+# 3. Keep checking until terminal (optimization is slow — widen the interval)
+while True:
+    s = get_optimization_session(sid)
+    status = s["data"]["session"]["status"]
+    if status in ("finished", "stopped", "terminated"):
+        break
+    time.sleep(20)
+
+# 4. Pick the candidate that generalizes best (smallest train->test drop)
+session = s["data"]["session"]
+if status == "finished":
+    cands = session["best_candidates"]
+    # report rank #1 plus train-vs-test for the top few; flag overfit candidates
+elif status == "stopped":
+    # read session["exception"] / get_optimization_logs(sid); if missing candles,
+    # import_candles() for both windows (~2 months before each start) then rerun_optimization(sid)
+    ...
+```
+
+## Constraints / common errors
+
+- **Strategy needs `hyperparameters()`** — empty list → `InvalidStrategy`, nothing
+  to optimize.
+- **Candles for BOTH windows** — a shortage stops the session with a message
+  naming both windows; `import_candles()` then `rerun_optimization()`.
+- **`trials` is per-hyperparameter** — total = `n_hyperparameters × trials`. Don't
+  set it huge on a multi-hyperparameter strategy unless you want a very long run.
+- **At least one route is required.**
+- **409 on the main endpoint** — the draft row already exists, which is why
+  `run_optimization` fires via the resume endpoint; you don't normally hit this.
+- **CPU- and time-bound** — far heavier than a single backtest. Use a smaller
+  `trials` and short windows for a quick exploratory pass, then scale up.

{jesse-2.3.3 → jesse-2.3.4}/jesse/mcp/tools/__init__.py

@@ -39,6 +39,7 @@ from jesse.mcp.tools.candles import register_candles_tools
 from jesse.mcp.tools.indicator import register_indicator_tools
 from jesse.mcp.tools.significance_test import register_significance_test_tools
 from jesse.mcp.tools.monte_carlo import register_monte_carlo_tools
+from jesse.mcp.tools.optimization import register_optimization_tools
 
 def register_tools(mcp):
     """
@@ -73,3 +74,6 @@ def register_tools(mcp):
 
     # Monte Carlo simulation tools (robustness analysis of finished strategies)
     register_monte_carlo_tools(mcp)
+
+    # Optimization tools (hyperparameter tuning with train/test split)
+    register_optimization_tools(mcp)

{jesse-2.3.3 → jesse-2.3.4}/jesse/mcp/tools/backtest.py

@@ -24,6 +24,7 @@ from .services import (
     cancel_backtest_service,
     purge_backtest_sessions_service
 )
+from jesse.mcp.usage_limits import gated, CREDIT_WEIGHTS
 
 def register_backtest_tools(mcp):
     """
@@ -49,7 +50,7 @@ def register_backtest_tools(mcp):
         export_json: bool = False,
         export_chart: bool = True,
         export_tradingview: bool = False,
-        fast_mode: bool = False,
+        fast_mode: bool = True,
         benchmark: bool = True,
         title: str = None,
         description: str = None,
@@ -90,7 +91,8 @@ def register_backtest_tools(mcp):
             export_json (bool): Export backtest results as JSON file
             export_chart (bool): Export chart data for visualization
             export_tradingview (bool): Export TradingView Pine Script for chart analysis
-            fast_mode (bool): Enable fast mode for quicker execution (reduced precision)
+            fast_mode (bool): Enable fast mode for quicker execution (reduced precision).
+                Defaults to True. The agent may set it False for a full-precision run.
             benchmark (bool): Run benchmark comparison against buy-and-hold strategy
             title (str, optional): Human-readable note title for this MCP-created session.
                 If omitted, Jesse MCP generates one from the first route.
@@ -431,6 +433,7 @@ def register_backtest_tools(mcp):
         )
 
     @mcp.tool()
+    @gated(weight=CREDIT_WEIGHTS["run_backtest"])
     def run_backtest(session_id: str) -> dict:
         """
         Trigger a backtest and return immediately (fire-and-poll pattern).

{jesse-2.3.3 → jesse-2.3.4}/jesse/mcp/tools/monte_carlo.py

@@ -33,6 +33,7 @@ from .services import (
     terminate_monte_carlo_service,
     purge_monte_carlo_sessions_service,
 )
+from jesse.mcp.usage_limits import gated, CREDIT_WEIGHTS
 
 
 def register_monte_carlo_tools(mcp):
@@ -48,7 +49,7 @@ def register_monte_carlo_tools(mcp):
         num_scenarios: int = 200,
         run_trades: bool = False,
         run_candles: bool = True,
-        fast_mode: bool = False,
+        fast_mode: bool = True,
         cpu_cores: int = None,
         pipeline_type: str = 'moving_block_bootstrap',
         pipeline_params: str = None,
@@ -81,7 +82,14 @@ def register_monte_carlo_tools(mcp):
             run_candles: Whether to run the candles resampler (default True).
                 Candles MC is the main mode — it resamples the underlying
                 price series and re-runs the strategy on each variant.
-            fast_mode: Skip charts/heavy outputs for speed (default False).
+            fast_mode: Use the fast resampling-and-replay path (default True).
+                Strongly recommended for candle Monte Carlo: the full
+                step-simulator can blow up on synthetic bootstrapped candles
+                (risk-sized strategies size positions off a momentarily tiny
+                ATR, the balance compounds to overflow, and scenarios die with
+                InsufficientMargin / Infinity). The fast path is robust and is
+                what the dashboard's healthy runs use. Only set False if you
+                specifically need the step simulator and accept those caveats.
             cpu_cores: Worker count. Defaults to (cpu_count - 1, capped at 4).
             pipeline_type: Candle resampling pipeline. Default
                 "moving_block_bootstrap". Other options depend on the
@@ -306,6 +314,7 @@ def register_monte_carlo_tools(mcp):
         return get_monte_carlo_logs_service(session_id)
 
     @mcp.tool()
+    @gated(weight=CREDIT_WEIGHTS["run_monte_carlo"])
     def run_monte_carlo(session_id: str) -> dict:
         """
         Fire a Monte Carlo simulation for a previously created draft and return immediately.