The February 5, 2026 Letta Office Hours episode covers Claude Opus 4.6, benchmark cost, model-provider setup in Letta Code, Lettabot, subagent coordination, and memory beyond retrieval. Cameron's recurring question is operational: how well does a model perform once tool use, token cost, provider behavior, retained state, and deployment are included?
This guide is part of the Letta Office Hours archive. It records the product and design discussion from that date; current behavior belongs in the Letta documentation.
Selected chapters
- 00:04:00 Opus 4.6 lands in Letta's model lineup
- 00:05:00 Agents can fork themselves or reuse existing agents
- 00:06:00 File system benchmark results and cost tradeoffs
- 00:07:30 Skills benchmark comparison across models
- 00:11:30 Expanded
/connectflow in Letta Code - 00:12:30 Project-level LLM key management and BYOK setup
- 00:17:30 What Lettabot is and how it is deployed
- 00:18:30 Lettabot architecture and remote agent access
- 00:31:00 Skills and autonomous workflows from email to RSS
- 01:18:00 Letta Cowork and the broader product direction
- 01:43:00 Why Letta emphasizes state over retrieval-only RAG
- 01:47:30 Closing reflections on feedback and weekly office hours
Benchmarks include tool and token cost
Opus 4.6 is the episode's headline model update. Cameron says Letta had prepared Cloud support and uses the release to discuss two internal evaluations: a file-system benchmark and a skills benchmark.
The file-system result places Opus 4.6 slightly ahead of GPT-5.2 in the recorded comparison. Cameron also examines how many tool calls, file reads, and tokens each model used. A higher score can cost more to obtain, which changes the economics of an agent that works for many turns.
The skills benchmark makes a related point. Model choice depends on the task and on the provider path serving the model. A model that performs well through one integration may become less reliable when another provider changes its tool schema, context handling, or upstream routing.
Letta Code exposes provider setup
The expanded /connect flow supports bring-your-own-key connections for OpenAI, Anthropic, Google Gemini, MiniMax, OpenRouter, Bedrock, and enterprise configurations discussed in the episode. Project-level key management makes the active provider visible in the product instead of leaving it entirely in external configuration.
This setup lets one agent use different model backends without moving its memory and identity into each provider's chat product. Behavior still varies by model and provider; portability preserves the surrounding state, not identical results.
Lettabot hosts an agent behind messaging channels
Lettabot is presented as a server-hosted Letta Code deployment available through Docker or a Railway template. Messaging channels connect users to the remote agent, while the server retains the agent process and its working environment.
Cameron demonstrates a personal agent editing Obsidian notes, transcribing voice memos, and searching conversation history. Other examples use skills for recurring email briefings and RSS digests. These tasks combine retained context, tools, schedules, and a channel through which the result returns.
Subagents divide work without erasing identity
Letta agents can fork themselves, invoke an existing agent by ID, or delegate to specialized subagents. A coding agent might send exploration to a faster worker and retain the main conversation for synthesis and decisions.
Delegation introduces ownership questions. Each worker needs a defined task and context, and the coordinating agent needs enough evidence to interpret the result. Shared names or memory do not make separate runs one execution history.
Memory includes behavior and retained state
Audience questions compare retrieval-augmented generation, agentic search, memory, and long context windows. Cameron treats retrieval as one mechanism inside a larger stateful system. Search can find a relevant file, while memory also includes the retained records and procedures that shape later behavior.
The distinction explains why the episode connects provider setup, Lettabot, skills, and subagents. Models supply inference. The agent system supplies continuity, tools, execution, and ways to revise what later turns can use.
Product surfaces share one stateful architecture
The episode places Letta Code, Lettabot, Letta Cowork, and the Agent SDK around the same persistent-agent model. They serve different interfaces and deployment settings. Their common requirement is that an agent can be reached again with retained state and a known tool environment.
Cameron closes by asking which topics viewers want explored in later sessions. The product set was broad and still changing. This page therefore preserves the architecture discussed on February 5 rather than treating every named product or model path as current.