Signing in has become slow for me — the first load takes a long time and the UI feels sluggish afterwards. I have a lot of old sessions piled up, so my instinct was to clear out the ones I no longer need. Before I do that, two things I could not work out from the UI: 1. Is there a real delete for a session, or does everything end up archived with the data still there? 2. Does archiving actually reduce what gets loaded at sign-in? If the slowness is not caused by the number of sessions, I would rather not spend an afternoon tidying up for nothing — I would like to know what to look at instead. If session count does matter, some way to archive in bulk (or by date range) would help a lot.

Hi Bram, To save you an afternoon: **don't spend time manually archiving your old sessions — it won't fix the sign-in slowness.** Here is the exact breakdown of how sessions work under the hood and what is likely causing the sluggishness instead: 1. Is there a real delete, or is archiving the only option? Currently, **archiving is the only option**. When you delete or archive a session from the UI, it performs a soft-delete: - The session is marked with an `archivedAt` timestamp and removed from your active sidebar. - All session data, conversation messages, and artifacts remain safely preserved in the database. - You can inspect or restore archived sessions at any time by going to **Agent Settings → Archive**. - There is currently no permanent hard-delete option exposed in the UI. 2. Does archiving reduce what gets loaded at sign-in? **Practically speaking, no.** - Buda's session sidebar does **not** download your entire historical backlog on sign-in. It queries sessions in small, paginated batches (typically 40–50 items) and uses a local client cache (IndexedDB + memory). - Full message histories and tool outputs are **never** loaded in bulk — they are only fetched on-demand when a specific session is opened. - Whether you have 20 old sessions or 1,000 in your account, the data transferred for the session list on sign-in is essentially the same. 3. What should you look at instead? The slowness during sign-in and first load is almost certainly caused by one of the following: **A heavy last-active session being resumed automatically:** When you sign in, Buda automatically re-opens the last active session you had selected. If that particular session has grown huge (hundreds of messages, long terminal logs, code diffs, or image/video artifacts), the browser has to hydrate and render all those DOM elements at once, making the UI feel frozen or sluggish. Let us know if testing a fresh session changes the load performance for you!

Signing in has become slow for me — the first load takes a long time and the UI feels sluggish afterwards. I have a lot of old sessions piled up, so my instinct was to clear out the ones I no longer need. Before I do that, two things I could not work out from the UI: 1. Is there a real delete for a session, or does everything end up archived with the data still there? 2. Does archiving actually reduce what gets loaded at sign-in? If the slowness is not caused by the number of sessions, I would rather not spend an afternoon tidying up for nothing — I would like to know what to look at instead. If session count does matter, some way to archive in bulk (or by date range) would help a lot.

Hi Bram, To save you an afternoon: **don't spend time manually archiving your old sessions — it won't fix the sign-in slowness.** Here is the exact breakdown of how sessions work under the hood and what is likely causing the sluggishness instead: 1. Is there a real delete, or is archiving the only option? Currently, **archiving is the only option**. When you delete or archive a session from the UI, it performs a soft-delete: - The session is marked with an `archivedAt` timestamp and removed from your active sidebar. - All session data, conversation messages, and artifacts remain safely preserved in the database. - You can inspect or restore archived sessions at any time by going to **Agent Settings → Archive**. - There is currently no permanent hard-delete option exposed in the UI. 2. Does archiving reduce what gets loaded at sign-in? **Practically speaking, no.** - Buda's session sidebar does **not** download your entire historical backlog on sign-in. It queries sessions in small, paginated batches (typically 40–50 items) and uses a local client cache (IndexedDB + memory). - Full message histories and tool outputs are **never** loaded in bulk — they are only fetched on-demand when a specific session is opened. - Whether you have 20 old sessions or 1,000 in your account, the data transferred for the session list on sign-in is essentially the same. 3. What should you look at instead? The slowness during sign-in and first load is almost certainly caused by one of the following: **A heavy last-active session being resumed automatically:** When you sign in, Buda automatically re-opens the last active session you had selected. If that particular session has grown huge (hundreds of messages, long terminal logs, code diffs, or image/video artifacts), the browser has to hydrate and render all those DOM elements at once, making the UI feel frozen or sluggish. Let us know if testing a fresh session changes the load performance for you!

Question

Closed · Answered

Can old sessions be deleted for real, or is archiving the only option?

BramSep 22, 2026

Signing in has become slow for me — the first load takes a long time and the UI feels sluggish afterwards. I have a lot of old sessions piled up, so my instinct was to clear out the ones I no longer need.

Before I do that, two things I could not work out from the UI:

Is there a real delete for a session, or does everything end up archived with the data still there?
Does archiving actually reduce what gets loaded at sign-in? If the slowness is not caused by the number of sessions, I would rather not spend an afternoon tidying up for nothing — I would like to know what to look at instead.

If session count does matter, some way to archive in bulk (or by date range) would help a lot.

Report

Caedman Lan

Team

26d ago

Hi Bram,

To save you an afternoon: don't spend time manually archiving your old sessions — it won't fix the sign-in slowness.

Here is the exact breakdown of how sessions work under the hood and what is likely causing the sluggishness instead:

Is there a real delete, or is archiving the only option?

Currently, archiving is the only option. When you delete or archive a session from the UI, it performs a soft-delete:

The session is marked with an archivedAt timestamp and removed from your active sidebar.

All session data, conversation messages, and artifacts remain safely preserved in the database.

You can inspect or restore archived sessions at any time by going to Agent Settings → Archive.

There is currently no permanent hard-delete option exposed in the UI.

Does archiving reduce what gets loaded at sign-in?

Practically speaking, no.

Buda's session sidebar does not download your entire historical backlog on sign-in. It queries sessions in small, paginated batches (typically 40–50 items) and uses a local client cache (IndexedDB + memory).

Full message histories and tool outputs are never loaded in bulk — they are only fetched on-demand when a specific session is opened.

Whether you have 20 old sessions or 1,000 in your account, the data transferred for the session list on sign-in is essentially the same.

What should you look at instead?

The slowness during sign-in and first load is almost certainly caused by one of the following:

A heavy last-active session being resumed automatically:

When you sign in, Buda automatically re-opens the last active session you had selected. If that particular session has grown huge (hundreds of messages, long terminal logs, code diffs, or image/video artifacts), the browser has to hydrate and render all those DOM elements at once, making the UI feel frozen or sluggish.

Let us know if testing a fresh session changes the load performance for you!

Report

Your reply

Question

Closed · Answered

Can old sessions be deleted for real, or is archiving the only option?

BramSep 22, 2026

Before I do that, two things I could not work out from the UI:

Is there a real delete for a session, or does everything end up archived with the data still there?
Does archiving actually reduce what gets loaded at sign-in? If the slowness is not caused by the number of sessions, I would rather not spend an afternoon tidying up for nothing — I would like to know what to look at instead.

If session count does matter, some way to archive in bulk (or by date range) would help a lot.

Report

Caedman Lan

Team

26d ago

Hi Bram,

To save you an afternoon: don't spend time manually archiving your old sessions — it won't fix the sign-in slowness.

Here is the exact breakdown of how sessions work under the hood and what is likely causing the sluggishness instead:

Is there a real delete, or is archiving the only option?

Currently, archiving is the only option. When you delete or archive a session from the UI, it performs a soft-delete:

The session is marked with an archivedAt timestamp and removed from your active sidebar.

All session data, conversation messages, and artifacts remain safely preserved in the database.

You can inspect or restore archived sessions at any time by going to Agent Settings → Archive.

There is currently no permanent hard-delete option exposed in the UI.

Does archiving reduce what gets loaded at sign-in?

Practically speaking, no.

Buda's session sidebar does not download your entire historical backlog on sign-in. It queries sessions in small, paginated batches (typically 40–50 items) and uses a local client cache (IndexedDB + memory).

Full message histories and tool outputs are never loaded in bulk — they are only fetched on-demand when a specific session is opened.

Whether you have 20 old sessions or 1,000 in your account, the data transferred for the session list on sign-in is essentially the same.

What should you look at instead?

The slowness during sign-in and first load is almost certainly caused by one of the following:

A heavy last-active session being resumed automatically:

Let us know if testing a fresh session changes the load performance for you!

Report