> ## 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.

# Enabling Autonomous Mode

> Enable predictive scaling with confidence

Following this quick checklist helps ensure your workloads are ready for
predictive autoscaling.

## Autonomous Mode Checklist

1. For autonomously scaling, Thoras requires the ability to persist historical
   metrics, which requires a Kubernetes persistent volume. See
   [Configure Persistent Volume](../installation/advanced-setup#persistent-volumes)
   page for a walkthrough

2. For managing more than one hundred workloads, you'll want to allocate more
   forecast workers. See
   [Configure Worker Capacity](../installation/advanced-setup#configure-worker-capacity)

3. Deploying Thoras with ArgoCD? Check out the
   [ArgoCD config considerations](../guides/argo-cd)

4. \[Optional] `kubectl` port-forwarding is a great way to experiment, but you
   may eventually want to expose the dashboard service internally to enable
   broader, more stable access. You can do this by enabling `Ingress` via
   `$.Values.thorasDashboard.ingress` or `GatewayAPI` via
   `$.Values.thorasDashboard.gatewayAPI`. See
   [GitHub](https://github.com/thoras-ai/helm-charts/blob/main/charts/thoras/README.md#thoras-dashboard)
   for further documentation

5. **Check predictions in the dashboard** - confirm metric suggestions for your
   workload are accurate. The Thoras reasoning engine typically needs to see a
   pattern twice to learn about it; so model performance can take between a few
   minutes to a few days to reach maximum accuracy.

<img src="https://mintcdn.com/thoras/SlaX_dne9nsRxoWC/guides/predictions-vs-usage.png?fit=max&auto=format&n=SlaX_dne9nsRxoWC&q=85&s=c5fa05efa707eabf4fbf8e057e22702e" alt="predictions-vs-usage" width="1492" height="1358" data-path="guides/predictions-vs-usage.png" />

6. **Wait for sufficient historical data** - Autonomous scaling requires at
   least 3 hours of historical data by default before it can be enabled. This
   ensures enough data confidence for safe scaling decisions. Configure via
   `model.min_lookback_to_scale` in the
   [AST definition](../reference/ast-definition#modelmin_lookback_to_scale) to
   adjust this threshold.

7. **Understand application behavior** - for vertical scaling, ensure the
   workload and its dependencies can handle periodic restarts. See the
   [vertical pod rightsizing](../guides/vertical-pod-rightsizing) and
   [aiscaletarget](../reference/ast-definition) pages for an overview of scaling
   and restart configuration options.

8. **Choose a scaling direction** - only one scaling direction (horizontal or
   vertical) can be in autonomous mode at a time. Choose the direction that best
   fits your workload:
   * **Horizontal** for workloads with variable traffic patterns that need to
     scale the number of replicas to handle demand spikes.
   * **Vertical** for workloads with more predictable resource patterns that
     benefit from optimized CPU and memory requests to improve cluster
     utilization and reduce costs. **Note:** before enabling `Autonomous Mode`,
     verify no competing vertical autoscaling controllers are modifying pod
     resource requests for the same workloads. Running multiple controllers that
     attempt to adjust pod resource allocation can lead to unstable behavior,
     oscillation, or conflicting decisions.

See
[Understanding Vertical and Horizontal Scaling Modes](./configuring-asts#understanding-vertical-and-horizontal-scaling-modes)
for more details.