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

# Manage Loop threads and limits

> Rename and delete threads, and learn how Loop's per-user sandboxes start, sleep, and count against your plan's concurrency limit.

Loop threads persist, so you can leave a page and come back to the work in progress. This page covers cleaning them up and the sandbox limits that govern how many you can run at once.

## Rename a thread

On the [**<Icon icon="blend" /> Loop**](https://www.braintrust.dev/app/~/loop) page, select the <Icon icon="ellipsis" /> menu on the thread header or on any thread in the sidebar, select <Icon icon="pencil" /> **Rename thread**, enter a name of up to 256 characters, then click **Save**.

## Delete a thread

On the [**<Icon icon="blend" /> Loop**](https://www.braintrust.dev/app/~/loop) page, select the <Icon icon="ellipsis" /> menu on the thread header or on any thread in the sidebar, select <Icon icon="trash-2" /> **Delete thread**, then confirm.

<Warning>
  Deleting a thread is permanent and cannot be undone.
</Warning>

You can't delete a thread while Loop is actively working in it. A thread whose sandbox has gone to sleep isn't running, so you can delete it. Automation run threads are read-only and can't be deleted this way. See [Review past runs](/docs/loop/automations#review-past-runs).

## Sandboxes

Loop runs in an isolated, per-user sandbox, which is what lets it inspect trace files directly and run commands against your data.

**When a sandbox starts.** Loop starts one the first time you send a message in a thread, not when you open the [**<Icon icon="blend" /> Loop**](https://www.braintrust.dev/app/~/loop) page or revisit a saved thread. One active thread uses one sandbox.

**When a sandbox stops counting.** After a period without activity, the sandbox goes to sleep, and a sleeping sandbox doesn't count toward your concurrent limit. Send another message in that thread and it resumes automatically, with the thread's history intact. The concurrent limit therefore applies to the threads you're working in at the same time, not to the total number of threads you've created.

**When you reach the limit.** If you send a message while all your sandboxes are running, Loop makes room by putting the sandbox of the thread that has been quiet longest to sleep, and your message proceeds. That thread and its history stay intact, and it resumes when you send it another message. You only see an error if every sandbox is actively working, such as several threads running long investigations at once. Wait for one to finish, then send the message again.

When a sandbox reaches its maximum lifetime, Loop starts a fresh one for your next message. Your thread and its history are unaffected.

### Concurrency limits

Concurrent sandboxes are counted per user across all of your organizations, not per organization.

| Plan                 | Concurrent running sandboxes |
| -------------------- | ---------------------------- |
| Starter              | 5                            |
| Pro and Enterprise   | 50                           |
| Self-hosted and BYOC | Unlimited                    |

A sandbox has a maximum lifetime of 8 hours, including time spent asleep.

<Note>
  Self-hosted deployments provide their own sandboxes, so the limits above depend on the capacity you provision. On AWS, enable the [Loop runtime](/docs/admin/self-hosting/configure/loop-runtime) to run Loop in your data plane. Until you do, Loop runs in the browser instead.
</Note>

## Models and providers

Loop runs on GPT-5.6 Sol, GPT-5.6 Terra, and GPT-5.6 Luna, and the **Built-in** setting in the model picker decides who pays for the inference:

* **On.** Braintrust serves the model from its own AI providers, and usage draws down your organization's monthly [model credits](/docs/plans-and-limits#model-credits), shared with Topics. No setup required, and it's the only option until you configure a provider that can serve the model you selected. On the Starter plan, this setting requires at least one organization owner with a work email address, or a payment method on file. See [Requirements](/docs/admin/ai-providers#requirements).
* **Off.** The model runs through one of your organization's own OpenAI-compatible [AI providers](/docs/admin/ai-providers), and inference is billed to that provider. The **Provider** setting picks which one, and Loop pins that choice to the thread.

Loop remembers the setting for each thread and applies your most recent choice to new threads.

Compatible providers are OpenAI, Azure, Bedrock, and OpenRouter, plus an Azure AI Gateway provider that serves the GPT-5.6 models. You need one of these once your model credits are exhausted.

To keep members off the built-in models, turn **Allow built-in models** off on the [AI providers](/docs/admin/ai-providers#manage-built-in-models) page. Loop then runs only on your organization's own providers, and the **Built-in** setting is unavailable.

## Privacy

Threads are private to the person who created them. Loop cannot see another user's threads, and sharing a thread with a teammate is not available.

By default, Braintrust logs frontend Loop interactions for product improvement and support. Loop works normally with this turned off, and self-hosted organizations have it off by default. See [Control Loop logging](/docs/admin/organizations#control-loop-logging).

## Next steps

* [What Loop can do](/docs/loop/capabilities) for the full range of tasks.
* [Run Loop on a schedule](/docs/loop/automations) for work that shouldn't depend on an open chat.
* [Plans and limits](/docs/plans-and-limits) for the rest of the system limits.
