ChatGPT is a native Delphi client whose newest tag is v1.0.18 from 2023, and whose VPN claim was amended in place

The feature list amends itself in place, which is the most honest thing here

One line in the feature list reads that the app does not require a VPN, and the parenthetical immediately after it says now required. Nobody rewrote the sentence. The claim is still there, with its refutation appended.

That is worth more than it looks. The reason a ChatGPT client needed a VPN is a change on the provider's side, not a bug, and there is no fix a client can ship. Most projects handle that by leaving the stale line or removing it silently. Editing in place keeps the history visible and tells a reader exactly which part of the list to distrust.

The rest of the list reads as frozen at the same moment. Access to gpt-3 and gpt-4, image generation with DALL-E, sound recognition fed to the model as context, SVG display, per-chat settings, the ability to edit a chat, all model settings, custom headers for third-party APIs, sending a message as assistant, user, or system, functions loaded from an external folder, and syntax highlighting for pascal, python, json, sql, and markdown.

The planned-features list reinforces the picture. It still contains display of mathematical formulas, support for Markdown, syntax highlighting for Linux, and additional OpenAI functions such as text correction, fine-tune based model customisation, and quick commands. None of those carry a done marker.

There is an odd overlap worth noting: Markdown appears both in the shipped syntax highlighting list and as a planned feature. One of the two is out of date, and the README does not say which.

Eight platform rows, seven downloadable, one link for all of them

The build table is the most concrete part of the documentation, and it opens with the clarification that matters: this is not a web page, it is a native application with its own interface. Every visual element is a platform-drawn control rather than HTML in a browser view, which for a Delphi FireMonkey project is the entire point of the exercise.

The table has eight rows. Windows 32-bit and 64-bit, Android 32-bit and 64-bit, Linux 64-bit, macOS on arm64, and macOS on Intel. Seven of the eight carry a check mark. iOS does not, and its download cell is empty.

That is the gap to notice, because the repository description lists iOS among the target platforms alongside Windows, Mac, Android, and Linux, and the README heading repeats it. So the description claims a platform the build table marks unavailable. Whether that is an abandoned target or a pending one is not stated.

Every other row points at the same address, a link to the repository's latest release page. There is no per-platform file listing, no version matrix, and no checksum table in the documentation. A reader who wants to know which build corresponds to which release tag has to visit the releases page and read the filenames.

Building for both macOS architectures from one Delphi project is a reasonable default in 2026, since the Intel row is the one most projects would have dropped. Keeping it suggests the project predates the transition rather than that it deliberately supports both.

Building requires a commercial Delphi toolchain, not a package manager

The dependency section is short and the first line is the constraint: building requires Delphi 11.3 or newer. That is a commercial FireMonkey toolchain with a licence, and it is not something you can install from a public package index. Anyone evaluating this project on a machine without Delphi is evaluating the download, not the source.

Two named libraries sit alongside it. Skia comes from the skia4delphi project, which provides the rendering backend. SVGImageList comes from a component library, which supplies vector icon support and therefore the SVG display the feature list advertises. The documentation also refers to submodules, and the repository tree confirms the pattern with vendored-looking directories for a third-party OpenAI client and a functions library.

The source layout makes the FireMonkey approach visible. Almost every feature is a paired form file and Pascal unit: a chat frame, a code frame, an image frame, an image preview frame, a message frame, a plain-text frame, an SVG frame, and a UI message frame, each with its own designer form. Then the application-level units for settings, chat settings, import and export, loaded functions, an overlay window, a text editor, and an about box.

Two project targets exist rather than one. There is a deployment project and a group project for the application, plus a separate console project with its own source and project files. A console variant of a chat client is not obvious from outside, and the documentation does not explain its purpose.

Functions load from a funcs folder at runtime, which is the most extensible part

The feature list mentions GPT functions and specifies the mechanism in the same line: they are loaded externally from a folder named funcs. That is a plugin system in the plainest possible sense, and it is the one design decision in this project that extends the application without a recompile.

The source layout backs it up with dedicated units. There is a functions interface unit, an external-functions unit, a functions unit, and a form whose name describes the loaded set. A library directory sits alongside them, so the pattern is unit for the contract, unit for the implementation, unit for registration, and a screen listing what arrived.

Loaded-at-runtime matters for two reasons. A user can add a function without a Delphi toolchain, which given the build requirement above is the difference between the extension mechanism being usable and being decorative. And a broken function is isolated to the folder it came from.

Two other capabilities in the same family are worth naming. Custom headers for third-party APIs means the client can point at an OpenAI-compatible endpoint rather than the default one, which is how people used these clients before provider-side restrictions made it necessary. And sending a message as assistant, user, or system is a role override on the outgoing request, which lets you construct a system prompt or simulate the other side of a conversation.

Together with per-chat settings and the ability to edit a chat, the implication is that this client was built for experimenting with request shape rather than for reading long chats comfortably.

One frame per content type, which is how the multi-modal handling is structured

The clearest way to read the architecture is as a set of frames selected by content type. There is a frame for code, one for images, one for an image preview, one for a message, one for plain text, and one for SVG, alongside the chat frame that hosts them and a separate UI message frame for the surrounding chrome.

That structure explains the feature list without needing to interpret it. SVG display is a frame. Image generation with DALL-E produces content that lands in the image frame, with the preview frame for the transient state while it loads. Syntax highlighting for pascal, python, json, sql, and markdown is the code frame doing its job on whatever the model returned. Sound recognition is a separate unit, a sound recorder, feeding transcribed context into the request.

Editing a chat is a capability rather than a frame, and it pairs naturally with the role override. Together they mean the transcript is not a read-only log of what a server returned; you can go back and change what was said, and you can change who is said to have said it.

Import and export has its own unit and form, so transcripts can leave the application. That is the feature a casual reader would want most and the one the feature list does not mention.

The Android build is visible in the tree as a manifest template at the repository root, which is how Delphi projects carry a per-platform manifest without one per form.

The newest tag is from September 2023 and the branch moved in April 2026

The version history is the fact to weigh before planning anything. The two tagged releases are version 1.0.16 from May 2023 and version 1.0.18 from September 2023. Nothing has been tagged since.

The default branch, by contrast, was pushed to on 6 April 2026, which is recent enough that the tree is being worked on. So the source and the distribution are three years out of step, and the download links that every row of the build table points to will resolve to a 2023 artifact.

That split determines what this repository is. It is a codebase that is still being modified and a release channel that has not followed. Whether the recent commits are fixes worth taking or unfinished work is not something the documentation says, because there is a changelog-shaped history in the tags and the tags stopped.

What the repository does have is a project site, hosted as GitHub Pages, which is where the screenshots and any version-specific notes would live. The language is Pascal, the licence is MIT, and the project is not archived.

For a client whose entire reason to exist is talking to a hosted API, a three-year-old binary against a current API is the practical risk. The maintenance posture to assume is that you can build it yourself if you have Delphi, and that you should not expect a fresh download.

Editorial conclusion

This repository is worth reading if you want a native desktop client written in a compiled language rather than a browser in a wrapper, and if you want to see FireMonkey's form-per-frame approach applied to a real multi-modal chat interface. The per-chat settings, the role override that lets you send a message as assistant or system, and the external functions folder are the three ideas worth taking. Two things to check before building on it. The build toolchain, because Delphi 11.3 or newer is a commercial product and Skia plus SVGImageList have to be fetched as submodules, so this is not a project you can build from a package manager. And the release state, because the newest tag is from 2023 while the branch moved in April 2026, so what a download gives you and what the source contains are different things. Treat it as a maintained codebase with an unmaintained distribution rather than the reverse.

Frequently asked questions

Official sources

1. HemulGM/ChatGPT on GitHub
2. License: MIT
3. Project website
4. README
5. Releases