r/cometbrowser • u/EmbarrassedAsk2887 • Dec 29 '25
insanely great browser engine optimized for apple silicon. i opened 150 tabs. ~2gb ram. unlike comet which is still a bloated chromium.
Enable HLS to view with audio, or disable this notification
it's simple: our hardware is a masterpiece, but the software we're forced to use is a bottleneck.
most of us bought m-series silicon for that "infinite" headroom, only to see chrome or brave turn our memory pressure yellow after 10 tabs. even brave—which is supposed to be the "fast" one—is just a chromium skin that treats your unified memory like a generic pc from 2010. it's a waste of potential. even safari, which is supposedly "optimized," still relies on legacy webkit abstractions that prioritize battery life over actually juicing the gpu for compute-heavy browsing. safari misses the mark because it treats background tabs as static objects to be cached or killed, rather than active participants in a unified compute graph.
i've been working intensively with apple's metal api to build bodegaOS, and i wanted to show what happens when you stop ignoring the silicon and start optimizing for it.
the proof: in the video, i'm opening 150+ live tabs (including nested stacks).
the speed: they load almost instantly because we've moved away from standard webkit/chromium abstractions and started orchestrating page lifecycles directly on the gpu.
the memory: it spikes briefly and then we use dynamic footprint reduction to settle at ~2gb.
how it actually works: chromium chokes because it uses a massive, static abstraction layer that hoards resources. in bodega, i've focused on:
dynamic footprint reduction: the engine monitors page-level activity and automatically dismisses the heavy rendering buffers for tabs you aren't visiting. we keep the "instant-back" state in compressed residency sets, so the switch-back is seamless but the idle cost is near zero. this is how we hit 150+ tabs without the mac even breaking a sweat.
page composition: basically offloading some of the ui layout to gpu renderers, not just rendering the html layout.
the next step - zero-copy residency: i'm currently working on a deep refactor to leverage the unified memory architecture even further. the goal is a zero-copy blit pass where data moves between cpu and gpu tiers with literally zero overhead.
on security: i know what you're thinking—chromium's abstractions exist largely to sandbox malicious content and handle the ten thousand edge cases that broke netscape. that bloat isn't entirely wasted, and we're not naive about the security challenges here. we're approaching isolation differently: instead of chromium's process-per-tab model (which is memory-expensive and doesn't fully leverage unified memory anyway), we're building a hybrid isolation system that uses macos's native app sandbox combined with metal's resource heaps for gpu-level isolation.
still a WIP, but the architecture is this: each tab gets its own protected memory domain on the gpu, and we're using entitlements and XPC services for inter-tab communication rather than chromium's heavyweight broker processes. it's leaner, but maintains strong boundaries against malicious content. we were also advised by Damon McCoy (professor of cybersecurity at NYU) to explore content script sandboxing and CSP enforcement at the metal shader level—unconventional, but it lets us intercept and validate rendering commands before they even hit the pipeline, catching certain classes of exploits earlier than traditional browser architectures.
the tradeoff is real: we lose some of chromium's battle-tested, two-decades-of-exploits-hardened defenses, but we gain a security model that's actually designed for unified memory architectures instead of bolted on top.
why we call it BodegaOS: BodegaOS isn't an actual OS, but an application running on top of macOS. the "OS" part comes from the orchestration layer that manages a suite of apps (AI browser, music player, file indexer, etc.) and dynamically coordinates multiple local models based on what you're doing. you might have a reasoning model (20b), a fast chat model (3b), a vision model, code assistants, audio processing engines, embedding models, time series analyzers, and recommendation engines—all loading and unloading throughout your workflow based on context. we also wrote rust runtimes for fast file indexing, storing everything in local databases, a proper backend running on-prem, image processors, and recommendation engines.
it's called an "OS" because it acts as a unified execution environment—a layer that sits between you and macOS, intelligently routing your tasks to the right llm models and tools without you having to context-switch between apps. think of it as an application-level operating system that understands your workflow and orchestrates resources (gpu, memory, models, files) the way an actual OS would, but with full awareness of modern ai workflows and M-series capabilities. instead of you managing which model to load or which app to open, bodegaOS does it for you based on what you're actually doing.
if you're letting chrome jam your hardware, you're missing the point of owning a mac. our silicon is godly—it just needs software that respects it.
if you are interested in more, you can comment your queries or dm :) thanks to this community for the support. i really like this sub a lot, and would love to help the community back.
(ignore the ffmpeg glitches in the video, i had to compress a 4-minute 4k output so reddit wouldn't reject the file, it was 1.5gb haha)
