comparison
AgentKit Cloud vs calling the SDK directly
Calling a provider SDK from the app is the fast path to a prototype. It also ships your key in the binary and bakes the model into the build.
Calling a provider SDK directly means the app talks to OpenAI, Anthropic, or Gemini with the key in the client.
| AgentKit Cloud | The provider SDK direct | |
|---|---|---|
| Model providers | Anthropic, OpenAI, Gemini, and Apple on-device | One provider per integration |
| Provider keys off the device | Encrypted server-side; the app ships a publishable key | The key ships in the app binary |
| End-user identity verified per request | A JWT from your trusted issuer, checked every request | Not provided |
| Hard spend cap per user | A hard ceiling per user and per project. Hit it, requests stop. | Not provided |
| Subscription-tier model routing | Bind tiers to RevenueCat entitlements | Not provided |
| Change models without an app update | Name a tier; remap it server-side | The model is hard-coded in the app |
| On-device option | Apple Foundation Models on-device, cloud when needed | Depends on the SDK |
| In-app agent loop with tools, guards, undo | Runs in your app with guards, undo, and run limits | You write the agent loop |
| Device attestation | Optional App Attest binds requests to real devices | Not provided |
| Backend to build and maintain | None. AgentKit Cloud is the backend. | You build everything server-side |
Keys do not belong in the binary
A shipped key can be extracted, and someone else's usage then lands on your bill with no cap. AgentKit holds keys server-side and caps spend per user, so a leak cannot become a surprise invoice.
Name a tier, not a model
Bind a tier like premium to a real model in the dashboard, and remap it any time. No App Store round trip to change a model.
Per-user control, no lock-in
Identity, usage attribution, and spend caps come built in, not built later. Your keys stay yours, and the same SDK calls the provider directly if you ever move off.