7. Cache and Data Reuse
Caching lets you "stage" a query result as a queryable table so other queries can reference it directly.
7.1 What Is a Cached Table
When you run a query on a Persist tab, the result is automatically cached as a temporary table named after the tab. It appears under the Cached node in the sidebar Data section, and you can reference it in other SQL queries.
7.2 How to Create Cache
- Create a tab and write a SQL query.
- Save the tab (make it a Persist tab).
- Run the query—the result is cached as a table with the same name as the tab.
For example, if you have a Persist tab named clean_orders, after you run it, its query result becomes a cached table named clean_orders.
7.3 Reference Another Tab's Cache in SQL
You can use cached table names directly in any SQL. For example:
SELECT category, SUM(amount) AS total
FROM "clean_orders"
GROUP BY category
Here "clean_orders" is the cache from another Persist tab.
Tip: Expand Data → Cached and double-click a cached table name to insert it into the editor.
7.4 Manage Cache (View / Refresh / Delete)
The cached table list updates with Refresh on the Data title row—that button rescans local files, refreshes the cache list, and re-fetches schema for loaded external connections.
Cached (n) parent row (list header):
Right-click Cached (n) for:
| Action | Description |
|---|---|
| Sort by… | Name or Modified time (four combinations); default is newest modified first (see §4.1 "List sorting") |
| Clear Agent Cache | Delete all Agent cache in the current workspace |
| Clear All Cache | Delete all cached tables in the current workspace (persist and agent) |
Bulk clear actions are disabled while a clear is in progress.
Single cache item:
Each cache item is one row: table name on the left, updated time on the right. Right-click a cache item for the action menu.
Actions available for all cache items:
| Action | Description |
|---|---|
| SELECT 100 rows | Insert SELECT * FROM "table_name" LIMIT 100 into the editor for a quick preview |
| View SQL | Open a read-only dialog showing the SQL that produced the cache; copy or insert into editor |
| Delete | Remove this cached table |
Cache from Persist tabs (persist cache) also provides:
| Action | Description |
|---|---|
| Run | Re-run the tab SQL that produced the cache |
| Source Run | Run source execution (see Chapter 8) |
| Open Tab | Open the Persist tab that produced the cache |
| Check Lineage | View lineage graph (see Chapter 8) |
Cache produced by the AI Agent (agent cache):
During multi-step background analysis, the system registers intermediate results as queryable tables per conditional materialization policy (see §12.6). Agent cache does not participate in Source Run, but you can reference it with FROM in other SQL. In View SQL, the subtitle shows "Agent cache"; persist cache shows "Persist tab cache", and SQL usually comes from tab content.
If SQL is unavailable (for example old cache or expired result), the dialog shows a notice; you can still delete the cache or re-run the corresponding tab.
Deleting cache and conversation step records: Right-click Delete removes the cache table from DuckDB and marks the corresponding step as deleted in the conversation-level Query Step Ledger (historical JSON is not deleted). After that, the AI's Recent Query Steps summary and list_query_steps no longer list deleted cache by default; for re-analysis, the Agent should re-run queries and materialize new cache.
Note: Cached tables are cleared when you switch workspaces or restart the app. Re-run the corresponding tab when you need them again.
[Image] Cached node under sidebar Data, cache list and right-click menu
[Image] Example SQL referencing a cached table
Design note: Cache semantics, conditional materialization, and View SQL rationale are in Unified Query Layer §7.1.