Skip to content
Back to blog
IAHomelabLaravel

Ollama defaults to MLX on Apple Silicon

Ollama now selects MLX automatically for supported model architectures on Apple Silicon.

Ismael Catala3 min read

The runtime changes without changing your client

When I use an Apple Silicon Mac as a local AI node, I do not want every upgrade to turn into a runtime-selection exercise. Ollama 0.40.0-rc0 changes that for compatible model architectures: on Apple Silicon, models supported by the MLX runtime will use it automatically. Existing Ollama commands, API endpoints, and clients do not need to change for that to happen.

That is useful in a homelab where the Mac runs inference and other services consume its local API. A coding assistant, an automation workflow, or a Laravel application can keep talking to Ollama in the same way. The important change happens below the application layer, where Ollama chooses the runtime when the hardware and model are compatible.

A small local check first

The release notes use qwen3.8 as the example model. It is a straightforward way to confirm that Ollama is working before adding Docker, reverse proxies, or another interface on top. If the model is not already present, pull downloads it and run starts a local chat session.

ollama pull qwen3.8
ollama run qwen3.8

There is no extra flag in those commands to request MLX. Automatic selection depends on running on Apple Silicon and on the model architecture being supported by that runtime. Ollama also notes that more models will be tested and enabled during this pre-release period.

Calling the local server from Laravel

For a Laravel application, the integration point is Ollama’s local API at http://localhost:11434/api. The /api/chat endpoint accepts a model, a messages array, and the stream option; setting it to false returns one complete JSON response, which keeps an initial HTTP integration simple. Laravel’s HTTP client provides timeout, post, and throw, which are enough for a small first implementation.

use Illuminate\Support\Facades\Http;
 
$response = Http::timeout(120)->post('http://localhost:11434/api/chat', [
    'model' => 'qwen3.8',
    'messages' => [
        [
            'role' => 'user',
            'content' => 'Summarize this ticket and suggest the next steps.',
        ],
    ],
    'stream' => false,
]);
 
$body = $response->throw()->json();
 
return $body['message']['content'];

With this approach, Laravel does not need to know whether Ollama is using MLX or another runtime. The application sends a local HTTP request and reads the response content. That separation also makes it easier to replace the model later without rewriting the integration layer.

The limitations worth keeping in mind

Not every model will move to MLX automatically, because the change only applies to architectures supported by the MLX runtime. It also does not make every Mac suitable for every model or context size; available memory is still a practical constraint. Test the exact model and the actual workload before making it part of a critical workflow.

This is a release candidate, not a final release. Ollama says it will continue testing and enabling additional models during the pre-release period, so the scope may change before a stable version is published. If this Mac is part of an important service, testing the upgrade outside production first is still the sensible option.

Finally, localhost only reaches the same machine. If Laravel runs on a different host, in a virtual machine, or inside a container, that address will not automatically point to the Mac running Ollama. Before exposing the service over the network, review the network boundary, access control, and the data being sent to the local model.

Keep reading