With the dynamic schedule a captured call took 10 to 20 minutes to become
memories, so a caller who rang back right away was not recalled. Capture
now defaults to dreaming="instant": on LiveKit Cloud a call's content was
recallable 19 seconds after it ended, and the callback answered from it.
Each capture write bills one extra operation. When the organization has
no balance for instant processing (HTTP 402), capture and remember fall
back to the dynamic schedule for the rest of the call instead of failing.
capture_dreaming="dynamic" keeps the old behaviour.
From review of 5b2a435e:
- Captured turns now keep the container tag and document id they were
spoken under. Rebinding the instance used to flush earlier turns into
the new caller's scope. Turns captured before any bind still go to the
first caller bound.
- Recall strips earlier injected memory before it runs, so a failed or
empty recall can no longer leave another caller's memory in context.
For the same caller, a slow or failed recall falls back to the profile
loaded by preload.
- The recall cache is keyed on the user message, not its text, so a
later turn with the same words recalls again.
- Capture writes time out after 10s and keep their turns for retry,
including on cancellation. Large calls are written in chunks of at
most 100k characters, and the buffer is capped.
- remember falls back to the default processing schedule when the
organization has no balance for instant processing (HTTP 402).
- Docs state the measured delays: about a minute for remember, 10 to 20
minutes for captured calls on the default dynamic schedule.
examples/voice_agent.py runs in console mode or joins LiveKit rooms. It
scopes memory from dispatch metadata, SUPERMEMORY_CONTAINER_TAG, or the
participant, preloads the caller's profile, and greets returning callers
by name. Tested on LiveKit Cloud: a second call greeted the caller by name
and used a fact from the first call.
The example is not included in the wheel or sdist.
