Native Models API vs BYO LLM vs Direct Callout: The Decision Guide

The scenario

Meridian Wealth is a mid-size wealth management firm. The advisory team wants AI-generated meeting prep notes on client accounts: portfolio changes, recent service cases, life events logged by advisors. Simple feature. Then legal joins the call.

Client financial data must not be retained by any model provider. Zero retention, in writing.
Compliance needs an audit trail of every prompt and response for seven years.
The data science team already fine-tuned a model on the firm's own advisory language, hosted with their cloud provider. They want it used.
Finance wants a predictable cost line, not a per-token surprise.

Suddenly "call an LLM from Apex" has three very different answers. This post is the map. The rest of the series builds each path hands-on.

The three paths

Path 1 — Native Models API. Salesforce hosts the model relationship. You call a Salesforce-managed model (OpenAI, Anthropic, Gemini and others) through the aiplatform Apex namespace or the REST endpoint. The Einstein Trust Layer sits in the path: data masking, toxicity scoring, audit trail, zero-retention agreements Salesforce has already negotiated. No endpoint, no key, no callout config. We covered this end-to-end in Call LLMs from Apex with the Models API — that post stays the reference for this path; we won't repeat it here.

Path 2 — Bring Your Own LLM (BYO LLM). You register an external foundation model — your Azure OpenAI deployment, an Amazon Bedrock or Google Vertex AI model, or an OpenAI account you contract directly — in Einstein Studio (Model Builder). Salesforce then treats it like any other model: it gets an API name, it's callable from the Models API, Prompt Builder and Agentforce, and requests still pass through the Einstein Trust Layer. Your contract, your model, Salesforce's governance. Part 2, Bring Your Own LLM: Register an External Model in Einstein Studio, builds this.

Path 3 — Direct external callout. Plain Apex HTTP callout to any model endpoint, authenticated with a Named Credential + External Credential. Maximum freedom: any provider, any parameter, any response shape, streaming, self-hosted models Salesforce has no connector for. Also maximum responsibility: no trust layer, no masking, no audit unless you build them. Part 3, Calling an External LLM from Apex, builds this — including when it's the wrong choice.

The decision table

Factor	Native Models API	BYO LLM (Einstein Studio)	Direct Apex callout
Model choice	Salesforce's supported model list only	Your deployment on supported providers (Azure OpenAI, Bedrock, Vertex AI, OpenAI)	Anything with an HTTP API — including self-hosted and fine-tuned models
Einstein Trust Layer	Yes — masking, toxicity scoring, audit built in	Yes — your model, Salesforce's trust layer in the path	No — you build masking, audit and safety yourself
Data retention terms	Salesforce's zero-retention agreements with providers	Whatever your contract with the provider says — you control it	Whatever your contract says — and nothing checks it for you
Data residency	Depends on Salesforce's model hosting	You pick the region when you deploy the model	You pick the region — full control
Cost model	Metered Salesforce AI credits/requests	Provider bill at your negotiated rates + Salesforce platform costs	Provider bill only — cheapest per token, but you build the controls
Latency	Trust layer adds a hop; fine for most UX	Trust layer hop + your provider's region	Shortest path — org to endpoint direct
Setup effort	Lowest — permissions and a few lines of Apex	Medium — provider setup + Model Builder registration	Highest — credentials, client class, retries, masking, audit, cost tracking
Governance burden	Mostly Salesforce's problem	Shared — contract yours, guardrails Salesforce's	Entirely yours

Rule of thumb: start at Path 1 and move right only when a named requirement forces you. "We might want our own model someday" is not a requirement. "Our regulator requires EU-region inference on our own tenancy" is.

The same call, three ways

Ignore the plumbing for a second — here is the shape of "summarize this text" on each path. The difference in what you own is visible in the code.

Path 1 and Path 2 look identical in Apex. That's the point of BYO LLM: once registered, your model is just another model name.

// Paths 1 & 2: Models API via the aiplatform namespace.
// Path 1 uses a Salesforce-managed model name; Path 2 uses the
// API name of the model you registered in Einstein Studio.
aiplatform.ModelsAPI.createGenerations_Request request =
    new aiplatform.ModelsAPI.createGenerations_Request();
request.modelName = 'sfdc_ai__DefaultOpenAIGPT4OmniMini'; // or your BYO model's API name

aiplatform.ModelsAPI_GenerationRequest body =
    new aiplatform.ModelsAPI_GenerationRequest();
body.prompt = 'Summarize in two sentences:\n' + inputText;
request.body = body;

aiplatform.ModelsAPI.createGenerations_Response res =
    new aiplatform.ModelsAPI().createGenerations(request);
String answer = res.Code200.generation.generatedText;

// Path 3: direct callout through a Named Credential.
// No trust layer — masking, retries, audit are now YOUR code.
HttpRequest req = new HttpRequest();
req.setEndpoint('callout:My_LLM/v1/chat/completions');
req.setMethod('POST');
req.setHeader('Content-Type', 'application/json');
req.setTimeout(120000);
req.setBody(JSON.serialize(new Map<String, Object>{
    'model'    => 'my-fine-tuned-model',
    'messages' => new List<Object>{
        new Map<String, Object>{
            'role' => 'user',
            'content' => 'Summarize in two sentences:\n' + inputText
        }
    }
}));
HttpResponse resp = new Http().send(req);

Two snippets, one honest observation: the Path 3 version above is not production-ready — it has no retry, no error taxonomy, no PII masking, no cost log. The full production version is Part 3; the hardening is Part 5. That gap is the real price of Path 3.

What Meridian chose — and why

Walk their four constraints through the table:

Zero retention in writing: all three paths can satisfy this — but with BYO LLM it's Meridian's own signed contract with their provider, which is exactly what their legal team wanted to hold.
Audit trail: the Einstein Trust Layer's audit and feedback data covers Paths 1 and 2 out of the box. Path 3 means building a custom audit object and hoping nobody bypasses the client class.
Their fine-tuned model: Path 1 is out — it only serves the Salesforce-managed list. Their model is deployed on a supported provider, so Path 2 works. Path 3 also works but buys nothing extra.
Predictable cost: their existing provider agreement has committed pricing. Paths 2 and 3 both use it.

Every constraint lands on Path 2: BYO LLM through Einstein Studio. Their fine-tuned model, their contract, their region — with Salesforce's masking and audit still in the path. The only work is the registration, which is Part 2 of this series.

When would the other paths have won?

Path 1 — if any current frontier model was acceptable and legal was satisfied by Salesforce's provider agreements. That's most orgs, most of the time. Start there.
Path 3 — if the model was self-hosted on infrastructure no BYO LLM connector reaches, or the use case needed request shapes the platform APIs don't expose. Real cases exist; Part 3 covers one.

The rest of the series

This post — the decision.
Bring Your Own LLM: Register an External Model in Einstein Studio — Path 2, hands on.
Calling an External LLM from Apex: Named Credentials, Retries, and When Not To — Path 3, hands on.
Grounding an External LLM on CRM Data — making any external model actually know your org.
Securing External AI: PII Masking, Prompt Injection, Cost and Audit — the hardening layer Paths 2 and 3 need.

Sources: Supported Models — official docs · Access Models API with Apex · Einstein Generative AI developer guide