The fix for MacBook Neo cursor lag circulating this week is a Swift app that opens a ScreenCaptureKit stream, captures a one-pixel frame every 10 seconds, and throws it away. The “Unlag Neo” gist writes nothing to disk. It appears to work by refusing to let the display pipeline sit idle, though why that cures the lag is the part nobody has confirmed.
What does the Unlag Neo gist actually do?
The “Unlag Neo” app is a 1-by-1-pixel ScreenCaptureKit capture loop that produces no output and fires roughly every 10 seconds. The gist ships a create_unlag_neo_app.sh script that compiles a Swift binary into a .app bundle with no Xcode and no developer account. The program configures a single SCStream aimed at a one-pixel sourceRect at the origin, with width and height of 1, a minimumFrameInterval of 10 seconds, a queueDepth of 4, audio capture off, and showsCursor = true. When the first frame arrives, the delegate prints “Receiving frames every 10 seconds and dropping them” and then ignores every frame after that. The intent is stated plainly in the source: “Record 1 pixel every 10 seconds (to /dev/null basically, no SSD write).”
The app itself is a menu-bar status item. It runs an accessory activation policy, so it never appears in the Dock, and it offers a “Launch at Login” toggle backed by SMAppService. It also watches for wake, front-app changes, and display-configuration changes, restarting the capture each time, since a stream that dies silently would let the lag creep back.
The visible cost is a screen-recording indicator dot in the menu bar. macOS shows that dot any time a process is capturing the screen, whether or not frames are saved, so the trick necessarily trades a clean menu bar for a lag-free cursor. The app’s “Pause in Fullscreen” toggle uses an Accessibility observer on the frontmost app’s windows, with a CGWindowList fallback, to detect a full-screen window and stop the capture, hiding the dot during video playback.
Before it runs, the app demands two permissions: Screen Recording, requested through CGPreflightScreenCaptureAccess() and CGRequestScreenCaptureAccess(), and Accessibility, requested through AXIsProcessTrustedWithOptions. Both are prompted at first launch and must be granted in System Settings.
When and where does the MacBook Neo cursor lag?
The MacBook Neo is Apple’s budget Mac: a 13-inch laptop on the A18 Pro chip with a 6-core CPU, 5-core GPU, and 8GB of RAM, listing from $599 for 256GB to $699 for 512GB at retail, and it is the machine where these reports are concentrated. Per the gist author, the lag appears in two specific situations on a unit running macOS Tahoe 26.5.1: when the cursor nears the screen’s edges, and when it enters a Terminal window. The author observes that the lag coincides with macOS switching from a hardware cursor to a software cursor, visible as CGCursorIsDrawnInFramebuffer() moving from 0 to 1.
The distinction matters. The hardware cursor is drawn on a dedicated overlay plane, which the display controller can move without re-rendering the rest of the frame, so pointer motion stays cheap. The software cursor is composited into the frame by WindowServer, the process that sits between running applications and what reaches the display, which means cursor motion can force compositing work. Hacker News commenters point out that this overlay-plane model is shared across every Apple Silicon Mac since the M1, because they all run the same iPhone-derived architecture, so the Neo is not doing anything structurally novel with the cursor.
The two trigger cases fit that model, at least as the author sketches them. At a screen edge, only part of the cursor can sit on the overlay plane, which may push the system to composite it instead. Inside Terminal, the text rendering may do the same. The author offers both explanations explicitly as guesses; the source literally reads “idk.” The geometry is a candidate, not a conclusion.
The strongest clue is timing. The author reports that the hardware cursor only engages about 17 seconds after the screen is unlocked, and that there is no lag before that point. Where the cursor sits may simply be where the symptom is most visible; the trigger looks time-dependent.
Why does a one-pixel capture fix it?
The connection between a discarded one-pixel frame and a smooth cursor is not obvious, and nobody with direct knowledge of MacBook Neo hardware has confirmed it. The gist author writes “I don’t know” under the heading “Why is it lagging?”, and the community explanations that follow are hypotheses rather than findings.
The leading hypothesis, from the Hacker News thread on the gist, is that the lag occurs during the handoff from hardware to software cursor. A commenter who has written GPU drivers speculates that the stall comes from waiting for the GPU command queue to flush when the system switches cursor modes. Flushing is the crux: a hardware cursor on an overlay plane and a software cursor composited into the frame travel through different paths, and switching between them can force the pipeline to drain pending work before it resumes. The same commenter explicitly disclaims direct knowledge of the Neo and says confirming the cause would require reverse engineering WindowServer, a step the gist author notes would likely mean disabling System Integrity Protection.
If that read holds, the one-pixel capture works because an active ScreenCaptureKit stream forces WindowServer to keep compositing frames on a steady cadence instead of gating the pipeline down. One detail in the gist’s own code supports this: the stream is configured with showsCursor = true, so the cursor is composited into each captured frame, which means the software-cursor path has to stay live for the stream to deliver anything at all. Holding that stream open may keep the code path that handles the software cursor warm, so the hardware-to-software transition no longer stalls. The author’s own phrasing hedges the same way: “Essentially anything that forces the compositor(?) to do SW cursor (or whatever else) will do.” The question mark is in the original.
The 17-seconds-after-wake observation is the author’s, not a commenter’s, and it is the cleanest evidence in the whole thread. For the first 17 seconds after wake, the hardware cursor is not yet active, which means the cursor is running in software mode the entire time, and there is no lag. The stutter only appears once the hardware cursor engages and the system starts transitioning between modes. That pattern fits the transition-stall hypothesis directly: when there is no hardware cursor to hand off from, there is no handoff to stall. It is still inference rather than proof, but it is the closest thing to confirmation the source material offers. The gist’s list of alternative fixes points the same way: enabling a macOS Color Filter, or making the cursor significantly larger, also stops the lag, and both are changes that force the compositor to treat the cursor differently.
How is this different from BetterDisplay or DisplayLink cursor lag?
Cursor stutter on Apple Silicon predates the Neo, and most of the prior reports trace to a different root cause. The BetterDisplay maintainer states that cursor issues under virtual screen mirroring, Sidecar, and DisplayLink have affected Apple Silicon Macs (but not Intel) since macOS Monterey 12.4, and that Apple has not fixed them despite community requests. In that same thread, mismatched refresh rates are flagged as a possible aggravator: a 60Hz virtual screen paired with a 75Hz display is the cited example, and matching both to 60Hz reduces but does not eliminate the stutter.
The Neo case involves neither mirroring nor a third-party display driver. It is the built-in panel and the built-in cursor, which is what makes the one-pixel workaround worth attention: it implicates the native compositor and cursor path rather than a driver shim. Conflating the two would be a category error. The BetterDisplay family is a driver and mirroring problem that happens to share a symptom; the Neo report is an idle or transition problem in stock macOS on stock hardware. That Apple Silicon and not Intel shows the BetterDisplay variant is consistent with the overlay-plane cursor model carrying over from iOS, but that is shared architecture, not a shared bug.
What is the real takeaway for developers?
The one-pixel capture is best read as a diagnostic probe into macOS compositor behavior, not as a finished fix.
For a developer hitting the Neo lag today, the gist is immediately useful: compile the app, grant the two permissions, and the stutter stops. The more durable lesson is the technique underneath it. A minimal ScreenCaptureKit stream pointed at a tiny region on a long interval is a cheap way to force the compositor to stay active, and that pattern generalizes beyond this one bug. Anyone debugging display-pipeline timing, cursor behavior, or power-gating regressions on macOS can reach for the same lever: open a throwaway capture, observe what changes, close it, observe again. The CGCursorIsDrawnInFramebuffer() readout the author relied on is the other half of the probe, a single function call that reports which cursor mode is live at the moment the lag bites.
A one-pixel recording that runs forever, demands two sensitive permissions, and leaves an indicator in the menu bar is the kind of fix that ships when a vendor stays quiet. Apple has not addressed the Neo lag, and the gist’s own “Proper fix” section names two ways forward: Apple fixes the lag directly, or someone forces permanent software-cursor mode by reverse engineering WindowServer. Until one of those happens, a one-pixel recording every 10 seconds is the best the community has.
Frequently Asked Questions
Does running the one-pixel capture carry a battery cost on the Neo?
Forcing a ScreenCaptureKit frame every 10 seconds keeps the display pipeline from gating down, which on a 13-inch laptop on battery is a continuous small draw rather than a one-time hit. The gist author does not publish a measured runtime or watt delta, so the real cost is unquantified.
Can I safely change the 10-second interval or queue depth in the gist?
The 10-second minimumFrameInterval and queueDepth of 4 are the author’s empirical picks, not values derived from a documented macOS timer. Lengthening the interval risks a gap long enough for the hardware-to-software transition to stall again; shortening it raises wake-up frequency and battery cost without a confirmed benefit.
How would a developer detect the cursor-mode transition without the gist?
CGCursorIsDrawnInFramebuffer() is a plain CoreGraphics call that reports whether the cursor is drawn in the framebuffer (software mode) or on a hardware overlay plane. Logging its 0-to-1 transitions against a timestamp is exactly how the gist author isolated the 17-second post-wake window, and it works as a standalone probe with or without a capture stream running.
What would make this workaround obsolete?
A macOS update that patches the lag directly would retire the capture loop overnight. The author’s 17-second post-wake figure also implies the stutter is tied to a specific idle or power-state timer in the display pipeline, so a change to that timer in a future build could quietly shift or break the trick without Apple touching the cursor code.
Do I need Xcode or a paid developer account to build the Unlag Neo app?
The build relies on swiftc, which ships with Apple’s free Command Line Tools rather than requiring a full Xcode install or a paid Apple Developer membership. The Screen Recording and Accessibility prompts the app raises are runtime user grants, not code-signing entitlements, which is why an unsigned, locally compiled binary can request them at all.
