Deployment Bases¶
G6 components are exposed through deployment bases — server implementations that make G6 accessible via different protocols.
Hosted product vs. repository surfaces
G6 is hosted. You reach it over MCP by pointing Claude Code (or any MCP client) at G6Solver's server — see Setup for the current connect string. There is no downloadable desktop binary, no local engine, and no self-hosted deployment; the LICENSE grants access solely through the hosted service.
The pages below document surfaces that exist in the repository — TUI, GUI, REST, gRPC, SOAP, Erlang and the desktop wrapper. They are engineering reference, not customer instructions: the REST route is closed at the edge, and the others are not part of the hosted product today.
Launch Status¶
| Surface | Status | Description |
|---|---|---|
| MCP Server | Production | Primary Claude Code integration |
| REST API | Not in the hosted product | Closed at the edge; repository reference only |
| Web Portal | Production | Account, billing, docs, status |
| CLI (TUI) | Beta | Local interactive interface |
| GUI | Beta | Browser-based desktop workbench |
| Desktop | Beta | Packaged binary application |
| gRPC | Experimental | High-performance RPC (deferred) |
| SOAP | Experimental | Legacy XML services (deferred) |
| Erlang | Experimental | Distributed systems (deferred) |
Recommended start
For production use, start with MCP (for Claude Code), REST (for programmatic access), or Web (for browser-based management). See the Workflows section for guided paths.
Production Interfaces¶
MCP Server¶
The primary integration point for Claude Code users. Provides 262 tools across 15 categories.
REST API¶
Programmatic HTTP access for developers building on G6. 91 endpoints across 16 route modules covering all MCP capabilities plus operational monitoring, safety, deployment, and task management.
Beta Interfaces¶
Beta
These interfaces are functional and useful for development/testing, but are not the recommended production surfaces. They may change without notice.
CLI (TUI)¶
Local interactive interface with an 11-tab Textual TUI. Full orchestration via RecursiveArchitectBlock with HITL management, LLM chat, task tracking, and solver flywheel.
CLI Documentation CLI Commands REPL
GUI¶
Browser-based desktop workbench with 8 views: dashboard, artifact inspector, goal tree, reasoning flow, HITL approvals, chat, learning, and settings.
GUI Documentation GUI API Reference
Desktop¶
Pre-built binary bundling the browser GUI, 11-tab TUI, embedded MCP server, Stripe licensing, and auto-updates. The "ship to users" artifact.
Surfaces at a Glance¶
| Surface | Access | Orchestration | Tools / Endpoints | Key Features |
|---|---|---|---|---|
| TUI (CLI) | Terminal | Full RecursiveArchitectBlock | 11 tabs | HITL, play/pause/stop, LLM chat, task tracker, flywheel |
| REPL | Terminal | Via LLM agentic chat | 10 tools | Cross-session memory, tool-calling |
| GUI | Browser | Full (via GUI API) | 8 views | Run CRUD, HITL, chat, learning, diagnostics |
| MCP | AI assistants | None (component-level) | 262 tools | For Claude Code, Cursor, etc. |
| REST | HTTP clients | None (component-level) | 91 endpoints | Swagger UI, Prometheus metrics, WebSocket |
| Desktop | Binary | Full (GUI/TUI) + MCP | All surfaces | + licensing + auto-update |
TUI and Desktop run the full orchestration loop — the RecursiveArchitectBlock decomposes goals into a search tree and executes branches with safety checks, HITL gates, and self-healing. MCP and REST provide direct component-level access without orchestration — the calling client (or LLM) manages the workflow. REST also exposes a /ws/pipeline WebSocket for streaming pipeline events.
Adaptive Tiers (T0--T3)¶
G6 implements the practopoiesis framework — nested layers of adaptation where each tier creates conditions for the next. All four tiers are accessible through every surface.
| Tier | Capability | Key Components | How to Engage |
|---|---|---|---|
| T0 | Fixed tool-calling | Any component via invoke | Default — no setup needed |
| T1 | Audit + diagnose | self_training, align_evals | invoke self_training {op: audit} |
| T2 | Continuous improvement | evoskill, adapt_optimisation | invoke evoskill {op: evolve} |
| T3 | Theory building | formal_methods, meta_programming, align_specs | invoke formal_methods {op: verify} |
- T0 is the baseline: invoke any component, get a result. No learning.
- T1 adds single-pass adaptation: the self-training loop audits component quality, diagnoses failures, and proposes fixes. Rules are fixed; parameters are learned.
- T2 adds continuous adaptation: EvoSkill evolves new skills, maintains a Pareto frontier, and feeds improvements back into the system. The learning rules themselves are now tunable.
- T3 adds meta-learning: formal verification, symbolic reasoning, and structured theory building. The system learns how to learn — constructing models that explain why certain approaches work.
TierManager¶
The tier_manager component provides unified control over T0-T3 tiers across all surfaces:
| Surface | How to access |
|---|---|
| MCP | tier_get_status, tier_propose_advance, tier_confirm_advance, tier_reject_advance, tier_cap |
| REST | GET /tier/status, POST /tier/advance, POST /tier/cap |
| TUI | Press t for tier popup; tier indicator in status bar |
Tier advancement requires explicit user confirmation — the system never auto-advances. State is persisted to an Obsidian vault with wikilinks and human-readable markdown history.
See Tier Manager component reference for full details.
Experimental Integrations¶
Experimental — Not part of v1 launch scope
These bases are available for advanced use and evaluation. They are not supported for production deployments and may be removed or significantly changed. For production, use MCP, REST, or Web.