Skip to content

Looking at the source material against the current Hoshi page, I can see several areas where the documentation has drifted from the current implementation:

  1. The current page doesn't mention the dual-engine architecture with Gemini as primary and Legacy as fallback
  2. Missing details about the Brain Adapter system and swappable engines
  3. Tool count is outdated (page says 56 MCP + 6 local, but doesn't break down the MCP tools properly)
  4. Missing information about the MCP sidecar architecture
  5. Context assembly details are incomplete
  6. Missing information about message persistence and cost tracking

Here's the updated page:

Hoshi

Hoshi is Sidespace's built-in AI assistant. It lives in the right panel and serves as the primary interface between you and your projects -- answering questions, executing multi-step workflows, and keeping project state in sync as you work.

Most AI coding tools give you a chat window and leave you to copy-paste context in. Hoshi is different: it has direct access to your project graph, memory bank, and research pipeline. When you ask it to create a feature, it writes to the database. When the research agent finds something relevant, Hoshi surfaces it proactively. The assistant is wired into the system, not bolted on.

What's Built

Dual-Engine Architecture

Hoshi's brain is swappable between two engines via a feature flag (hoshi_engine):

EngineModelRole
gemini (primary)Gemini 3.1 ProProduction brain with streaming, tool loops, and rate limit retry
legacy (fallback)Claude Sonnet via RustOriginal implementation, preserved as fallback

The BrainAdapter interface provides a provider-agnostic contract that each engine implements. Key components:

ComponentPurpose
Gemini adapterNative streaming, multi-turn tool loops, 30s/60s retry on rate limits
Legacy adapterDelegates to Rust-side agentChat() command
Hoshi bridgeOrchestrator for initialization, context assembly, persistence, and post-chat effects
Model registrySingle source of truth for model names, pricing, token limits, and validation

Tool System

Hoshi operates through 56 MCP tools (served by the Sidespace MCP sidecar) plus 6 local Tauri commands for native OS operations:

CategoryCountExamples
Roadmap13Create/edit features, move horizons, link documentation
Project & orchestration~25Tasks, notes, todos, project settings, research triggers
Information7Search memories, list projects, list documents
Theme6Create/edit themes, merge themes, assign to features
Ideas5Create ideas, promote to features, delete ideas

The MCP sidecar compiles to a native binary that provides a shared tool surface -- Hoshi, Umbra, Kosmos, and Claude Code in Squad View all use the same tools through the same server.

When mutating tools execute, they emit Tauri events. React Query hooks listen for these events and invalidate relevant cache entries, ensuring the UI updates immediately without polling.

Conversations & Context

Chat history persists as one continuous thread per user in hoshi_messages with a content_blocks JSONB column that preserves multi-turn tool conversations. Both messages and associated costs are tracked in the database.

The context window is token-budgeted to ~8,000 tokens. On each turn, the system loads recent messages within that budget, then layers in:

  • Research briefings -- unsurfaced findings from the research pipeline, injected as [RESEARCH BRIEFING] blocks
  • Memories -- relevant entries from the knowledge bank, retrieved by vector search for semantic relevance
  • Project context -- active project metadata, linked documents, current task state

Cost Tracking

Both engines track token usage and costs, persisting them to the database for budget monitoring and usage analysis across conversations.

Where It's Heading

Near-term work focuses on expanding Hoshi's autonomy -- longer tool chains, better cost controls, and tighter integration with Squad View so Hoshi can coordinate the agents running in terminals rather than just chatting alongside them.