DelphiOpenAI: an OpenAI API wrapper for Delphi 11 and later

What problem DelphiOpenAI solves for Pascal developers

Calling the OpenAI HTTP API from Delphi by hand means building JSON request bodies, setting authorization headers, parsing nested response objects, and repeating that work for every endpoint you touch. DelphiOpenAI packages that work as Pascal classes and interfaces. The README states the library is an unofficial implementation over the public OpenAI API and notes that OpenAI does not provide an official Delphi library, so this fills a gap rather than replacing a first-party SDK.

The audience is narrow and specific. The README badge says IDE Version Delphi 11+, and the platform badge says all platforms, which matches the usual Delphi split between VCL desktop targets and FireMonkey mobile or Linux targets. If you maintain a Windows service, a desktop tool or a cross-platform client written in Object Pascal and you want a chat panel, an image generator or a transcription step inside it, this is the layer that saves you from writing a JSON client yourself.

The repository also names non-OpenAI services it is compatible with: Azure OpenAI, DeepSeek, YandexGPT, Qwen and GigaChat. That matters for teams whose compliance rules push inference to a regional provider. Each service ships as its own unit, for example OpenAI.GigaChat.pas, so the compatibility is not just a claim in prose.

How the wrapper is structured and how a request flows

The entry point is the TOpenAI class, exposed either as a component or as an interface. From there, each endpoint family has its own unit: OpenAI.Chat.pas, OpenAI.Images.pas, OpenAI.Audio.pas, OpenAI.Embeddings.pas, OpenAI.Files.pas, OpenAI.Models.pas, OpenAI.Moderations.pas, OpenAI.FineTuning.pas, OpenAI.Completions.pas, OpenAI.Edits.pas and OpenAI.Engines.pas. Assistants live in OpenAI.Assistants.pas. Shared types sit in OpenAI.Types.pas and OpenAI.API.Params.pas, and the HTTP layer is OpenAI.API.pas.

Request parameters are not passed as a long constructor argument list. They are set inside an anonymous method that receives a params object, which the README explains by saying that many parameters exist and not all are required. The call itself is synchronous and returns an object you own and must free, usually in a try/finally block. Streaming is the exception: CreateStream takes a second callback that fires as deltas arrive, and the callback receives an IsDone flag plus a var Cancel parameter, so the caller can stop the stream rather than only observe it.

Two utility units are worth noting because they signal where the friction normally appears. OpenAI.Utils.JSON.Cleaner.pas suggests response text sometimes needs cleaning before display, and OpenAI.Utils.ChatHistory.pas plus OpenAI.Component.ChatHistory.pas indicate that conversation history management is treated as a library concern rather than something every caller reimplements. The Samples folder has Chat, QuickChat and Sample projects, so there is a working reference for the chat path in particular.

Installing DelphiOpenAI and sending a first chat request

The README gives two installation routes. The first is GetIt, Embarcadero's package manager, which installs the package directly into the IDE. The second is manual: add the repository root folder to the IDE library path or to your project source path. There is no build step described beyond that, and no environment variable is documented for the API key, so the token is passed in code.

Initialization takes the token and returns the entry point. The README shows both a component form and an interface form:

uses OpenAI;

var OpenAI := TOpenAIComponent.Create(Self, API_TOKEN);

or:

uses OpenAI;

var OpenAI: IOpenAI := TOpenAI.Create(API_TOKEN);

A first real use is a chat completion. Messages are built as an array, the token limit is set, and the returned object is freed when you are done. The README example reads:

var Chat := OpenAI.Chat.Create(
  procedure(Params: TChatParams)
  begin
    Params.Messages([TChatMessageBuild.Create(TMessageRole.User, Text)]);
    Params.MaxTokens(1024);
  end);
try
  for var Choice in Chat.Choices do
    MemoChat.Lines.Add(Choice.Message.Content);
finally
  Chat.Free;
end;

After this runs, MemoChat holds the assistant reply. The try/finally is not optional decoration: the README wraps every non-streaming example the same way, which tells you the returned objects are heap-allocated and the caller owns them. If you want tokens to appear as they are generated instead of all at once, switch to CreateStream and read Chat.Choices[0].Delta.Content inside the callback, as the stream example in the README does.

Streaming, vision and the parts the README marks as unfinished

The coverage table is the most honest document in the repository. Models, Completions, Chat, Chat Vision, Edits, Images, Embeddings, Audio, Files, Fine-tunes, Fine-tuning, Moderations and Engines are marked done. Assistants, Threads, Messages and Runs are marked in progress. That is a clean line: the classic request-and-response endpoints work, the stateful assistant API does not yet.

Vision support is shown with the gpt-4-vision-preview model, and the request is assembled by appending to a TArray<TMessageContent> one text part and one image part, where the image is produced by FileToBase64. The README example for this uses a literal placeholder for the file path, which is a documentation gap rather than a code one: you have to supply your own path and decide how large an image you are willing to base64 into a request body.

Streaming has its own shape. CreateStream takes the params builder and a callback with the signature procedure(Chat: TChat; IsDone: Boolean; var Cancel: Boolean). The README example writes the delta content when the stream is not done and prints DONE! when it is, then sleeps 100 milliseconds between iterations. That sleep is inside the sample callback, not inside the library, so it is illustrative rather than a required throttle. The Cancel parameter means a UI can abort a long generation, which is the kind of detail that is easy to leave out of a wrapper and is present here.

Where DelphiOpenAI is the wrong choice

The clearest limitation is the Assistants family. If your design depends on creating an assistant, opening a thread, posting messages and running the assistant, the README's own table says those four areas are in progress. You would be building on endpoints the project has not declared finished.

The second limitation is the Delphi version floor. The badge says Delphi 11+, and the code style confirms it: inline variable declarations such as var Models := OpenAI.Model.List(), for-in loops over typed collections, and anonymous methods used as parameter builders. Anonymous methods exist in older Delphi releases, but the inline var syntax does not. If your codebase is pinned to Delphi 10.x for third-party component reasons, this library's own examples will not compile as written.

The third is the absence of documented operational detail. The README does not document retry behaviour, rate-limit handling, timeouts or proxy configuration beyond a section heading for proxy usage. OpenAI.Errors.pas exists in the repository, so error types are modelled, but the README does not explain which HTTP status codes map to which exception. If you are building a long-running service rather than an interactive client, you will be writing that policy yourself.

Finally, the README describes the library as unofficial. There is no compatibility guarantee from OpenAI, and the deprecation notes in the coverage table (Completions and Engines both marked deprecated, Fine-tunes deprecated) show that upstream API changes do reach this project's surface area.

How it compares with calling the API directly or using a general HTTP client

The realistic alternative is not another Delphi AI SDK, because the README states OpenAI provides no official Delphi library. The alternative is doing it yourself: use Delphi's built-in HTTP client, build the JSON with System.JSON, and parse the response by hand. That approach gives you full control over retries, timeouts and logging, and it never blocks you on a missing endpoint. It also means you own every schema change, and chat responses with nested choices, deltas and tool calls are tedious to model correctly.

DelphiOpenAI sits between those poles. It gives you typed params objects, a streaming callback with cancellation, and separate units per endpoint family, so you can read OpenAI.Chat.pas to understand exactly what is sent. The cost is that you inherit its coverage boundary, which currently excludes the assistant endpoints, and you depend on the maintainer to track upstream changes. The last push to the default branch was on 2026-07-14, and the most recent tagged release listed is v1.4 from 2024-08-01, so releases are much less frequent than commits. That pattern usually means fixes land on main before they are tagged, which is fine for teams comfortable tracking a branch and awkward for teams that only consume releases.

Licence, upgrade cost and what to check before you depend on it

The repository is MIT licensed, and a LICENSE file sits at the top level alongside the source units. MIT is permissive: you can use the library in closed-source commercial products provided you keep the copyright notice and permission text with the distribution. This is a description of the licence file, not legal advice; if your organisation has a policy on third-party notices, route the LICENSE file through it.

The upgrade surface is the API itself. Because the wrapper mirrors OpenAI's request and response shapes, an upstream change to a model name, a parameter or a deprecated endpoint can require a library update. The coverage table already records two deprecated areas, Completions and Engines, plus deprecated Fine-tunes, which means some of the done endpoints are done against interfaces OpenAI has moved away from. Budget for reading the diff of OpenAI.API.pas and the endpoint units you actually use when you take a new revision, rather than assuming a drop-in upgrade.

Installation cost is low. Adding the root folder to the library path, or installing through GetIt, is the whole setup the README describes. There is no service to run and no configuration file to maintain. The ongoing cost is the token itself and whatever you build around error handling, since the README does not document retry or rate-limit behaviour.

Editorial conclusion

Adopt DelphiOpenAI if you ship a Delphi 11 or later application and want chat, streaming, vision, images, audio or embeddings behind typed Pascal classes instead of raw HTTP calls. Do not adopt it if your product depends on the Assistants, Threads, Messages or Runs endpoints, because the README lists all four as in progress, or if you target a Delphi version older than 11. Before committing, verify that your endpoint accepts the request format the library sends, since the README names several compatible services but documents the request shape only for OpenAI, and confirm the MIT licence text in the LICENSE file matches what your legal review requires.

Frequently asked questions

Official sources

1. HemulGM/DelphiOpenAI on GitHub
2. Issues
3. License: MIT
4. README
5. Releases