NotebookLM CLI gotchas + multi-agent patterns#

A 2026-05-12 8-tengelyű szuperintelligens-vault Phase A + A+ research során felfedezett notebooklm CLI quirks és multi-agent batch-patternek. ~4800 forrás importálva, 80 strukturált kérdés válaszolva 1 nap alatt, közben minden buktató kéznél.

1. `notebooklm create "Title" --json` empty-ID bug#

Tünet: notebooklm create "Title" --json → empty stdout (üres JSON), a parse-olt ID üres string.

Következmény: ha utána notebooklm use "" fut, NEM váltja a context-et — az ELŐZŐ aktív notebook marad. Cross-contamination.

Megoldás: --json nélkül futtass, és parse-old a stdout-ot regex-szel:

out=$(notebooklm create "SV-1 Memory architecture" 2>&1)
id=$(echo "$out" | grep -oE '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}' | head -1)

Konkrét incidens (2026-05-12): 6 forrás (MemGPT, GraphRAG, Generative Agents, RAPTOR, Letta, Mem0) véletlenül a Wellbeing 3.0 notebookba ment Atti-research helyett. A classifier helyesen blokkolta a takarító delete-et (más-user-notebook write). Manual user-cleanup szükséges volt.

2. Explicit `-n <NB_ID>` MINDEN parancsban — NE támaszkodj `notebooklm use`-ra#

Multi-agent race-condition: ha 7-8 párhuzamos sub-agent dolgozik különböző notebookokon, a notebooklm use <id> egyetlen shared session-state-be ír (/root/.notebooklm/storage_state.json). Az utolsó use nyer, a többi agent rossz notebookot ír.

Konvenció: MINDEN notebooklm <subcommand> parancsban explicit -n <NB_ID> flag. Példa:

notebooklm source add "https://arxiv.org/abs/2310.08560" -n "$NB_ID"
notebooklm ask -n "$NB_ID" "kérdés"
notebooklm research wait -n "$NB_ID" --import-all

3. `notebooklm ask` marker-pattern API-fallback (600 char csonkolás)#

Tünet: néhány válasz fallback-olt a "longest unmarked text (600 chars)" warning-gal, plus angol nyelven jött (nem magyar) — a NotebookLM API marker-pattern változott.

Konkrét incidens (2026-05-12): SV-6 Q3 Cost-sensitive trade-off csak ~600 char, csonkolt 3-tier táblázat-input. Manual jelölés (retry-pending) a wiki-cikkben.

Megoldás: - Rövidebb prompt (max 200-300 char) használata bonyolult kérdés helyett - -c <conv-id> flag-gel ugyanazon conversation-on belül kérdezz vissza pontosítást - Retry másnap, ha az API-pattern visszaáll

4. `--mode deep --no-wait` aszinkron pattern (research bővítés)#

Pattern: a source add-research --mode deep --no-wait 5-30 perces aszinkron művelet. Indítás után NE blokkolj --import-all-ra — több párhuzamos research-rel a research wait timeout-ol (RPC client-side 30 sec).

Helyes munkamenet:

# Start aszinkron, NEM blokkoló
for query in "${QUERIES[@]}"; do
  notebooklm source add-research "$query" -n "$NB_ID" --mode deep --no-wait
  sleep 8
done

# Az importálás háttérben fut — folytasd más munkával
# Később (5-30 perc múlva):
notebooklm research status -n "$NB_ID"

# Csak ha végeztek, használd source list-tel az importált source-ok ellenőrzésére
notebooklm source list -n "$NB_ID"

Konkrét incidens: A research wait többször 502 / timeout-ot dobott a SV-research alatt. A háttér-import mindenképp lefutott — a source list időnként megerősíti.

4b. `research wait --import-all` párhuzamos = RPC timeout, sequential OK (2026-05-15)#

Probléma (2026-05-15 MFL-Voice research): 4 párhuzamos notebooklm research wait -n <NB> --import-all (egy-egy a 4 notebookra) mind IMPORT_RESEARCH timed out hibával exitelt — 30s RPC timeout × 6 retry (exponential backoff 5→10→20→40→60s), total ~225s, aztán Error: Request timed out.

MÉGIS partial import lefutott: a source list 12-36 URL-t mutatott per notebook (28 query × ~7-8 source / query közül 30-60%). A háttér-import mindenképp dolgozik, a wait --import-all csak a teljes set-re vár — és párhuzamosan ez túlfutaja a 30s RPC-budget-et.

Helyes pattern: - NE indíts 4 párhuzamos research wait --import-all-t — sequential a #7 multi-agent-batch-pattern szerint. - Vagy fogadd el a partial import-ot — 12-36 source bőven elég a strukturált ask-okhoz (#10 retry-prompt minta 800+ szavas válasszal jó eredményt ad). - Sequential research wait per notebook 60s timeout-tal:

for v in NB1 NB2 NB3 NB4; do
  timeout 60 notebooklm research wait -n "${!v}" --import-all || true
  sleep 5
done

- Cél: kiegészítse a partial import-ot a maradék source-szal — második körben már a teljes set ott van.

Reusable szabály: ha 4+ párhuzamos research-task egy account-on, vagy szekvenciális wait, vagy partial-import elfogadása — ne 30s RPC-timeout-ban várj 200+ source-ot.

5. Source-limit (NotebookLM Plus tier ~300/notebook)#

Tapasztalat (2026-05-12): a --mode deep import-all-lal 1 notebookba akár 1000+ source is bekerülhet (SV-2: 1009, SV-3: 737, SV-4: 921, SV-8: 1200) — a NotebookLM elfogadja, de a kérdés-fázis lassul, plus némelyik forrás error státuszban marad.

Tipp: Per-notebook 250 source hard-limit (manual prune oldest-first), vagy 3-4 notebookra szétosztott research ha 600+ source kell.

6. Audio overview generálás — több párhuzamos hívás OK#

Pattern: notebooklm generate audio -n <NB_ID> --format deep-dive --length long "<prompt>" aszinkron job. 8 párhuzamos hívás 2-2 mp delay-jel sikeresen futott (SV-1..SV-8 audio overview-k).

Letöltés:

notebooklm artifact poll -n <NB_ID> --type audio  # ellenőrzés
notebooklm download audio -n <NB_ID> --out ~/vault-audio/sv-1.mp3

Render-idő: ~10-15 perc/notebook a NotebookLM-Google-szerveren.

7. Multi-agent batch-pattern: szekvenciális > párhuzamos#

Anti-pattern (2026-05-12 reprodukálta): 8 párhuzamos sub-agent + mindegyikben source add-research + ask × 3 → rate-limit-tömeg (502 / Research failed to start), 6/8 batch-ben Q-fázis kimaradt, partial pipeline.

Helyes pattern: - Notebookokat előre létrehozni szekvenciálisan (NEM párhuzamosan, race-condition miatt — lásd #1) - Per-notebook sub-agent igen, párhuzamosan, DE limit 4-5 egyszerre (nem 8) - ask műveletek per-notebook szekvenciálisan (conversation-state miatt) 5-15 mp delay-jel - Retry-loop minden ask-ra (max 3-szor, exponential backoff) — üres Answer: detektálás után retry

Konkrét script-template: /tmp/sv-batch3.sh (re-runnable, hiányzó Q-kra fókuszál).

9. Batch-status-log autoritatív, ne a session-summary (audit-first retry)#

Probléma (2026-05-12 reprodukálta): Egy session Summary-jában „7 retry-pending Q" szerepelt. Az új session-ben naïve approach: 7 retry-API-call.

Helyes pattern — audit a status-log-on ELŐSZÖR:

# A batch-script lefutása logot ír:
cat /tmp/sv-research/batch3-status.log
# >>> SV-2 Q2 ... OK (92 lines)
# >>> SV-8 Q2 ... retry 3 (timeout)        ← TÉNYLEG failed
# >>> SV-6 Q3 ... (nincs itt — kihagyva)   ← TÉNYLEG nincs benne

Az audit kimutatta: 11/12 már korábban SIKERES (csak SV-8 Q2 timeout + SV-6 Q3 a script-ből kihagyott). A „7 retry-pending" Summary félrevezető volt — 10 felesleges API-call megspórolva.

Reusable szabály: minden batch-művelet után a *-status.log az igazságforrás. A session-Summary az emberi narratíva — pontatlanodhat napokon belül. Audit ELŐBB, retry UTÁNA.

10. 600-char marker-fallback retry-prompt minta (mélyebb mint #3)#

Probléma (lásd #3): a notebooklm ask esetenként a „longest unmarked text" fallbackbe esik (No marked answer found), output csak ~600 char, gyakran angolul. SV-6 Q3 érintett volt (csonkolt 3-tier-bontás).

Megoldás — strict prompt-format minimum word-count + langauge-lock + structure-mező-kényszerrel:

KRITIKUS FORMÁTUM: Hosszú strukturált válasz kell legalább 800 szó terjedelemben,
MAGYARUL, a forrásokra alapozva. Konkrét számokkal (token-cost/lekérdezés, dollár/hó).
NE 600 karakterben! Részletes 3-szintes elemzés.

Minden tier-nél:
- ROW1: <konkrét tartalom>
- ROW2: <kontraszt>
- ROW3: Forrás-citáció

SV-6 Q3 retry eredmény: 126 sor, 7632 char, clean marker-pattern, magyar 3-tier ($50/$200/$500) bontás. Reusable template: /tmp/sv-retry-sv6-q3.sh — más csonkolt-output retry-hoz adaptálható (subject + struct-fields cseréje).

Mit NEM elég: csak „részletes választ kérek" — a NotebookLM nem kényszeríti rá a struktúrát. Minimum word-count + explicit struktúra-mezők + language-lock mind a 3 kell.

11. Bulk projekt-sync rate-limit OK (Plus tier, sequential)#

Probléma (potenciális): 10+ NotebookLM-create + source-add chain rate-limit aggregálódással.

Mért 2026-05-13 (SV B-5 vault-nb-sync):

17 create-notebook + 44 source-add sequential
~25 perc wall-clock total
0 rate-limit error, 0 timeout
Per-projekt átlag: ~90 sec (create + 1-8 source-add)

Tanulság: Plus tier-en (NotebookLM Plus, $20/hó) sequential bulk-sync biztonságos ~50 művelet-ig egy chain-ben. Plus pattern: audit-first commit-mandatory flag elkerüli a "véletlen 17 NB" risk-et:

# audit-mód: csak report, no mutation
vault-nb-sync                       # default: AUDIT

# commit-mód: explicit user-action
vault-nb-sync --commit              # actually create + sync

NEM párhuzamos! Memóriabeli SV-research deep-research-tapasztalat (lásd #7 multi-agent batch-pattern): párhuzamos add-research 502-okat dob. Sequential 30-60 sec delay nélkül is működik a Plus tier-en, csak ne legyen 5+ concurrent connection.

Reusable use-case-ek: - Új vault-owner (Rob, future invitee) onboarding — 1 script-futtatás minden aktív projektre élő NB - Quarterly bulk-source-resync (új ADR-ek / Memory-fájlok mind frissen) - Bulk-archive (ha projekt archived → notebook source-remove batch)

8. Cross-vault contamination védelem#

Probléma: a NotebookLM-en több vault notebook-ja egyszerre nyitva (Peti + Rob potenciálisan). Cross-write-rizikó.

Megoldás: - Strict per-vault -n <NB_ID> enforcement (lásd #2) - Classifier mint last-resort (a Claude Code-auto-mode auto-block-ol más-notebook-write-ot) - Manual cleanup ha mégis kerül szennyező source (NotebookLM webes UI: source delete listából)

12. `ask` `Chat request timed out` ~30% random fail — retry ugyanazzal a prompt-tal átmegy (2026-05-15)#

Tünet (2026-05-15 MFL-Voice research batch): strukturált 800+ szavas HU prompt-okra a notebooklm ask -n <NB_ID> "<prompt>" ~30%-ban Error: Chat request timed out: üzenettel azonnal exitel. A response csak Different notebook specified, starting new conversation... Continuing conversation <id>... Error: Chat request timed out: (~127 byte).

Reprodukáló adatok: 22 ask × 4 notebook, első körben 15/22 OK, 7 timeout. Második kör ugyanazzal a prompt-tal: 6/7 átment. Harmadik kör a maradék 1-re átment. Konzisztens server-side overload-pattern, nem prompt-formátum hiba.

Helyes pattern:

# Detect timeout-fail = output-file < 1500 byte
ask_q() {
  local nb_id="$1" prompt="$2" outfile="$3"
  notebooklm ask -n "$nb_id" "$prompt" > "$outfile" 2>&1
  [ $(wc -c < "$outfile") -lt 1500 ] && return 1
  return 0
}
# Retry-loop max 3-szor, 20s sleep közte
for try in 1 2 3; do
  ask_q "$NB" "$Q" "$OUT" && break
  sleep 20
done

Audit-first (per #9): minden batch után a kis-file-okat azonosítani (< 1500 byte), majd csak azokra retry. NE a teljes batch-et — a sikeres ask-ok valószínű elsőre is jók.

13. `download audio --out` flag deprecated (CLI v0.3.4, 2026-05-15)#

Tünet: korábbi munkafolyamatok notebooklm download audio -n <NB_ID> --out <path> szintaxisa most:

Error: No such option: --out

Helyes szintaxis (v0.3.4):

notebooklm download audio -n "$NB_ID" "/path/to/output.mp3"
# OUTPUT_PATH most positional argumentum

Plus a notebooklm artifact poll szintaxis is változott: - ❌ notebooklm artifact poll -n <NB_ID> --type audio - ✅ notebooklm artifact poll <TASK_ID> -n <NB_ID>

Az audio generate parancs visszaadja a Started: <TASK_ID> UUID-t — azt kell tárolni és pollolni. Nem notebook-szinten kérdezhető le.

14. `download report` szintaxis — pozicionális output-path, NEM `-o` flag (2026-05-19)#

Tünet:

notebooklm download report -a 5f282621 -o /target/report.md
# Error: No such option: -o

Helyes:

notebooklm download report -a 5f282621 /target/report.md
# OUTPUT_PATH pozicionális argumentum (akárcsak download audio óta v0.3.4)

Konzisztens a download audio 2026-05-15-i változással (lásd #13).

15. `research wait --import-all` az ÖSSZES running research-re vár (2026-05-19)#

source add-research <q> --mode deep --no-wait többször hívható egymás után — queue-szerűen feláll. A notebooklm research wait --import-all aztán mindre vár (NEM csak az utolsóra) és import-álja a source-okat.

A notebooklm research status csak az utolsó (vagy current) task-ot mutatja — a többit egyenesen csak a wait látja.

16. `artifact wait --timeout 600` — default 60s sokszor kevés (2026-05-19)#

Custom report-artifact generation 5-10 perc deep research-output-on. A notebooklm artifact wait <id> default --timeout 60 simán lefut anélkül hogy befejezte volna a generálás. Mindig --timeout 600 minimum custom report-okra.

Kapcsolódó#

11-wiki/notebooklm-headless-login-fifo — auth-pattern (foundation)
11-wiki/notebooklm-seo-competitor-research-pattern — 17×7 workflow
11-wiki/notebooklm-deep-research-custom-report — Deep Research + custom report-flow
11-wiki/sv-08-notebooklm-cognitive-layer — research-cikk a NotebookLM cognitive-layer-paradigmaról
07-Decisions/2026-05-12 sv-8 notebooklm cognitive layer arch — Phase B-5 sprint ADR (vault-nb-sync + crystallize-hook + commute-podcast)

11. Audio-overview bitrate gotcha (2026-05-19)#

Tünet: NotebookLM generate audio --format deep-dive --length long 2-host conversational podcast ÉLES (Alex+Jordan EN dialogue) — sokkal élvezhetőbb mint a Gemini-3.1 Flash TTS 1-voice TL;DR narrátor. DE: a downloaded MP3 ~1200 kbps AAC, ~45 MB egy 5-perces audio-ra. 3 podcast = 121 MB total.

Megoldás (ffmpeg re-encode):

ffmpeg -i input.mp3 -b:a 96k -ac 2 -ar 44100 output-96k.mp3
# 45 MB → 4-5 MB, ~10× kisebb, voice-quality alig csökken

Reusable szabály: minden NotebookLM-downloaded audio-on ffmpeg -b:a 96k re-encode pipeline — public-repo bundle size kritikus a CDN-cost + mobile-bandwidth-on. NEM raw download.

Plus HU dubbing gap: NotebookLM CLI csak EN audio-t generál. HU-first audience-nek subtitle (Whisper-transcribe → translate) + TTS-overlay combo pareto-jobb a két nyelvi sávra.

2026-05-20 — Subagent-handoff fail-recovery#

A NotebookLM deep-research-flow gyakran hosszú (15-30 min queries × 4 parallel = ~30-60 min). Ha a háttér-orchestrator-subagent fail-el (pl. API 529 Overloaded), a long-running munka megőrződik a server-side-on — a recovery NEM az újraindítás, hanem a main-thread takeover.

Pattern#

Subagent indítja:
  notebooklm source add-research "Query 1" --mode deep --no-wait → task_id_1
  notebooklm source add-research "Query 2" --mode deep --no-wait → task_id_2
  ...
  notebooklm research wait --import-all  → CRASH (API 529)

Main-thread recovery:
  notebooklm research status              → tasks already done
  notebooklm source list                  → 612 sources imported
  notebooklm ask "..."                    → Q&A directly, no re-research needed

Wider lesson#

A NotebookLM-cluster-state szerver-oldali, az orchestrator-subagent CSAK koordinálja. Ha a subagent fail-el, a NotebookLM-corpus megmarad — a recovery a source list + ask direkt-hívásokkal történik a main-thread-en, NEM a teljes flow újraindításával.

Hasonló pattern minden long-running, server-side-state-tartó task-nál (Higgins job-status, GEPA-optimization-runs, big-batch-ingest-jobok).

Empirikus eredmény#

A 2026-05-20-i TikTok-stratégia deep-research subagent API 529 Overloaded-szel fail-elt ~15 min-re a 90 min-budget-éből. A main-thread takeover (notebooklm ask direkt-hívásokkal) 30 sec alatt készre vitte a 8-question Q&A-t, és a magyar briefing megíródott. Recovery-window: NEM kell újraindítani a 30-60 min-es research-task-ot.

Source-of-truth: ../06-Audits/2026-05-20 TikTok-strategy deep-research briefing — a magyar briefing main-thread-recovery után készült.