> For the complete documentation index, see [llms.txt](https://platformdocs.lattica.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://platformdocs.lattica.ai/platform-workflows/worker-management.md).

# Worker Management

## Fundamentals

1. **Worker-Model Relationship**
   * Each worker operates for a **single workload**, created and managed by the Workload Provider.
   * **One Worker, One Workload**: Workers cannot process multiple workloads, but a single workload can be deployed on multiple workers simultaneously.
2. **Credit-Based Payment**
   * Workload Providers pay for workers’ runtime using credits purchased in advance.
   * The worker continuously deducts credits while in operation.
3. **Requirements to Start a Worker**
   * The workload must be **active**.
   * The provider’s account must have **sufficient credits** to sustain the worker.
4. **Query Processing and Worker Runtime**\
   When an end user submits a query using a valid **access token**, the request is routed to a **worker** running the workload associated with that token.
   * **Workers** execute encrypted queries.
   * **Workload Providers** are billed based on the **runtime of active workers**, not the number of queries processed.
   * **Performance Considerations:** High query volumes on a single worker may impact response times - scale worker sessions accordingly for optimal performance.
5. **Scaling Workers**
   * Providers can start additional workers for the same workload if performance drops due to high query volume.
   * There is **no limit** to the number of workers that can run for a workload simultaneously.
6. **Monitoring Worker Performance**
   * Providers can monitor worker performance by viewing:
     * **Average Query Time**: The average processing time for a query on the workload.
     * **Current Query Time**: The real-time processing time for queries on the workload.
7. **Stopping Workers**
   * Workers can be stopped manually at any time.
   * If credits are depleted, workers are automatically stopped.

***

## Worker Management Workflow

{% stepper %}
{% step %}

### S**tart Worker**

Before starting a worker, verify that your account has sufficient credits and check that your workload is properly activated in the system.
{% endstep %}

{% step %}

### M**onitor Performance**

Regularly check query performance metrics (average and current query time). Add workers if needed to maintain optimal performance.
{% endstep %}

{% step %}

### S**top Worker**

Stop workers when they are no longer needed or when credit consumption needs to be managed.
{% endstep %}
{% endstepper %}

***

## Future Functionality

1. **Performance Notifications**\
   Workload Providers will receive alerts when worker performance drops below a defined threshold.
2. **Worker Usage Reports**\
   A detailed report of worker usage will help providers analyze and optimize their resource utilization.
3. **Scheduler for Worker Management**\
   Workload Providers will be able to define schedules to start and stop workers automatically, eliminating the need for manual operations. This functionality will help align worker usage with predictable query loads and save credits during low-demand periods.

***

## Quick Links to How-To Pages

For detailed steps, refer to the following guides:

* \[How-To: [Start Worker](/how-to-guides/resource-management/how-to-start-worker.md)]
* \[How-To: [Stop Worker](/how-to-guides/resource-management/how-to-stop-worker.md)]
* \[How-To: [Monitor Worker Performance](/how-to-guides/resource-management/how-to-monitor-worker-performance.md)]

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://platformdocs.lattica.ai/platform-workflows/worker-management.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.