leetgo: a terminal-first LeetCode client with local test execution

The gap leetgo fills between the browser editor and your own toolchain

LeetCode's web editor gives you a text box, a run button and a submit button. That is enough to pass problems and not enough to debug them. You cannot set a breakpoint in the browser, you cannot run the same input twice under a profiler, and you cannot keep your solutions in a repository laid out the way you like. leetgo moves the whole loop into the terminal: it fetches the problem, writes a description and a code skeleton into your working directory, generates test cases, and runs your solution against them on your machine. The README describes the target user as someone who wants to do all LeetCode exercises without leaving the terminal, and the command list backs that up. There is pick to generate a problem, test to run cases, submit to send the answer, edit to open the file in your editor, and contest to pull a live contest's problems. The audience is narrow and specific: engineers who already live in a terminal and an IDE, and who treat LeetCode as practice rather than as a website they visit. If you solve one problem a month and never debug, the setup cost is not repaid.

How generation, local testing and submission actually fit together

The mechanism is code generation plus a per-language test harness. When you run leetgo pick, the tool writes a file containing the problem description, a skeleton function body, and a main function that reads test input from stdin, calls your function, and prints the result in a serialized form. The README shows the generated Go output for problem 257: a binaryTreePaths function with an empty body, plus a main that deserializes a tree from stdin, calls the function, and prints the serialized answer. That file is a complete, runnable program, which is the design decision that makes local testing possible at all. leetgo test -L then runs that program against the cases in testcases.txt and compares outputs. Because the harness is generated per language, local testing has to be implemented per language, and the README's support matrix reflects that: Go, Python, C++ and Rust have both generation and local testing, while Java, JavaScript, TypeScript, PHP, C, C#, Ruby, Swift, Kotlin, Bash and the SQL dialects have generation only. The repository layout matches the story: there is a lang/ directory for per-language logic, a leetcode/ directory for site interaction, and a separate testutils/go module referenced from go.mod, with Makefile targets release-pypi and release-cargo pointing at testutils/python and testutils/rust. The test harnesses are shipped as their own packages per language, not embedded in the main binary.

Installing leetgo and generating your first problem

The README lists five installation routes. On macOS or Linux, Homebrew is the shortest: brew install leetgo. On Windows, the project publishes a Scoop bucket. Arch users can install leetgo-bin from the AUR, and there is a curl installer script for macOS and Linux. If you already have a Go toolchain, go install works and builds from source. After installing, initialize a workspace. The init command takes a site flag and a language flag, and writes a leetgo.yaml config file that the Quick Start tells you to edit.

leetgo init -t <us or cn> -l <lang>

The -t value selects leetcode.com or leetcode.cn and -l selects the target language. Then pick a problem. The README defines a qid identifier with several accepted forms, so you can address a problem by slug, by numeric id, or by date.

leetgo pick two-sum
leetgo pick 1
leetgo pick today

The first form uses the slug, the second the question id, and today resolves to the daily question. yesterday and today-1 also work, and today-2, today-3 and so on are supported. Once the file exists, run the tests and submit. The README notes that test and submit can be combined in one command.

leetgo test last -L
leetgo submit last
leetgo test last -L -s

Here last refers to the most recently generated question, -L selects local execution, and -s submits after a successful test. You can open the generated file in your editor with leetgo edit last.

The language matrix is the real constraint, not the CLI surface

The most consequential limitation is stated plainly in the README's support matrix and is easy to skim past. Local testing, the feature that justifies the tool's existence for a debugging-oriented user, exists for four languages. Everything else gets generation only. If you write Java or TypeScript, leetgo will still fetch problems and produce skeleton files, but leetgo test -L has no harness to run, so the debugger story disappears and you are back to pasting code into a browser. The README acknowledges this directly and invites contributions to implement local testing for more languages. A second limitation is that the local test path depends on generated code staying intact. The skeleton includes markers like @lc code=begin and @lc code=end, and the README mentions modifiers that pre-process code. That implies regeneration and template customization interact with whatever you wrote between the markers. The README does not document rollback of generated files, nor what happens if you edit the generated main function. A third point: the ChatGPT-based fix command is labelled experimental in the feature list and described in the command help as being for fun, which is a fair signal about how much weight to put on it.

How leetgo differs from a plain LeetCode CLI wrapper

A generic LeetCode command-line client typically wraps the site's API: fetch the problem, submit the answer, print the verdict. The test loop still happens on LeetCode's servers, and you still cannot attach a debugger. leetgo's approach is different in kind, because it generates a self-contained program with a stdin-driven main function and runs that program against a local testcases.txt. The trade-off is that this only works where someone wrote a test harness, which is why the language matrix is uneven. The other meaningful difference is contest handling. The README says leetgo can generate contest questions in real time and submit all of them at once, with the qid form weekly100 addressing the 100th weekly contest and weekly100/1 addressing a single problem inside it. A thin API wrapper would let you fetch a contest problem but not batch-submit a generated set. Conversely, a wrapper is language-agnostic by construction. If you solve in a language outside leetgo's four, the wrapper's approach costs you nothing while leetgo's costs you the main feature.

Maintenance, licensing and what upgrades cost you

The repository is not archived, and its last push was on 2026-08-18. Release v1.4.18 landed the same day, after v1.4.17 on 2026-04-04 and v1.4.16 on 2025-12-23. That is a steady cadence rather than a burst, and the gap between v1.4.17 and v1.4.18 is roughly four and a half months. The project is MIT licensed, which is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice are kept. That is a statement about the licence text, not legal advice; if you plan to vendor the code, read the LICENSE file in the repository root. Upgrade cost is mostly a matter of generated artifacts. Because skeletons are written into your working directory, a new leetgo version that changes a code template or a modifier can produce different output for the same problem. The README documents custom templates and modifiers as a feature, which means your leetgo.yaml may need revisiting after an upgrade. The README does not describe a migration guide or a changelog for template changes, so the practical check is to regenerate one problem after upgrading and diff it against the committed version before regenerating in bulk.

Editorial conclusion

Adopt leetgo if you solve LeetCode problems in Go, Python, C++ or Rust and want the test loop to run under your own debugger. Do not adopt it if your language is Java, JavaScript, TypeScript or anything else in the generation-only column, or if you need a documented rollback path for generated files, which the README does not describe. Before committing to it, run leetgo init -t <us or cn> -l <lang>, check that leetgo.yaml reflects the site and language you want, and confirm that leetgo test last -L actually executes your language's test harness on your machine.

Frequently asked questions

Official sources

1. Issues
2. j178/leetgo on GitHub
3. License: MIT
4. README
5. Releases