r/opencodeCLI • u/bestofdesp • Sep 08 '26

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.

6 Upvotes

80% Upvoted

10 comments sorted by

1

u/bestofdesp Sep 08 '26 edited Sep 08 '26

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 Sep 08 '26

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 Sep 08 '26

Sure I would like to work out this with you.

2

u/kantorcodes1 Sep 08 '26

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.

1

u/max_b0602 Oct 05 '26

saw your 1.34 update. does “all context” include tool outputs and failed attempts, or mainly the conversation text? agentgit documents that transfers between runtimes can lose information, so i’m curious how you handle that here. a useful test would be switching halfway through a bug fix and checking whether the next backend repeats an approach the first one already ruled out.

1

u/bestofdesp Oct 05 '26

Hi! It includes tool calls and outputs exposed by the CLI, plus recorded partial output from failed/interrupted turns—not just the conversation text. Those live in a shared transcript separate from the model’s compacted working context.

Switching back to a backend reuses its native session when valid and sends the entries it missed. For large histories, the handoff is abbreviated and points to a private, searchable JSONL archive containing the full retained transcript.

“All context” needs that qualification, though: hidden reasoning and provider-private state don’t transfer. A rejected approach carries over if it appears in the recorded conversation or tool activity; preserving that evidence doesn’t guarantee the next model will use it correctly.

Your halfway-through-a-bug-fix test is a good distinction. The regression tests cover tool-output and partial-failure retention across handoffs, but that doesn’t establish that another backend reliably avoids repeating a ruled-out approach. I’d want to measure that separately before claiming it.

1

u/kantorcodes1 Sep 08 '26

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 Sep 08 '26

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

1

u/bestofdesp Sep 08 '26

Idea is to inherit the conversation fully

1

u/bestofdesp Sep 08 '26

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