《▒ What it actually does ▒》

• Proper async scheduling with worker lanes, telemetry, sane fallback behavior, and less Ehhh, why is my game suddenly at 5 tps xd
• DAG / task graph execution so dependency-aware workflows don't need to be wired by hand (I 100% recommend doing it, so fun)
• Backend-aware compute routing through QuantifiedAPI.compute(...) with CPU, Vulkan, and OpenCL preferences
• GPU acceleration when it actually makes sense, not fake "gpu preferred" branding slapped onto CPU work as on other mods
• Caching + persistence layers so repeated expensive work, so your CPU/GPU has more time to nap (for nanoseconds xd)
• Live diagnostics through the Quantified webpanel and runtime telemetry

《▒ Vulkan GPU Acceleration/OpenCL Acceleration ▒》

Quantified API is the first Minecraft mod / API setup with Vulkan compute acceleration that simply works, without any configuration required. Vulkan is the preferred GPU backend, while OpenCL is still kept around as the fallback / legacy path for compatibility.

That said, Vulkan under Minecraft + Forge + LWJGL can be a complete pain, so to counter that Quantified API is built around isolated probing, deferred runtime init, explicit failure reasons, and proper fallbacks.

• Isolated Vulkan probing so a corrupted driver or a loader issue doesn't instantly brick the game or cause a crash
• Explicit fallback routing Vulkan falls to OpenCL if Vulkan isn't available, or is misbehaving. Worst case if both decide to act up, everything heads to the CPU without you even noticing :DDD
• Backend diagnostics so you can see probe state, runtime state, active backend, chosen device, and failure reason without digging through 9 years of log spam (Modded logs xd)

《▒ Public API surface ▒》

The newer API side is now even easier to use, and lets modders (perhaps you are one xd?) choose how they wanna throw work at the runtime without writing cursed boilerplate all over the place (GeckoLib's API has to be studied in my opinion xd).

• QuantifiedAPI.compute(...) for backend-aware compute submission
• QuantifiedAPI.vulkan(...) for explicit Vulkan-targeted workloads
• QuantifiedAPI.graph(...) for DAG / dependency-aware flows
• Backend preferences like preferVulkan(), preferOpenCL(), requireVulkan(), and cpuOnly()

If your mod is doing worldgen prep, simulation, batching, heavy math, cache-heavy systems, or other compute nonsense (Dancing cockroaches :DDD), Quantified API gives you a proper runtime instead of forcing you to reinvent multithreading for the 40th time, and then fix each compatability issue, every FREAKING time...

《▒ Quantified Webpanel ▒》

Quantified API from day one ships with a webpanel, which is basically there so you can see what it's doing in realtime.

You can enable it through config or with /quantified webpanel.

• Runtime overview for scheduler activity, queue pressure, backend state, mod usage and so etc
• GPU controls for backend preference and device selection (Dual 5090 users will love this xd)
• Diagnostics export so debugging weird behavior is easier for me, and you :]
• Optional auth / HTTPS stuff if you want it a bit less jank when exposing it beyond localhost

《▒ Compatibility ▒》

• Vulkan is optional. If it works, W. If not, it'll degrade cleanly instead of becoming a startup bomb
• OpenCL support still exists for compatibility, but Vulkan is the main direction due to it's large advantages over OpenCL
• If your hardware doesn't support Vulkan, it as mentioned switches to OpenCL. If even OpenCL isn't supported... how are you running the game then???

《▒ Licensing and support ▒》

Licensed under BRSSLA V1.5 which is free for personal and non commercial use.

Mod Developers who include Quantified API as a dependency automatically gain Commercial Rights for their mod.

It's built to be flexible, easy to integrate and to be as user friendly as possible, while being flexible. If you have any requests, ideas, or found a bug, feel free to open a github issue or even a merge request :]