OpenBMB reports MiniCPM-V 4.7 running on an iPhone 17 Pro Max at more than 13 tokens per second, with a 3 GB working memory footprint. Its listed Q4 KM model file is 21.2 GB.
The numbers describe different things. The 3 GB figure is the reported working memory footprint, not the size of the whole model or its download. OpenBMB does not say whether it measured a peak or an average.
Fewer Active Parameters, Same Model File
MiniCPM-V 4.7 has 35 billion parameters, but activates about 3 billion for each token. Using fewer parameters per token changes the work the model does for that token. It does not make the other parameters disappear from storage.
OpenBMB’s LESS system predicts which expert weights a later layer will need and starts loading them while the current layer works. The model still makes its own routing choice. OpenBMB also changes how weights are stored and uses different bit counts across layers.
Liquid AI’s LFM 2.5 makes the same distinction easy to see. It stores 24 billion parameters and uses 2.45 billion per token. A router picks four of 64 expert networks in each layer, but the other 60 still occupy memory. The file used for its 4-bit speed test is 14.5 GB.
I estimated that LFM 2.5 might run on a 32 GB laptop. That was an estimate, not a test. The stored file size and the parameters used for each token answer different questions.
The Detailed Speed Results Come From an iPad
OpenBMB’s step-by-step speed test used an iPad Pro 11-inch with an M4 chip and 16 GB of memory. Its reported speeds rose as the team added changes:
- Basic SSD loading: 2.97 tokens per second
- LESS scheduling and weight layout: 9.81 tokens per second
- Layer-wise quantization: 14.92 tokens per second
- D-Spark speculative sampling: 17.39 tokens per second
At the last step, a small draft model proposes tokens for the larger model to check. The progression begins with an unoptimized baseline, so it shows what these changes did in that iPad test.
There is no matching stage-by-stage table for the reported iPhone result. A separate iPhone study tested a different model and found minimal speedup from its own prefetch predictor. That does not settle OpenBMB’s phone claim; it does make the test setup important when reading the speed number.
The device result leaves two concrete questions: can independent tests reproduce the reported iPhone speed, and exactly what does the 3 GB memory figure count?
A Coding Agent Can Go Back to a Better Checkpoint
The script’s other technical result concerns a different kind of memory: what a coding agent keeps from earlier work. A user can change a requirement while the agent is working from a current version that no longer fits as well as an earlier one.
Git Harness saves each requirement state with a checkpoint. When instructions change, the agent can choose a compatible earlier version, modify it, or start fresh. In the authors’ tests, it beat the Native baseline in all 30 settings and matched or beat the strongest competing baseline in 28.
On coding tasks with DeepSeek V4 Flash, solved-task rates rose from 67 to 74 with Stack Planner, 64 to 72 with OpenHands, and 56 to 62 with TCRag. One test gives the earlier-version choice particular weight: forcing the system to continue from the current version cut its code resolve rate from 74.0 to 44.0.
Those results are about the tested setups. They do not mean every changed instruction needs a rollback. They show why the choice of starting point mattered in these tests.
The Token Bill Did Not Fall Everywhere
In one Stack Planner setup, token use fell from about 4.90 million to about 1.29 million. Listed API cost fell from $2.28 to $0.63. That is a large difference for that setup, alongside the higher solved-task rate reported for Stack Planner’s coding tasks.
The cost pattern was not uniform. On math tasks, token use rose from 43.13 thousand to 59.98 thousand, though accuracy rose too. The authors have not released the code, and parts of the implementation remain undocumented.