Capabilities
Stateful Conversations
Provider-managed conversation state via stored sessions
Read this when
- Building long-running agents
- Reducing per-turn payload size
OpenAI’s Responses API and Google’s Interactions API can persist conversation state server-side; the client passes a previous_response_id (OpenAI) or session reference rather than re-sending the entire history each turn.
Compatibility
| Provider | API | pi-go | Notes |
|---|---|---|---|
| Anthropic | ❌ stateless (history is client-managed) | — | |
| OpenAI Chat | ❌ stateless | — | |
| OpenAI Responses | ✅ Conversations API; store: true, previous_response_id | ❌ | pi-go forces store: false (openairesponses.go:303) |
| Google Gemini | ✅ Interactions API | ❌ | not wired |
| Claude CLI | ✅ session JSONL in ~/.claude/projects/ | ❌ | each pi-go call spawns a fresh subprocess (claude.go:5-8); only last user message replayed |
| Codex CLI | ✅ thread resume via codex exec resume | ✅ agent / ❌ provider | pkg/agent/codex captures thread.started and resumes subsequent sends; pkg/ai/provider/codexcli remains stateless and uses --ephemeral |
Provider Documentation
pi-go Gaps
- pi-go’s design replays full message history each turn — works everywhere but forfeits cost/latency wins from server-side state.
- No
SessionStoreabstraction. - Claude CLI’s
--resume/--session-idnot wired, so multi-turn agents lose conversation history between calls.