The 55s timeout is indeed on the MotherDuck side. However, it is set so that you don't encounter the 60s timeout on the claude.ai side. The claude side is a silent timeout whereas the MotherDuck is explicit.
There are a number of suggestions to doing your CTAS with over a billion rows. These are claude's suggestions:
What actually works for a CREATE TABLE AS <complex select over ~1B rows>
A few options, in roughly increasing order of robustness:
1. Fire-and-forget with polling. Issue the CREATE TABLE and don't wait synchronously. MotherDuck supports inspecting active server connections via md_active_server_connections() and interrupting them with md_interrupt_server_connection(client_connection_id). The pattern: have the LLM issue the CREATE TABLE wrapped so it runs server-side, then check progress with separate short queries on subsequent turns. This keeps each individual MCP call under the 55s wall. MotherDuckMotherDuck
2. Decompose the query. Build the derived table in chunks. CREATE TABLE my_derived AS SELECT ... WHERE date_bucket = '2024-01' then INSERT INTO my_derived SELECT ... WHERE date_bucket = '2024-02', etc. Each insert finishes inside 55s and the result is the same table.
3. Use a materialized intermediate. If the bottleneck is a heavy aggregation, pre-aggregate to a smaller staging table first, then the final CREATE TABLE is cheap. Two short hops instead of one long one.
4. Move off web claude.ai for the heavy job. Run the same CREATE TABLE from Claude Code (their machine) using either DuckDB CLI with md: or the local MotherDuck MCP server. Claude Code's MCP timeout is also ~60s by default, but the customer can drop the MCP entirely there and just have Claude Code shell out to duckdb md: -c "CREATE TABLE ..." — that runs as a regular subprocess with no MCP timeout in the path at all. The model only sees "command exited 0 after 14m32s," which is exactly the "model orchestrates, doesn't carry the payload" pattern from the previous thread.
.png){kind=logo}
