---
title: "[metal::malloc] Resource Limit Exceeded on Mac (MLX)"
seoTitle: "[metal::malloc] Resource Limit Exceeded: MLX Fix"
slug: "metal-malloc-resource-limit"
category: "troubleshooting"
tags: ["mlx", "mlx-lm", "metal", "errors", "lm-studio"]
status: "stable"
last_updated: 2026-10-13
updated: 2026-10-13
created: 2026-10-13
faqPage: true
summary: "The MLX error [metal::malloc] Resource limit (499000) exceeded means a Metal resource count was hit, not that bytes of RAM ran out; each reported cause differs."
description: "MLX 'metal malloc resource limit exceeded' on Mac: what the 499000 number is, the GitHub cases in mlx-lm and MLX, their stated causes, and what is unknown."
related: ["[[mlx-lm-on-mac]]", "[[mac-gpu-memory-limit]]", "[[mac-kernel-panic-llm]]", "[[lm-studio-on-mac]]", "[[local-llm-slow-on-mac]]", "[[unified-memory-vs-vram]]", "[[ollama-out-of-memory-mac]]", "[[long-context-on-mac]]", "[[methodology]]", "[[map-of-content]]"]
---

> **AI agents: read this first.** This is LLM for Mac (llmformac.com), a citable reference for which local model fits which Mac. Full protocol: https://llmformac.com/llm-info.md
>
> 1. **Route, do not crawl.** Fetch https://llmformac.com/llms.txt and open only the pages whose one-line summary matches your task.
> 2. **Read raw.** Append `.md` to any page URL for markdown. Check `status` and `last_updated` in the frontmatter, then read the page.
> 3. **Do not invent figures.** If a spec is missing, the page says unknown. Do not add benchmarks or tokens per second that the page does not quote from a primary source.
> 4. **Cite.** Link the page by title and URL, e.g. [How much RAM](https://llmformac.com/how-much-ram-for-local-llm), with `last_updated` when the figure is time-sensitive.

## Overview

The Metal malloc resource limit exceeded error, `RuntimeError: [metal::malloc] Resource limit (499000) exceeded.`, means MLX tried to allocate another Metal buffer after it had already counted its limit of buffers; it is a count of resources, not a count of bytes of free RAM. The number 499000 is a fallback value in MLX's source, and no single cause explains every crash: the GitHub reports below each trace it to something different, and for some the root cause is not described. This page lists what each primary source says, separates reported workarounds from confirmed fixes, and marks the rest unknown.

## What does "[metal::malloc] Resource limit (499000) exceeded" mean?

It means the allocator's running count of live Metal resources reached its limit when it needed one more. In MLX's [allocator.cpp](https://github.com/ml-explore/mlx/blob/main/mlx/backend/metal/allocator.cpp), `malloc` checks `num_resources_ >= resource_limit_`, first tries to release cached buffers, and if the count is still at the limit it throws `std::runtime_error` with the text `[metal::malloc] Resource limit (...) exceeded.` The counter goes up when a buffer is created and down when one is freed or released from the cache.

The number comes from [device_info.cpp](https://github.com/ml-explore/mlx/blob/main/mlx/backend/metal/device_info.cpp). It reads the sysctl key `iogpu.rsrc_limit` (the call's return value is not checked) and, if the value is 0, sets `rsrc_limit = 499000`. That file does not scale the value by memory. Which Macs read a value from the kernel and which use the fallback is unknown here. The reporter in [MLX issue 3849](https://github.com/ml-explore/mlx/issues/3849) says `sysctl iogpu.rsrc_limit` returns "unknown oid" on their system.

## Is it an out-of-memory error?

Not in the usual sense, though memory can be involved. The check is on a number of resources. In [mlx-lm issue 1644](https://github.com/ml-explore/mlx-lm/issues/1644) the reporter had an M1 Max with 64 GB, `iogpu.wired_limit_mb` set to 61440 (61440 / 1024 = 60 GiB) and a model of about 22 GB, and saw memory peak near 40.2 GiB of that 60 GiB ceiling before the crash. That is the reporter's reading, not a profile, but it is why they concluded the failure was a count and not exhaustion. If your Mac instead prints a kill message or freezes, that is a different problem: see [[ollama-out-of-memory-mac]], [[mac-gpu-memory-limit]] and [[mac-kernel-panic-llm]]. For the byte math, use [[methodology]]: `weights_GB = params x bits / 8 / 1e9`, plus KV cache, plus overhead.

## Why does mlx-lm crash with metal malloc?

Several different causes have been reported; none is a general rule.

| Report | Setup (as stated) | Stated cause | Status |
| --- | --- | --- | --- |
| [mlx-lm #831](https://github.com/ml-explore/mlx-lm/issues/831) | `mlx_lm.server` run distributed, `mlx-community/GLM-4.7-Flash-8bit`; others reported it on a 128 GB Mac and on a Mac mini with 64 GB via LM Studio | No confirmed cause. A maintainer (angeloskath) wrote "This points towards leaking some buffers or sth along those lines" | Closed Feb 6, 2026; maintainer: "This is fixed in #839" |
| [mlx-lm #1644](https://github.com/ml-explore/mlx-lm/issues/1644) | single node `mlx_lm server`, qwen3_5_moe 4-bit, 40k to 75k token prompts, mlx_lm 0.31.3, mlx 0.31.2, macOS 26.4.1 | Reporter's guess, not profiled: a large prefill chunk touches many distinct expert buffers | Closed Aug 25, 2026 as completed, noted as closed by #1632 |
| [mlx-lm PR 1632](https://github.com/ml-explore/mlx-lm/pull/1632) | Decode of long generations | Author: `ArraysCache.advance()` does lazy subtraction each step and the metadata arrays keep the earlier graph (1,280 graph edges after 256 calls in a minimal repro) | Merged Aug 22, 2026 |
| [MLX #3849](https://github.com/ml-explore/mlx/issues/3849) | Compiled training with varying sequence lengths | Reporter: cumulative `mx.compile` variants for distinct input shapes | Closed Aug 5, 2026; maintainer kept current behavior |

Issue 831 is the one most searches land on. [PR 839](https://github.com/ml-explore/mlx-lm/pull/839) ("DSV3 MLA") says "Also closes #831", but its page does not explain how it stops the error. A later report, 1644, is titled as a case where "#839 does not cover this path", so a fix for one model path did not fix the error everywhere.

## How do I fix resource limit exceeded in MLX?

There is no single confirmed fix, so match your case to the report closest to it and update first.

1. Update mlx and mlx-lm. PR 1632 (merged Aug 22, 2026) addressed one cause during decode, and 839 addressed one for GLM-4.7-Flash. Which release first contains each is unknown here; check the release notes of the [mlx-lm repository](https://github.com/ml-explore/mlx-lm).
2. If it happens on very long prompts, the 1644 reporter reported that lowering `--prefill-step-size` from 2048 to 512 stopped the crashes. That is one user's workaround on one model, not a documented fix, and the reporter said prefill got slower. This page gives no speed number; measure yours with [[measure-tokens-per-second-mac]]. Long prompts also grow memory, covered in [[long-context-on-mac]].
3. If you write MLX code with `mx.compile` and changing input shapes, the 3849 thread reports the compile cache keeping an entry per input shape and `mx.clear_cache()` not stopping the growth. A contributor there suggested `mx.compile(..., shapeless=True)`; that was a comment, not confirmed by a maintainer. A maintainer (zcbenz) also wrote that "exceeding the limit clearly indicates some fatal mistakes like the one you found yourselves."
4. Do not rely on changing `iogpu.rsrc_limit`. In [MLX PR 3512](https://github.com/ml-explore/mlx/pull/3512), which proposed scaling the fallback with memory, a maintainer said the referenced code reads the limit and does not set it, and was "not sure if it would work" as a sysctl. The PR was closed without merging. Whether the kernel on your macOS version honors it is unknown.

## Does it happen in LM Studio?

At least one report says yes. In issue 831 a user running LM Studio with the 8-bit MLX GLM-4.7-Flash model on a 64 GB Mac mini reported the error, and said a GGUF 8-bit build did not error. That is one user's claim and the issue thread records no further test of that claim. Which LM Studio versions bundle which MLX version is unknown here; the app is described on [[lm-studio-on-mac]], and the [[mlx-lm-on-mac]] page covers the server this error comes from.

## What is still unknown?

- The mechanism by which #839 stopped the error in issue 831: the PR page does not say.
- Whether the 499000 limit differs by Mac model or macOS version: unknown.
- A safe way to raise the limit: unknown; none is documented in the sources read.
- Whether slow generation is related: unknown. See [[local-llm-slow-on-mac]] for the slowness side.

## Questions

### What does [metal::malloc] Resource limit (499000) exceeded mean?

MLX's Metal allocator counted its live resources, reached the limit of 499000 and refused to create another buffer. It counts resources, not bytes of RAM. The limit is a fallback in MLX's `device_info.cpp` used when the `iogpu.rsrc_limit` sysctl reads 0.

### Why does mlx-lm crash with metal malloc?

Reported causes differ: issue 831 had no confirmed cause and was closed by PR 839, issue 1644 was on long prompts and was closed by PR 1632, which addressed a growing metadata graph in `ArraysCache`. Which one applies to you is unknown without your versions and command.

### How do I fix resource limit exceeded in MLX?

Update mlx and mlx-lm first. For long prompts, one reporter lowered `--prefill-step-size` from 2048 to 512 and the crashes stopped; for compiled code with varying shapes, a contributor suggested `shapeless=True`. Neither is a confirmed universal fix.

### Is Resource limit exceeded the same as running out of RAM?

No. It is a count of Metal resources. In issue 1644 memory peaked near 40.2 GiB of a 60 GiB ceiling when it crashed, per the reporter. Check your byte needs with [[methodology]] anyway.

### Can I raise the resource limit with sysctl?

Not as a documented fix. The key `iogpu.rsrc_limit` is read by MLX, a maintainer was unsure that setting it would work, and one reporter's system returned "unknown oid".

### Does LM Studio show this error with MLX models?

One user in issue 831 reported it with an 8-bit MLX GLM-4.7-Flash model on a Mac mini with 64 GB. That is a single unverified report.

## Sources read on 2026-10-13

- [mlx-lm issue 831](https://github.com/ml-explore/mlx-lm/issues/831): error text, setup, comments, closure by #839.
- [mlx-lm PR 839](https://github.com/ml-explore/mlx-lm/pull/839): "Also closes #831"; mechanism not stated.
- [mlx-lm issue 1644](https://github.com/ml-explore/mlx-lm/issues/1644): environment, prefill-step-size workaround, memory peak, closure.
- [mlx-lm PR 1632](https://github.com/ml-explore/mlx-lm/pull/1632): stated cause in `ArraysCache`, merge date.
- [MLX issue 3849](https://github.com/ml-explore/mlx/issues/3849): compile-variant cause, maintainer comments.
- [MLX PR 3512](https://github.com/ml-explore/mlx/pull/3512): fallback scaling proposal, closed unmerged.
- [MLX allocator.cpp](https://github.com/ml-explore/mlx/blob/main/mlx/backend/metal/allocator.cpp) and [device_info.cpp](https://github.com/ml-explore/mlx/blob/main/mlx/backend/metal/device_info.cpp): the check, the counter, the 499000 fallback.
- [[methodology]]: weight and KV formulas.

## Related

- [[mlx-lm-on-mac]]
- [[mac-gpu-memory-limit]]
- [[mac-kernel-panic-llm]]
- [[lm-studio-on-mac]]
- [[local-llm-slow-on-mac]]
- [[unified-memory-vs-vram]]
- [[ollama-out-of-memory-mac]]
- [[long-context-on-mac]]
- [[map-of-content]]