> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thoras.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Choosing a Forecast Optimization Strategy

Thoras forecasts future demand for your workload and recommends resource levels
accordingly. You can choose an optimization strategy that reflects your
operational priorities.

All strategies forecast demand and remain peak-aware. The difference is how
closely recommendations track usage versus how much additional margin they
maintain.

Thoras modes span a spectrum from cost optimization to assurance focused:

`undershoot` → `cost_optimized` → `balanced` → `assurance_optimized` →
`overshoot`

Because Thoras is forecasting future demand, no mode eliminates forecast misses
entirely. More aggressive modes are more likely to run closer to real demand,
while more conservative modes maintain more room above it.

`percentile` is an alternative mode that sets the forecast directly from
historical usage rather than predicting future demand.

## Quick Reference

| Strategy              | Approach                                              | Recommended For                                     |
| --------------------- | ----------------------------------------------------- | --------------------------------------------------- |
| `undershoot`          | Allows recommendations to run below usage more often  | Non-critical or resilient jobs                      |
| `cost_optimized`      | Tracks tightly with minimal headroom                  | Async, retry-safe workloads                         |
| `balanced` (default)  | Tracks usage with balanced efficiency and assurance   | General production workloads                        |
| `assurance_optimized` | Tracks above usage with moderate headroom             | User-facing or consistency-sensitive workloads      |
| `overshoot`           | Maintains elevated headroom based on historical usage | Critical workloads requiring additional consistency |
| `percentile`          | Forecast set at Nth percentile of historical usage    | Stable workloads with a specific coverage target    |

## Mode Details

### `balanced` (default)

* Balances efficiency and assurance with comfortable headroom
* Provides strong coverage against historically observed demand volatility
* Choose this for production workloads where you want both optimization and
  consistency

### `cost_optimized`

* Uses tighter recommendations to reduce unused capacity
* May allow occasional brief resource pressure during rare demand spikes
* Best for workloads that tolerate moderate variability: background jobs, async
  services, retry-safe systems

### `undershoot`

* Most aggressive low-headroom strategy
* Intentionally allows recommendations to run below observed demand more often
* Best for non-critical workloads, batch processing, or systems with strong
  retry logic and fallback behavior

### `assurance_optimized`

* Tracks above typical usage patterns while remaining responsive to changes
* Stays close to usage for steady workloads, increasing headroom when
  variability rises
* Best for workloads where consistency is important without significantly
  increasing resource usage

### `overshoot`

* Maintains consistent headroom based on historical usage levels
* Less responsive to short-term changes in usage patterns
* Best for workloads where maintaining additional headroom is preferred over
  tighter recommendations

### `percentile`

* Forecast is set to the Nth percentile of observed historical usage
* `percentile_value` (0–100) is required and determines the coverage level: a
  value of `80` means 80% of historical data points fell at or below the
  forecast value
* Best for workloads where you want to set a specific historical coverage target
  rather than rely on demand prediction

```yaml theme={null}
spec:
  model:
    mode: percentile
    percentile_value: 80
```

If not specified, the default is `mode: balanced`.

## Configuring Forecast Mode

Set the optimization strategy in your AIScaleTarget:

```yaml theme={null}
spec:
  model:
    mode: assurance_optimized
```

You can also configure different modes per metric. See
[model.metrics reference](/reference/ast-definition#model-metrics) for details.

## Fine-Tuning Forecast Behavior

After choosing a forecast optimization strategy, you can further tune forecast
behavior using additional settings. These are best used for workload-specific
adjustments after selecting your primary mode.

### `forecast_buffer_percentage`

Adds a fixed percentage on top of the forecasted recommendation.

**Use this when:**

* The forecast is generally reasonable, but you want it to run slightly higher
  or lower overall

**Reference:**
[model.forecast\_buffer\_percentage](/reference/ast-definition#model-forecast-buffer-percentage)

### `forecast_interval`

Controls how often Thoras generates a new forecast.

**Use this when:**

* Workload behavior changes quickly and recommendations need to refresh more
  often

**Reference:**
[model.forecast\_interval](/reference/ast-definition#model-forecast-interval)

### `forecast_blocks`

Controls how far into the future each forecast is trying to cover.

**Use this when:**

* You want Thoras to account for demand farther ahead in time

**Note:** `forecast_blocks` should be greater than or equal to
`forecast_interval` to ensure each forecast covers the next update window.

**Reference:**
[model.forecast\_blocks](/reference/ast-definition#model-forecast-blocks)

### Quick Guidance

If you're deciding what to adjust:

* Change **`mode`** when you want forecasts to behave more aggressively or
  conservatively
* Change **`forecast_buffer_percentage`** when the forecast shape looks right,
  but you want to raise or lower the average prediction
* Change **`forecast_interval`** when you want forecasts to update more or less
  frequently
* Change **`forecast_blocks`** when you want to adjust how far ahead forecasts
  look (longer horizons are more conservative but may increase overprovisioning)

**In most cases, `model.mode` should be your first tuning lever.** The settings
above are for smaller workload-specific adjustments.

Your model mode also determines default scaling thresholds, controlling how
large a suggested change must be before a scaling action fires. See
[`scaling_behavior`](/reference/ast-definition#scaling_behavior) for details.