macai: a native macOS AI chat client for OpenAI, Claude, Gemini and Ollama

What macai solves, and who it is for

macai (macOS AI) is a native macOS chat client that supports ChatGPT, Claude, xAI (Grok), Google Gemini, Perplexity, Ollama, OpenRouter, and what the README calls "almost any OpenAI-compatible APIs". The problem it addresses is fragmentation. If you use a hosted model for one task and a local model for another, the usual setup is several browser tabs, each with its own session, its own history and its own keyboard shortcuts. macai puts those providers behind one interface and one settings pane.

The audience is narrower than the provider list suggests. The system requirements state macOS 14.0 and later, with both Intel and Apple chips supported, so this is a Mac-only tool. The README also points people new to LLMs toward Ollama, which runs open models locally on Apple M1 through M4 machines. That combination, a native client plus a local back end, is the strongest argument for macai: it gives you a desktop chat surface for models that never leave the machine, using the same UI you use for paid APIs.

How macai talks to providers: API services and assistants

The architecture visible in the README is a client that stores API service definitions and routes chat requests through them. In the Ollama walkthrough, the user opens the API Service tab in settings, adds a new API service in Expert mode, and selects type "Ollama". A model is then chosen and set as the default AI Assistant. That sequence tells you the data flow: a service holds connection details, an assistant binds a service and a model to a chat, and the chat window sends messages through that binding.

The same pattern applies to commercial providers. To run macai with ChatGPT or Claude you need an API token, which the README describes as being like a password, and it links to each vendor's own instructions for obtaining one. macai does not proxy your traffic through a project-run server; the app talks to the provider endpoint you configured. The README states there is no telemetry or usage tracking by macai itself, with the caveat that Apple may collect anonymized telemetry when iCloud Sync is enabled.

Settings, chats and messages are local unless iCloud Sync is on. The repository layout shows a single Xcode project, macai.xcodeproj, with macai/, macaiTests/ and macaiUITests/ directories, which matches a straightforward SwiftUI app rather than a plugin or extension architecture.

Installing macai with Homebrew and sending a first message

The README gives two install paths: a manual download of the latest universal binary, which it says is notarized by Apple, and a Homebrew cask. The cask is the shorter route.

brew install --cask macai

After the app launches, you need a provider. For a paid API, obtain a token from the vendor first; the README links to OpenAI, Claude, Gemini, xAI and OpenRouter token instructions. Then add it as an API service in settings and pick the model you want.

If you would rather not pay for tokens, the documented Ollama path is the alternative. Install Ollama from its official site, then pull a model in a terminal. The README recommends llama3.1 or llama3.2.

ollama pull llama3.1

Back in macai, open the API Service tab in settings, add a new API service in Expert mode, and set its type to "Ollama". Select the model, set it as the default AI Assistant, and save. The README's last step is to test and use it. If the model list is empty or the assistant does not respond, the failure is almost always at the Ollama step: the model was not pulled, or the local server is not running.

Building from source, and the iCloud Sync split

macai is Apache-2.0 and the repository is a normal Xcode project, so building it is possible without an Apple Developer account. The README splits the instructions by whether you have one, and the split is really about iCloud Sync.

With a developer account, you clone the repo, open macai.xcodeproj, select your team under Signing & Capabilities, and build. iCloud Sync is off in Debug builds by default because of a DISABLE_ICLOUD compiler flag; the README says this is to simplify contributor setup and avoid CloudKit signing problems. Release builds have it enabled.

Without an account, you point the target at a different entitlements file and sign locally. The command line version from the README is:

git clone https://github.com/Renset/macai.git
cd macai
xcodebuild -scheme macai \
  -configuration Debug \
  CODE_SIGN_IDENTITY="-" \
  CODE_SIGN_ENTITLEMENTS="macai/macai-no-icloud.entitlements" \
  DEVELOPMENT_TEAM="" \
  CODE_SIGNING_ALLOWED=NO \
  build

The README is explicit that an app built this way works normally except for iCloud Sync, and that chat, API services and personas all function. That is a reasonable trade for a contributor, but it means a locally built copy is not the same product as the notarized release, and you should not expect settings or history to move between machines.

Where macai is the wrong choice

The clearest limitation is the platform. macOS 14.0 and later only. If your team is mixed, or you work on Windows or Linux part of the time, macai cannot be the shared client, and any chat history you build in it stays on the Mac.

The second limitation is documentation depth. The README covers installation, tokens and the Ollama setup, and it lists features such as vision, image generation, search, reasoning, and import/export. It does not explain how import and export are formatted, what happens to a chat when you switch the assistant's model, or how conflicts are resolved when iCloud Sync is on across two machines. The README notes that Apple may collect anonymized telemetry when iCloud Sync is enabled, but it does not describe what is synced beyond chats, messages and settings.

Third, macai assumes you are comfortable managing credentials. There is no hosted account, so every provider means obtaining and pasting an API token, and every provider's billing and rate limits are yours to track. A user who wants a single sign-in and a single bill will find that this design pushes the work back to them.

Finally, the release history shows a gap. v2.4.2 arrived on 2026-01-16 and v2.4.3 on 2026-08-16, so there was a seven-month stretch between releases. The README says the project is in active development and the repository is not archived, with the last push on 2026-08-16, but a team that needs a predictable release cadence should look at that spacing before standardizing on it.

Alternatives and the difference in approach

The obvious alternative for a local-first workflow is Ollama's own tooling. Ollama is the back end macai connects to, and it ships a command line interface and its own API. The difference is shape rather than capability: Ollama gives you a terminal and an HTTP endpoint, and you build or pick a front end yourself, while macai gives you a window with chats, assistants and settings already wired up. If you only ever talk to one local model and you are happy in a terminal, macai adds a layer you do not need.

On the hosted side, the alternative is each vendor's own web interface. That removes the token setup entirely and usually exposes provider-specific features first, because the vendor ships them. What you give up is the single window and the ability to keep a local model in the same list as a hosted one. macai's value is proportional to how many providers you actually juggle; with one provider, the web UI is simpler.

A third option is any cross-platform desktop client. Those run on Windows and Linux as well, which macai does not, and they usually bring their own sync service rather than relying on iCloud. The trade is that they are not native macOS apps, which is the property macai leads with.

Maintenance, upgrades and the licence

macai is licensed under Apache-2.0, which permits commercial and private use, modification and redistribution, and includes an explicit patent grant. It also requires that you keep the licence and notice files and state significant changes if you redistribute a modified version. That matters here because the README documents a fork path: if you build and ship a customized macai, the licence obligations travel with your binary. This is a description of the licence text, not legal advice; read LICENSE.md in the repository for the binding terms.

Upgrades are simple for the Homebrew cask install, since brew upgrade --cask macai pulls the newer notarized build. Source builds are the opposite: you are responsible for pulling the repository and rebuilding, and because iCloud Sync depends on entitlements and signing, a fork that changes bundle identifiers or entitlements can lose sync even though the chat features keep working. The README's iCloud section is aimed at contributors and forks, and it is the part most likely to need updating when Apple changes CloudKit requirements.

One cost worth naming: the README asks for funding to keep development going. A project with a single maintainer and a seven-month release gap is a real dependency risk for a team, not just an individual.

Editorial conclusion

macai suits Mac users who want one native window for several providers, including local Ollama models, without running a browser tab or an Electron app. It is the wrong tool if you need Windows or Linux, or if you want a documented sync and upgrade story before you commit. Verify first that your macOS version is 14.0 or later, that you have an API token for every commercial provider you plan to use, and whether you need iCloud Sync, because the debug build path disables it by default.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. Renset/macai on GitHub