feat(livekit): persist latest model id on tasks

[wsxiaoys]

Please describe the feature you want

Tasks persisted in LiveStore do not record the LLM model id used for the most recent run. The tasks table schema currently includes status, todos, git metadata, and token counts but lacks any model identifier (packages/livekit/src/livestore/schema.ts#L60-L82). When a chat stream starts, LiveChatKit.onStart already has access to the llm instance returned by FlexibleChatTransport (packages/livekit/src/chat/flexible-chat-transport.ts#L91-L143), but it omits the model id when committing v1.ChatStreamStarted (packages/livekit/src/chat/live-chat-kit.ts#L216-L263). Because the RequestData[\"llm\"] discriminated union keeps the selected modelId for every first-party provider (packages/livekit/src/types.ts#L33-L102), we can persist that value so downstream consumers know which model produced the result.

Without this information, VS Code surfaces built atop the task snapshot—such as the chat toolbar and task history—cannot display which model generated the assistant response, and the CLI cannot audit changes after a model switch (packages/vscode-webui/src/features/chat/lib/use-live-chat-kit-getters.ts#L20-L166). Storing the latest model id directly on the task would make the data available everywhere we hydrate a Task.

Proposed approach

• Extend the v1.ChatStreamStarted event schema and tables.tasks definition to include an optional modelId string that always reflects the latest stream (packages/livekit/src/livestore/schema.ts#L133-L218).
• Capture llm.modelId (when present) inside LiveChatKit.onStart and pass it through the new event field before committing to the store (packages/livekit/src/chat/live-chat-kit.ts#L239-L263). For vendor-backed LLMs that do not expose a modelId, store null and document the limitation.
• Update the SQLite materializer to persist the field, and surface the property on the exported Task type so both the CLI and VS Code web UI can render it.
• Optionally surface the field in the chat toolbar next to the model picker or in task summaries so operators can confirm which model generated each response.

Additional context

graph TD
    ModelPicker[VS Code model picker] -->|LLMRequestData| Getters
    Getters --> FlexibleChatTransport
    FlexibleChatTransport -->|getLLM| LiveChatKit
    LiveChatKit -->|commit v1.ChatStreamStarted| LiveStore[(tasks table)]
    LiveStore --> TaskConsumers[CLI & web UI task views]

Loading

Open questions:

• Should we also persist the model id on v1.TaskInited when spawning subtasks so the parent task inherits the initial selection?
• Do we want to track historical model ids per message, or is “latest per task” sufficient for the current auditing needs?

🤖 Generated with Pochi

[wsxiaoys]

also related to #226