Recap

Open a thread and read a short recap of it without putting that summary back into the model's context. Recap stores the text in its own database, so the original conversation stays unchanged.

What you get

• A compact banner above the composer, a larger recap card, or no inline recap until you open the Recap panel.
• Generate from the thread header, the command palette, or bb recap.
• Automatic recaps after a visible thread goes idle, once it has enough user turns. Recap does not scan every idle thread on startup.
• A refresh when the thread has moved on. A new turn hides the previous recap until a newer one exists.
• Settings for the model, idle delay, turn minimum, concurrent workers, prompt, auto-cleanup, and display layout.

How it works

Each recap is generated by a hidden BB worker that receives a bounded transcript and the configured prompt. The worker uses Accept Edits, the least-permissive spawn mode BB currently offers, and is instructed to produce only a recap. Recap archives and stops the worker after every attempt, including failures. Automatic recaps retry at most three times for transient worker failures.

Recaps live in Recap's namespaced SQLite database. Auto-cleanup, on by default, removes suppressed attempts, invalidated recaps, and visible records beyond the newest 1,000. It never deletes BB threads, messages, files, or projects. Generated text is limited to 1,200 characters.

Use bb recap recap, bb recap show, and bb recap list from a thread-aware CLI context. summarize is an alias for recap.

Requirements

• BB 0.40 or newer.
• Recap has no account or API key of its own. It uses a provider and model already configured in BB. Without a saved selection, recaps use BB's current default model.
• The selected provider may process the transcript remotely under that provider's policy.