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

The gap leetgo fills between the browser editor and a real repository

LeetCode's own editor is a browser text box. You get a skeleton, a handful of example cases, and a Run button that ships your code to a remote judge. There is no debugger, no breakpoint, no way to step through a failing case, and no local file you can put under version control. For someone practising for interviews this is tolerable. For someone who wants to write a solution the way they write production code, in an IDE with a debugger and a test file, it is a constant context switch.

leetgo is a command-line tool for LeetCode that moves that workflow into the terminal. The README describes it as providing "almost all the functionality of LeetCode", and the command list backs that up: init, pick, info, test, submit, fix, edit, contest, cache, debug and open. The target user is an engineer who already has an editor and a build toolchain and does not want to leave them. The secondary audience is contest participants, since leetgo can generate contest questions in real time and submit all of them at once, which the README frames as keeping your submissions "one step ahead".

How generation and local testing actually work

The mechanism is code generation plus a generated main function. When you run leetgo pick for a question, it fetches the problem statement, converts the HTML description to Markdown (the dependency list includes html-to-markdown, goquery and html2text), and writes a problem file containing the description, the skeleton, and the test cases in a separate testcases.txt. The generated file is wrapped in markers: @lc code=begin and @lc code=end delimit the region you are meant to edit.

What makes local testing possible is that the generated code is a complete runnable program, not a fragment. The README shows the Go output for problem 257, where the skeleton is followed by a main function that reads from stdin, deserializes the input, calls your function, and prints the result with an "output: " prefix. Because it is a normal program, you can run it by hand, pipe in a case, and compare. leetgo test -L automates that loop: it runs the program against the cases in testcases.txt and diffs the results. The README is explicit that this is why local testing is hard to add per language: "Local testing requires more work to implement for each language, so not all languages are supported." The support matrix confirms it. Go, Python, C++ and Rust have both generation and local testing. Everything else, including Java, JavaScript, TypeScript, C#, Ruby, Kotlin and the SQL dialects, has generation only.

Installing leetgo and running your first problem

The README points at the release page for a binary, and also lists package-manager routes. On macOS or Linux with Homebrew, the install is a single formula. On Windows, Scoop is supported through the j178 bucket. Arch users have leetgo-bin in the AUR, and there is an installer script and a go install path. Pick whichever matches your machine.

brew install leetgo

If you prefer Scoop on Windows, the README gives two commands: add the bucket, then install the package.

scoop bucket add j178 https://github.com/j178/scoop-bucket.git
scoop install j178/leetgo

With the binary on your PATH, initialize a workspace. The -t flag selects the site (us or cn) and -l selects the language. This writes a leetgo.yaml that you are expected to edit before going further.

leetgo init -t us -l go

Now pick a question. leetgo defines its own question identifier, called qid, which accepts a slug, a numeric id, or a relative day. The README uses two-sum as the running example.

leetgo pick two-sum

After picking, you should have a generated source file with the @lc code=begin and @lc code=end markers, plus a testcases.txt. Edit the function between the markers, then run the local tests. The -L flag is what forces local execution.

leetgo test last -L

If the tests pass, submit with the same qid. The README also notes that test and submit can be combined with -s.

leetgo submit last

The local testing matrix is the real constraint

This is the part to read before you invest time. leetgo's headline feature is local testing, and local testing covers four languages. If you solve in Java, JavaScript, TypeScript, PHP, C, C#, Ruby, Swift, Kotlin, Bash, MySQL, MSSQL, Oracle, Erlang, Racket, Scala, Elixir or Dart, leetgo will generate a skeleton and test cases for you, but leetgo test -L will not run them. You are back to pasting into the browser for verification, which removes most of the reason to use a CLI at all.

The README acknowledges this directly and invites contributions: "Welcome to help us implement local testing for more languages!" That is an honest framing, but it also means the feature set is uneven by design. A second limitation is authentication. The README states that leetgo reads cookies from your browser automatically, so there is no password prompt. That is convenient when it works and opaque when it does not, because the failure mode is a cookie extraction problem in a dependency, not a leetgo error you can reason about. The debug command exists for this kind of diagnosis, but the README does not document what it prints.

Where leetgo sits next to a plain generated file and a local judge

The obvious alternative is doing it by hand: copy the skeleton from the browser, paste it into a file, copy the sample cases into a text file, and write your own main function to read them. That is exactly what leetgo automates, and for a single problem it is not much work. The difference shows up at volume. leetgo maintains a local question cache (there is a cache command to manage it), supports relative qids like today, yesterday, today-1 and today-2, and can pull an entire contest with leetgo contest weekly100. Doing that manually means twenty browser tabs.

A second comparison is against a full local judge harness that you write yourself around your own test data. That approach gives you complete control over input format and assertions, and it works for any language because you wrote it. leetgo's advantage is that the input format is already solved for you, matching LeetCode's serialization for trees and lists, which is the tedious part. The trade-off is that you inherit leetgo's per-language implementations of that serialization rather than your own, and the support matrix tells you which four languages have one.

Maintenance, licensing and what upgrading costs you

The repository is not archived, and the last push was on 2026-08-18. The most recent release, v1.4.18, was tagged the same day, following v1.4.17 on 2026-04-04 and v1.4.16 on 2025-12-23. That cadence suggests the project is still being worked on, though the release notes are not in the repository, so treat the interval between v1.4.16 and v1.4.17 as a gap rather than a signal either way.

The licence is MIT, which is permissive: you can use, modify and redistribute leetgo, including in commercial settings, provided the copyright notice and permission notice are preserved. That is a summary of the licence identifier, not legal advice; read the LICENSE file in the repository root if the distinction matters to you.

Upgrade cost is low in the normal case, since the binary is self-contained and the config is a single leetgo.yaml. The friction is in generated code. leetgo writes files into your workspace, and if a new version changes the template or the test harness, regenerating a question could overwrite edits you made outside the @lc code=begin and @lc code=end markers. The README does not document rollback or a dry-run mode for pick, so keep the generated workspace in version control before upgrading.

Editorial conclusion

Adopt leetgo if you solve LeetCode problems in Go, Python, C++ or Rust and want generated test cases plus a real local runner you can attach a debugger to. Do not adopt it if your language is Java, JavaScript, TypeScript, C# or any of the twenty-odd languages listed as generation-only, because leetgo test -L will not work there. Before committing, verify three things in your own workspace: that leetgo init -t <us or cn> -l <lang> writes a leetgo.yaml you are happy with, that leetgo test last -L actually executes your language, and that cookie extraction from your browser succeeds, since the README states cookies are read automatically rather than by password.

Frequently asked questions

Official sources

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