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

What macai solves for people who juggle several LLM accounts

Most chat clients assume one provider. If you hold an OpenAI key for one task, an Anthropic key for another, and run llama3.1 locally through Ollama for anything you would rather not send over the network, you end up with three browser tabs and three sets of conversation history. macai's stated purpose is to collapse that into a single native macOS application. The README lists ChatGPT, Claude, xAI (Grok), Google Gemini, Perplexity, Ollama, OpenRouter, and "almost any OpenAI-compatible APIs" as supported backends.

The audience is narrow and specific. This is a desktop app for macOS 14.0 and later, on both Intel and Apple chips. It is not a web service, not a mobile client, and not a gateway you deploy for a team. The README frames the value as macOS-native and lightweight, with a minimalist light and dark UI, and it explicitly says macai itself collects no telemetry or usage tracking. That last point matters if your objection to hosted chat UIs is the data path rather than the model. The README also notes that Apple may collect anonymized telemetry when iCloud Sync is enabled, so the privacy claim is conditional on that setting.

The architecture visible in the repository: SwiftUI app, provider adapters, optional CloudKit

The repository layout is a single Xcode project. The top level holds macai.xcodeproj, a macai/ source directory, plus macaiTests/ and macaiUITests/, with a .swift-format config and a GitHub Actions workflow at .github/workflows/swift-xcode.yml. There is no server component, no Dockerfile, and no separate daemon. The app is the whole product.

Provider support is organized around API services that you configure yourself. The README's Ollama walkthrough tells you to open the API Service tab in settings, add a new API service in Expert mode, and select the Ollama type. That implies a service-type field that switches the request shape, with a generic OpenAI-compatible path for everything that is not a first-class provider. Credentials live in the app rather than in a proxy, which is the trade-off: simpler to set up, but every machine needs its own keys.

State is local by default. iCloud Sync is the optional layer, built on CloudKit entitlements, and it is gated at compile time. Debug builds disable it through the DISABLE_ICLOUD compiler flag so contributors without an Apple Developer account can build; Release builds enable it. That is a deliberate split between contributor ergonomics and shipped behaviour, and it is the single most important architectural detail in the README.

Installing macai and connecting a first model

There are two install paths. The manual path is a universal binary from the releases page, which the README says is notarized by Apple. The Homebrew path is a cask:

brew install --cask macai

That command installs the app through Homebrew's cask mechanism rather than building from source. After it finishes, macai appears in your Applications folder like any other macOS app.

For a hosted provider, the README is direct about the precondition: you need an API token, described as being like a password. It links to the token-issuing documentation for OpenAI, Claude, Google Gemini, xAI Grok, and OpenRouter. Most of those services offer free credits on registration, so you can evaluate without paying up front.

For a local model, the flow runs through Ollama. Install Ollama from its official site, then pull a model in a terminal. The README recommends llama3.1 or llama3.2, using this command:

ollama pull <model>

Once the model is on disk, open macai settings, go to the API Service tab, add a new API service in Expert mode, and choose the Ollama type. Then select the model, set it as the default AI Assistant, and save. The README's last step is simply to test it.

Building from source, and the iCloud Sync trap for forks

If you want to modify macai, the build instructions branch on whether you have an Apple Developer account. With an account, you clone the repository, open macai.xcodeproj in Xcode, select your team under Signing & Capabilities, and build. iCloud Sync in Debug builds requires removing DISABLE_ICLOUD from Active Compilation Conditions.

Without an account, the README gives a command-line route that strips the iCloud entitlement:

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

This swaps CODE_SIGN_ENTITLEMENTS from macai/macai.entitlements to macai/macai-no-icloud.entitlements and disables signing entirely. The README states the resulting app works normally except that iCloud Sync is unavailable; chat, API services, and personas are unaffected. The Xcode-only equivalent is to change the same CODE_SIGN_ENTITLEMENTS value and set the signing certificate to "Sign to Run Locally."

The trap is for anyone maintaining a fork. If you fork macai and want sync in your own builds, you need your own CloudKit container and entitlements, and the README's fork section is where that discussion begins rather than ends. Budget for that before you assume sync will carry over.

Where macai is the wrong choice

The macOS 14.0 floor is a hard constraint, not a suggestion. Anything older is out, and there is no Linux or Windows build anywhere in the repository layout.

The bigger limitation is scope. macai is a client, not a gateway. Your API tokens sit in the app on each machine, so there is no central place to rotate a key, audit who used which model, or cap spend. If your requirement is a shared workspace where teammates see the same conversation history, macai does not provide it; iCloud Sync is tied to your personal Apple account and CloudKit container, not to an organization.

The feature list is also broader than the README's depth. Vision, image generation, search, reasoning, and import/export are named in the Why macai section, but the README does not document how each one behaves per provider, and it does not document rollback or version pinning for a cask install. If you need guaranteed behaviour on a specific model version, you are relying on the provider's side, not macai's.

Finally, the README does not describe a rate-limit or retry policy. If you are driving long batch conversations through a paid API, that is unverified territory and worth testing yourself before you depend on it.

macai versus Open WebUI and other multi-provider front ends

The obvious comparison is a self-hosted browser front end such as Open WebUI. The difference is where the process runs and who owns the credentials. Open WebUI is a server you deploy; users reach it through a browser, accounts and model access are managed centrally, and the API keys live on the server rather than on each laptop. macai inverts all of that. It is a per-machine app, keys are per-machine, and there is nothing to deploy.

That inversion decides the choice. If you are administering models for a group, a server-side front end gives you one place to change a key and one place to see usage. If you are one person on a Mac who wants a native window and a local Ollama model alongside hosted ones, macai's model is simpler because there is no infrastructure at all. The cost is that you give up central control, and you give up access from any device that is not a signed-in Mac.

A second comparison point is the generic OpenAI-compatible client. macai supports that category, so it can stand in for a single-provider desktop app, but the reason to pick it over one is the multi-provider settings screen and the Ollama integration, not any protocol advantage.

Maintenance, release cadence and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-08-16, which is recent enough that the README's claim of active development is consistent with the commit history. The release history shows v2.4.3 on 2026-08-16, v2.4.2 on 2026-01-16, and v2.4.0 on 2026-01-14. That is a burst in mid-January followed by a seven-month gap and then a single patch release. Contributors should read that cadence honestly: the project moves when the maintainer has time, and the README's funding link suggests that is a factor.

Upgrade cost is low for cask users. Homebrew handles the version bump, and the app's own data lives locally, so there is no migration step described. Source builders carry more: Xcode project settings, signing, and the DISABLE_ICLOUD flag are all things you re-verify on each pull.

The licence is Apache-2.0, per LICENSE.md at the repository root. That permits commercial use and modification, and it includes an explicit patent grant, which matters if you plan to redistribute a modified build. It does not grant trademark rights, so a fork should not ship under the macai name. This is a description of the licence text, not legal advice; if you intend to redistribute, read LICENSE.md and the NOTICE requirements yourself.

Editorial conclusion

Adopt macai if you are a macOS 14+ user who already holds API tokens and wants one native window for both hosted models and a local Ollama server. Do not adopt it if you need a browser client, a shared team workspace, or a build with iCloud Sync but no Apple Developer account, since Debug builds ship with DISABLE_ICLOUD set. Before committing, verify that your provider is reachable through the Expert mode API Service tab, confirm the model you intend to use is pulled locally if you are on Ollama, and decide whether you want the Homebrew cask or the notarized universal binary from the releases page.

Frequently asked questions

Official sources

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