64Gram: an unofficial Telegram Desktop fork with a Windows x64 build

What 64Gram adds to Telegram Desktop, and who it is for

64Gram is a fork of Telegram Desktop published by the TDesktop-x64 organisation. The README states the project goal plainly: "Provide Windows 64bit build with some enhancements." The original motivation, that official Telegram Desktop did not ship a Windows 64-bit build, is struck through in the README, so the fork now leans on the enhancements rather than on architecture alone. The repository describes itself as "64Gram (unofficial Telegram Desktop)", and the word unofficial is doing real work here: this is not a Telegram product, and the README points to a Telegram channel and discussion group rather than to any official support channel.

The intended audience is narrow. It is a Windows user who wants a native x64 binary of a desktop Telegram client and is willing to run a build that tracks upstream Telegram Desktop plus a patch set. The README also lists Linux 64 bit and macOS above 10.12 as supported systems, so the fork is not Windows-only in practice, but the project goal sentence is Windows-specific. If you are on macOS or Linux, the reason to choose 64Gram over upstream Telegram Desktop is the feature list, not the architecture.

The features live in a separate file, features.md, which the README links but does not inline. That is a deliberate separation: the README stays short and the feature surface is maintained elsewhere. It also means the README alone cannot tell you what is different. Anyone evaluating 64Gram has to open features.md before deciding, because the repository's top-level README does not enumerate a single enhancement.

How the fork is structured: upstream code plus a patch set

The repository layout shows a C++ project built with CMake. CMakeLists.txt sits at the top level, alongside a cmake directory, a lib directory and a Telegram directory. That is the shape of a Telegram Desktop tree with the fork's additions layered in. The default branch is named dev, not master or main, which tells you where the maintainers consider work to happen.

Build documentation is split by platform into docs/building-win.md, docs/building-mac.md and docs/building-linux.md. The README links each one. The Linux path is described as "GNU/Linux using Docker", so the container definition in the repository is the supported way to produce a Linux build rather than a native toolchain walkthrough. There is also a snap directory at the top level, which indicates packaging metadata for Snap exists in-tree.

Several top-level files are aimed at automated coding assistants rather than humans: AGENTS.md, CLAUDE.md, GROK.md and directories .agents/, .claude/ and .grok/. Their presence says the maintainers are working with agent tooling on this codebase. It is a repository convention, not a user-facing feature, and it does not change how you install or run 64Gram. What it does suggest is that the fork accumulates tooling around the same upstream tree rather than restructuring it, which is consistent with a patch-set model.

The changelog files are split too: changelog.txt and 64gram_changelog.txt sit side by side at the top level. The upstream changelog and the fork's own changelog are kept separate, so a reader can see which changes come from Telegram Desktop and which come from the fork. That is a useful convention for anyone tracking what a fork actually changed.

Installing 64Gram from the release page and building it yourself

The README does not give a binary install procedure. It says only that "The latest version is available on the Release page", linking to the GitHub releases for TDesktop-x64/tdesktop. If you want a ready binary, that page is the documented source. The README does not describe an installer, a package repository, or an update mechanism, so treat the release page as the whole distribution story.

If you prefer to build, the README routes you to three platform documents. The Windows instructions are in docs/building-win.md, macOS in docs/building-mac.md, and Linux in docs/building-linux.md. The Linux document is described as using Docker. The repository itself does not reproduce the build commands in the README, so the exact flags and dependencies come from those files, not from this article.

Once you have a build or a release binary, the first thing worth doing is comparing it against upstream Telegram Desktop on the same machine. The fork keeps its own changelog in 64gram_changelog.txt, so that file is the fastest way to see what the current build carries. The releases listed for the project are tagged v1.2.10, v1.2.8 and v1.2.7, with v1.2.10 dated 2026-09-21.

For localization work, the README gives a concrete workflow. Translations live in a separate repository, TDesktop-x64/Localization, with a template at en.json. The README explains that you can find the language ID in Telegram's log.txt, quoting the line format:

[2022.04.23 10:37:45] Current Language pack ID: de, Base ID: 

From that, the README says your translation filename is de.json "or something like that", and it explicitly says to ignore the base ID because base ID translation is a work in progress. Contributions go in as pull requests against the localization repository. Note the README's tone on this: "If you want to translate this project, Just Do It!" There is no review process described beyond the pull request itself.

Where 64Gram is the wrong choice

The README states there is no roadmap, and it does so with a rhetorical question: "No Roadmap? Yes." That is an honest disclosure, but it is also a planning constraint. If your organisation needs to know where a client is going before standardising on it, 64Gram will not tell you. Feature direction is visible only after the fact, in features.md and in the fork's changelog.

The default branch is dev. The README does not describe a stable branch, a release cadence, or a support window for older versions. Releases exist (v1.2.7, v1.2.8, v1.2.10), but nothing in the README says how long a given release is supported or whether fixes are backported. A user who pins a version has no documented answer to "how long will this keep working".

Rollback is undocumented. The README says nothing about downgrading, about data migrations between versions, or about what happens to a local profile when you move between a fork build and upstream Telegram Desktop. Because this is a chat client with local state, that gap matters more than it would for a stateless tool. The README is silent, and silence is not a guarantee that downgrade is safe.

Licensing is another boundary. The source is published under GPLv3 with an OpenSSL exception, and the repository carries both LICENSE and LEGAL files. That is fine for personal use and for anyone willing to comply with the GPL, but it is a different proposition from using an official client, and the README offers no guidance on redistribution beyond the licence file itself. Finally, the supported-system list is coarse: "Windows 7 and above" does not distinguish 32-bit from 64-bit, even though the project goal is specifically a 64-bit Windows build. If you need a 32-bit Windows binary, the README does not promise one.

64Gram compared with upstream Telegram Desktop

The honest alternative is Telegram Desktop itself, the upstream project this fork is based on. The difference is not in the protocol or the core client; it is in what each project promises. Upstream is the reference implementation, and its repository is the place where the client's behaviour is defined. 64Gram takes that tree and adds "some enhancements", which the README declines to enumerate, pointing instead to features.md.

So the comparison comes down to two questions. Do you need the enhancements? If yes, upstream will not give them to you, and 64Gram is the only one of the two that will. Do you need a documented support model, a roadmap, or a stable branch? Then upstream is the safer default, because 64Gram's README explicitly disclaims a roadmap and names its default branch dev.

There is a third option worth naming: build upstream Telegram Desktop yourself. The repository layout here shows a standard CMake tree with platform build docs, so the same skill set that lets you build 64Gram lets you build the upstream client and apply only the patches you want. That path costs more maintenance effort and gives you full control. It is the right answer for a team that wants one specific enhancement and nothing else, and it is the wrong answer for anyone who wants someone else to keep the patches current. 64Gram's last push was on 2026-09-21, the same date as the v1.2.10 release, so the fork is being updated, but the README gives no commitment about how long that continues.

Maintenance, licensing and upgrade cost

The repository is not archived, and the most recent push recorded is 2026-09-21, which coincides with the v1.2.10 release. The two prior releases, v1.2.8 and v1.2.7, are dated 2026-08-30 and 2026-08-07. That spacing shows a release rhythm of roughly three to four weeks across those three versions, though three data points do not establish a schedule, and the README makes no promise about one.

Upgrade cost is where the fork model shows its seams. Because 64Gram tracks Telegram Desktop and layers patches on top, each upstream change is a potential conflict with the fork's own edits. The repository keeps changelog.txt and 64gram_changelog.txt separate, which helps a reader attribute changes, but it does not tell you how much work a given upgrade will be. The README does not document a migration or rollback procedure, so an upgrade that goes wrong has no documented recovery path.

On licensing, the README states the source is published under GPLv3 with an OpenSSL exception, and the licence text is in the LICENSE file. The GPL is a copyleft licence, which has practical consequences for anyone who wants to redistribute a modified build: the source for those modifications has to be made available under the same terms. That is a description of the licence, not legal advice, and the repository also ships a LEGAL file that a redistributor should read. For an individual running the client on their own machine, none of this creates an obligation beyond using the software; for anyone packaging it, it does.

Editorial conclusion

Adopt 64Gram if you want a 64-bit Windows build of Telegram Desktop with the enhancements listed in features.md, and you are comfortable tracking a fork whose default branch is dev and whose README states there is no roadmap. Do not adopt it if you need a documented rollback path, a stable release channel, or a 32-bit Windows binary: the README lists Windows 7 and above without splitting by architecture, and the project goal text is struck through, which signals the original 32-bit rationale no longer drives the fork. Before installing, read features.md end to end and confirm the feature set you actually need is in v1.2.10, released 2026-09-21.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. TDesktop-x64/tdesktop on GitHub