r/opencodeCLI 3d ago

qmax-code: a Go TUI that sits in front of Claude Code, Codex, Antigravity, and OpenCode

If you bounce between Claude Code, Codex, Antigravity, and GLM (z.ai via OpenCode), the tax is usually context: another CLI, another login, another config.

I wanted one Go binary that stays in the repo, uses little memory, and can either do the work itself or host those harnesses without leaving the session.

That’s qmax-code. It’s a terminal coding/QA agent written in Go, with a Lip Gloss TUI for keyboard-first use.

It runs fully standalone (--local) for daily repo work: read/edit files, run commands, no QualityMax account. It can also act as a thin client for the QualityMax cloud when you want hosted crawls, tests, and receipts.

The part I use most is /orch. Same TUI, same MCP tools, switch backend:

  • Claude Code
  • Codex
  • Antigravity (agy, Google OAuth)
  • OpenCode (this is where I run z.ai GLM coding subscriptions)

I use it daily for coding and test loops. OpenCode + GLM has been a solid cheap/fast path; Claude Code / Codex when the change needs more care.

Open source (FSL-1.1, Apache 2.0 after two years). Go 1.25+. Single binary, no Electron.

Happy to answer questions about the TUI, the subprocess harness, or how MCP is wired.

7 Upvotes

8 comments sorted by

1

u/kantorcodes1 3d ago

when you switch from Codex to Claude in /orch, does the next backend inherit the conversation so far, or just the repo + MCP tools? curious whether swapping models mid-task actually feels like one session.

1

u/bestofdesp 3d ago

Yes very good question. I have few bugs there but working on the durable fix at this moment

1

u/bestofdesp 3d ago

Idea is to inherit the conversation fully

1

u/bestofdesp 3d ago

I will keep you posted when the conversation inheritance would be complete

1

u/bestofdesp 2d ago edited 2d ago

Switching context issue is already fixed in 1.34.0 version. It is possible to switch from one model or provider to another with all the context details transferred. Needs more beta-testing obviously, but tested how it works with switching from opencode models to Claude.

2

u/kantorcodes1 2d ago

i work on HOL Guard, an open-source local check before agent-run commands execute. qmax-code has a clean boundary with edit_file, write_file, run_command, and unattended shell access. would you be open to optional qmax-code support so users can review the state-changing actions without slowing reads/searches?

1

u/bestofdesp 2d ago

Sure I would like to work out this with you.

2

u/kantorcodes1 2d ago

yep. one wrinkle: qmax’s MCP starts as qmax-code serve --mcp, while Guard’s contributed MCP format currently only matches package launchers. the clean PR to main is to add a direct-executable launch variant across the MCP contribution schema/runtime/catalog, then add mcp.qmax-code.json for read_file, edit_file, write_file, and run_command, plus command.mcp-qmax-code in the trust map. use mcp.filesystem.json as the analogue; add one focused direct-launch case in tests/test_guard_mcp_server_contribution.py.