CluxMate

AI coding agent with one Python core and three front-ends — headless CLI, Textual TUI, and an Electron desktop. Works with any OpenAI-compatible API, with risk-…

LLM Mart
3 views 89 listing impressions

CluxMate

An AI coding agent — one Python core, three front-ends.

Python License Platform

English · 中文文档


What is CluxMate?

CluxMate is an AI coding agent that reads your codebase, plans changes, edits files, runs commands, and answers questions. A single Python core powers three interchangeable front-ends:

Front-end What you get
Headless CLI One-shot prompts for scripts, CI, and automation (cluxmate -p "...")
Textual TUI A full interactive terminal UI (cluxmate)
Electron desktop A polished GUI that drives the same core over JSON-RPC (stdio)

It speaks the OpenAI-compatible API, so it works with DeepSeek, Qwen, GLM, OpenAI, OpenRouter, Ollama, or any self-hosted endpoint using the same protocol — just point it at a base_url. No vendor lock-in.

Screenshots

CluxMate Textual TUI CluxMate Desktop

Highlights

  • One core, three front-ends — the headless CLI, the REPL, the Textual TUI, and the Electron desktop all drive the exact same agent loop. The desktop app is a shell around that core; the Python agent remains fully usable on its own.
  • No vendor lock-in — speaks any OpenAI-compatible API: DeepSeek, Qwen, GLM, OpenAI, OpenRouter, or a self-hosted endpoint. Configure multiple models and switch on the fly; provider failures never crash a turn, because timeouts, API errors, and network failures are translated into graceful, user-visible messages.
  • Event-sourced sessions, fully traceable — every session is an append-only event log; the model's message history is derived from it, never stored separately. Every turn of every agent — main and subagents — is bracketed by turn/start/turn/end, every step logs step/start, request/header, and tool results, so the exact prompt sent at any step can be reconstructed and replayed verbatim, and context compaction rewrites a summary region without erasing the underlying events. See Sessions you can replay below.
  • Stable, cache-friendly context — the system prompt never changes with your session: memory, skills, and mode are injected as tagged synthetic messages, so request prefixes stay stable and prompt caches stay hot — with per-turn cache-hit and latency metrics surfaced in the UI.
  • Risk-tiered permissions — every tool declares a risk level (safe / write / dangerous / critical); four modes (plan / default / acceptEdits / yolo) plus two persistent always-allow lists (write tier + dangerous tier — delete_file, and bash per category like bash:rm / bash:python / bash:run, never whole-tool) control approval. Running code (python script.py, node app.js, npm run, ./x.sh, …) is dangerous, not safe. plan mode is read-only by construction; dangerous commands prompt unless explicitly always-allowed, and critical commands (format/mkfs/dd, etc.) and sandbox escalation always prompt.
  • A two-layer sandbox — file write/delete tools are guarded by an in-process WriteFence (canonicalize-then-contain), and model-generated bash commands run inside an OS-level sandbox (Windows Low-integrity token, Linux bubblewrap, macOS Seatbelt). Sandboxing is fail-closed and only yolo mode — the explicit opt-out — disarms it. An opt-in read denylist hides secrets (.env, *.pem, ~/.ssh, …) from the model and from shell/MCP subprocesses. See Security: sandbox.
  • Network-access guard (SSRF)web_fetch / web_search pass through an SSRF guard in every mode (including yolo): internal/private addresses (RFC1918,

From the project's README.

Comments (0)

Sign in to join the conversation.

No comments yet.

Related tools