fix: move off the LLM context frames pipecat removed in 1.8
MossIndexProcessor cannot be imported on any current pipecat:
ImportError: cannot import name 'LLMMessagesFrame' from 'pipecat.frames.frames'
ModuleNotFoundError: No module named 'pipecat.processors.aggregators.openai_llm_context'
pipecat-ai 1.8 removed LLMMessagesFrame, and removed OpenAILLMContext, OpenAILLMContextFrame and the whole openai_llm_context module with it (#4215). LLMContextFrame and LLMContext are the replacements, and all services use the universal LLMContext now.
The dependency allows pipecat-ai>=0.0.99 with no upper bound, so a fresh install resolves to 1.11 and the processor fails at import.
What changed
The two dead branches are removed rather than ported. Nothing can emit a frame type that no longer exists, so isinstance(frame, LLMMessagesFrame) and the OpenAILLMContextFrame arm were unreachable code that only existed to fail at import time. What remains is the LLMContextFrame path, which is what pipecat sends now.
The augmented frame is forwarded as it arrived, instead of being rebuilt. The old code pushed type(frame)(context=context). Since context is the same object the frame arrived with and the retrieval augments it in place, rebuilding was never necessary — and it dropped every other field on the frame. speculation is the one that matters: it marks an inference run from a provisional context whose response must not reach the user and whose tool calls must not execute. A speculative frame rebuilt this way arrives at the service looking like an ordinary turn.
pipecat-ai floor raised to 1.8, the first release with LLMContextFrame. The old floor cannot satisfy this code, and the old code cannot run on anything current, so the range had to move one way or the other.
Verified
On a clean environment against pipecat-ai 1.11.0: the module imports, LLMContextFrame(context=..., speculation=True) keeps its speculation through the processor, and _get_latest_user_text still finds the latest user turn from LLMContext.get_messages(). Both removed names are confirmed absent on that version, which is what makes the current import fail.
Separately — one more thing blocking the package
Unrelated to pipecat, and not fixed here because it is yours to decide: pipecat_moss/__init__.py imports AddDocumentsOptions from inferedge_moss, and the current inferedge_moss on PyPI does not export it (it has GetDocumentsOptions). So even with this PR, import pipecat_moss raises:
ImportError: cannot import name 'AddDocumentsOptions' from 'inferedge_moss'
Happy to send a second PR for that once you say which side should move — the plugin's import or the SDK's export.
Found with a checker I run nightly over every community plugin listed in the Pipecat docs, against the latest release and against main: https://github.com/Rehansanjay/pipecat-plugin-health