Vanilla Minecraft ticks your whole server on one thread. One busy farm, one mob swarm, one player off exploring, and everything else is lined up behind it waiting its turn. You see it as MSPT climbing and TPS falling, and usually the only fix anyone can offer you is to ask your players to build smaller.
Threadcore splits each world into regions and ticks those regions at the same time, on a pool of worker threads. Entities, block entities and scheduled ticks in different parts of the world stop waiting on each other.
Minecraft 1.20.1 on Fabric, server side, Java 17.
This goes on the server only. Your players install nothing, there is no client mod, and they do not need to know it is there.
You need two jars, plus Fabric API. Threadcore needs threadcore-api 0.0.2 or later sitting next to
it in your mods folder. If you only install Threadcore then Fabric will not start the server at
all, it just prints requires version 0.0.2 or later of threadcore-api, which is missing! and
stops.
Entity ticking, block entity ticking, and scheduled ticks, for the regions that have work in them. That is the bulk of what a busy survival server spends its tick on.
Things that have to happen on one thread still do. A region thread never writes a block itself, never spawns or removes an entity itself, and never reaches into another region's chunks. All of that gets handed to the main thread, which replays it in order, so the result is the same order of events you would have had without Threadcore.
This is where nearly all of the work went, and it is the part I would judge a mod like this on.
Every operation is tagged as main thread, region thread or async, and a guard checks while the server runs that whatever is executing is allowed to be where it is. In strict mode you hear about a violation when it happens rather than finding a broken world later. Anything that crosses a region boundary goes through a queue instead of happening on the spot, which covers block changes, entity spawning and removal and damage, scheduled ticks, lighting, neighbour updates and path recalculation. Reads that happen off the main thread see a frozen copy of the world for that tick, so they cannot catch it halfway through a change.
There is also an audit layer that keeps a ledger of items and XP and reports anything that does not balance. That is how I find out about a problem, rather than waiting for somebody to notice their backpack is lighter. An entity type that misbehaves gets demoted and stops being offloaded at all.
Threadcore's safety comes from intercepting a specific handful of call sites and serving region threads from those frozen snapshots instead of live shared state. Another mod that redirects the same call site first defeats that, so Threadcore carries a registry of mods it knows about and tells you at boot which category each one is in.
If you have another mod that also moves tick work off the main thread, like Async, MCMT or Dimensional Threading, Threadcore refuses to arm instead of running a combination that neither mod can make safe. Your server still boots, it just runs the vanilla tick loop until you remove one of them.
Lithium gets a caution with the actual interaction named, which is that it redirects the entity cramming query, and that it reads the entity cache directly if you turn its experimental item merging option on. Keep Lithium's experimental options off. C2ME and ScalableLux also get cautions with their reasons spelled out. Sodium, FerriteCore, ModernFix, Krypton, Noisium, ThreadTweak and Very Many Players are fine and say so.
The registry never guesses. A mod it does not know about is not mentioned, rather than being vouched for, because working out from a mod id whether something multithreads is exactly the confidently wrong behaviour this is here to prevent.
This is a beta and the version string says so.
The 1.20.1 build has been running a real server of mine since September 16th, 258 mods, and that is where my confidence in it comes from. Your modpack is not my server though, so back your world up before you install this. That is not a formality, it moves the tick loop.
It is not a free speedup for everybody either. What you get depends on how much of your tick is entities and block entities spread across the world. If you are bottlenecked on chunk generation, or on one enormous farm sitting in a single chunk, or on one mod doing heavy work on the main thread, there is not much here for you yet.
Modded entity types start out staying on the main thread until they have proven themselves, so a heavy modpack starts conservative and opens up as types pass. Two things are off on purpose: region random ticks, which are experimental, and owned chunk tick suppression, which would stop ice and snow forming and lightning striking in the chunks a region owns. Everything risky has an off switch and the defaults are the careful ones.
Put -Dthreadcore.noOffload=true on the server's JVM arguments. That turns the parallel tick off
completely and makes Threadcore do nothing at all, so if your problem is still there with that flag
set, Threadcore is not what is causing it. It is the quickest way to find out and it is the first
thing I am going to ask you.
When you report something, include your Minecraft and Fabric Loader versions, the full mod list, and the server log. If you can reproduce it, say whether it still happens with that flag on.
