MTGA and the local proxy that redirects an IDE's model traffic

The problem is a locked provider list, not a missing model

MTGA exists to work around the fact that an IDE can only use the model providers its vendor allows. The project describes itself in Chinese as a local proxy based solution for that fixed provider restriction, applicable on Windows and macOS, and the acronym is expanded in a deliberately hidden line in the README as Make Trae Great Again, so the target IDE is Trae.

The audience is narrow and specific: a developer working in Trae who has an API endpoint for a different provider, or a self-hosted one, and cannot enter it through the IDE's own model picker. The tool does not add model capability to the IDE. It makes the IDE believe it is talking to the endpoint it already knows how to talk to, while the local proxy forwards the request wherever the user actually configured it.

That framing matters for the rest of the review, because every significant detail of this project follows from it. The certificate, the hosts file, the port 443 requirement and the OpenAI compatible configuration steps are not incidental implementation choices. They are the mechanism, and they carry the security trade-offs that come with it.

A hosts entry, a generated certificate and a listener on 443

The startup sequence is described in the README and it is worth reading closely, because it explains how the interception works. After you add a proxy configuration group and fill in the global configuration, one button starts everything, and on macOS that button needs administrator rights. The program then automatically generates and installs a certificate, modifies the hosts file and starts the proxy server.

The hosts modification is the visible part. The troubleshooting section tells you to make sure the hosts file contains the line 127.0.0.1 api.openai.com, uncommented, which redirects the IDE's request to the loopback address where the local proxy is listening. The certificate is the invisible part: the proxy terminates TLS for a domain the IDE believes is api.openai.com, so the certificate has to be trusted by the operating system or the IDE refuses to connect. That is why the README tells you to check that the CA certificate is installed in the trusted root certificate authorities, and why the advanced troubleshooting path includes a toggle for disabling strict SSL mode.

The consequence for a reviewer is that MTGA behaves like a man in the middle on your own machine. It has to be, given the goal, and the price is a root certificate in your trust store and a hosts file that other software on the machine now resolves differently.

From v2.6.0 the downstream side is always Chat Completions

The architecture note in the README is the most useful technical passage in the project. From v2.6.0, MTGA exposes the OpenAI Chat Completions API uniformly to whatever is downstream, and the backend forwards through the built-in MLiteLLM execution layer to upstream providers including openai_chat_completion, openai_response, Anthropic and Gemini, with no need to install a third party forwarding framework. The upstream type is chosen explicitly through the provider field in the configuration group, and openai_response is handled by MTGA itself, which converts between the chat completions shape and the responses shape inside the proxy layer.

That conversion is the piece an adopter should think about hardest, because it happens on the wire, in the middle, without the upstream model knowing. A request that your provider expects in its responses format arrives in the chat completions format because the IDE speaks that dialect, and MTGA translates. The project points to docs/provider-support.md for the limits, which is the right document to read before relying on a specific provider, and the README itself is explicit that not every provider will behave identically.

The other notable piece of the configuration flow is model name mapping. To enable multimodal behaviour you map your model name onto a built-in multimodal model name, which is how the IDE's own modality checks are satisfied without the upstream provider advertising that capability itself.

Installing on Windows and macOS

Installation is by download, not by a package manager. On Windows you take the latest MTGA_v{version}_windows_x64-setup.exe from the GitHub releases and double click it. On macOS you take MTGA_v{version}_apple_{arch}.dmg, where the architecture is x64 for Intel processors and aarch64 for Apple Silicon, mount the DMG and drag MTGA_GUI.app into Applications.

The macOS path has a well known wrinkle that the README devotes two sections to. If macOS reports that the package is damaged, the fix is to remove the quarantine attribute from the application bundle, which the README gives as a terminal command:

xattr -d com.apple.quarantine /Applications/MTGA_GUI.app

That removes the com.apple.quarantine extended attribute, and the app then starts. The README also offers a graphical route through a separate utility called Sentinel, which processes the app when you drop it onto the Sentinel window, so you can resolve the problem without touching a terminal.

Once the app runs, the configuration order is: add a proxy configuration group where the API URL needs only the domain, with the port optional and no route suffix, then set the global configuration including your key, then start all services. The proxy configuration and the generated certificate are stored persistently in the user data directory, which you can find under the user data entry in settings. Finally you configure the IDE itself by choosing OpenAI as the provider, picking the model that matches the ID you configured, and entering the same key.

Port 443 is where the setup usually breaks

The troubleshooting section is the most honest part of the documentation, and it starts from the assumption that something is already broken. The first check is the hosts file, because a commented out 127.0.0.1 api.openai.com line, or one that another tool rewrote, produces exactly the symptom of no traffic arriving. The second check is port 443, because the proxy needs to listen where the IDE expects the real API to be, and a browser or a VPN client holding that port will block the start. The README gives the commands to look for the conflict:

netstat -ano | find ":443" | find "LISTENING"
netstat -lnp tcp | grep :443

The first line is the Windows form and the second the macOS one, and both are for finding the process that already owns the port. The advice is to close that process.

Beyond that, the README asks for a clean network environment. Other proxy software can interfere, and it recommends running a separate proxy in TUN mode rather than as a system proxy, and deploying it on a machine other than the one running MTGA if possible. DNS misconfiguration can also stop the resolution. The remaining items are the usual suspects: the CA in the trust store, the firewall allowing inbound connections on 443, and, for a deeper look, using a debugging proxy such as Reqable to send a list request with a Bearer Token and read the response body directly, with the strict SSL mode option turned off in the proxy server settings.

A Nuxt and Tauri shell around a Python core

The repository layout explains a lot about how the project is built. The default branch is tauri, and the tree carries a Nuxt front end with nuxt.config.ts, an app/ directory and a src-tauri/ directory, alongside a python-src/ directory holding the Python side. The package manifest is named mtga-tauri, uses pnpm as its package manager at version 10.32.1, and requires Node in the range 24 and above but below 25.

The scripts show how the two halves are developed together. The Python side runs through uv, with dev:py setting DEV_SERVER and MTGA_SRC_TAURI_DIR and starting python -m mtga_app, while dev:all runs the Nuxt dev server and the Python service concurrently. The Python checks are pyright and ruff through uv, and the JavaScript checks are prettier, eslint and vue-tsc against the generated Nuxt tsconfig. A gate script at scripts/ci-gate.mjs is invoked by several app, rs and py gate targets, so the repository has a single scripted entry point for its own quality checks.

Configuration is deliberately minimal. The .env.example states that no environment variable is needed by default, that MTGA_ENV_FILE can point at a different .env path, and that MTGA_RESOURCE_DIR can override the auto detected resource directory with an absolute path. That last one matters for packaging, since the app embeds a Python runtime under src-tauri and there are separate install targets for Windows and macOS that reinstall the mtga-app package into the embedded interpreter.

AGPL-3.0, administrator rights, and a June 2026 last push

The licence is AGPL-3.0, which is the strongest copyleft in common use and the one detail that matters most for anyone who plans to modify the tool or build on it. The network copyleft clause means that if you run a modified version as a service for other users, you are obliged to offer them the corresponding source. For a desktop application that a person runs on their own machine, that clause rarely bites, but for anyone who embeds the Python core, that is a different question, and it is a question to answer before building on the code rather than after.

The operational cost is higher than the licence question. MTGA needs administrator rights, installs a certificate into the trust store of the operating system, rewrites the hosts file and occupies port 443. On a company machine with endpoint management, on a shared workstation, or anywhere a certificate and hosts change is a policy violation, this is the wrong tool regardless of how well it works.

The repository is not archived. The last push was on 2026-06-18, and the newest release is v2.6.0 from 2026-05-18, preceded by v2.6.0-beta.5 and v2.6.0-beta.4, so the 2.6.0 line went through a beta phase and the project is now several months past its last push. Documentation exists in many languages, with English, Japanese, Korean, Spanish, French, Portuguese, German and Russian versions in the docs directory, and a CHANGELOG.md and ROADMAP.md sit at the root for history and direction.

Editorial conclusion

Adopt MTGA if you use the Trae IDE on Windows or macOS, need to route it to a model provider of your own choosing, and are willing to grant administrator rights on your own machine. Do not adopt it on a shared or managed workstation, since it installs a root certificate, rewrites the hosts file and takes port 443, and do not expect it to fix a provider that the upstream list in docs/provider-support.md does not include. Verify three things first: that your provider type is one of the supported entries in the config group, that port 443 is free before you start the services, and that the generated CA is trusted in your root store, since a missing trust entry shows up as an SSL or TLS error inside the IDE. The last push was on 2026-06-18 and the newest release is v2.6.0 from 2026-05-18, so pin that build rather than assuming the tauri branch is stable.

Frequently asked questions

Official sources

1. BiFangKNT/mtga on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases