FerriteCore

About FerriteCore

FerriteCore makes Minecraft use less memory. That is the whole job. It does not touch the renderer, it adds no menu, no overlay and no keybind, and after you install it the game looks and plays exactly as it did before. The only difference is that the same world occupies a smaller share of the memory Java has handed to it.

That matters most in one specific situation: a large modded instance that is running out of headroom. If your game stutters every few seconds while the garbage collector clears space, or a server creeps up against its memory limit as players spread out, FerriteCore is aimed squarely at you. If your frame rate is low because your GPU is working hard at high render distance, it is not, and a different mod is the answer. The rest of this page is mostly about telling those two cases apart.

RAM and FPS are not the same number

Almost every page written about this mod calls it an FPS booster. Sorting out the vocabulary explains why that is misleading, and it takes four terms.

• Allocated RAM is the ceiling you set in your launcher, the -Xmx figure. Giving Minecraft 8 GB does not make it use 8 GB; it permits up to 8 GB.
• Heap used is how much of that ceiling is occupied by live data at a given moment. This is the number FerriteCore reduces, and the number the official benchmark reports.
• FPS is how many frames per second your machine draws. It is decided mostly by your GPU, your render distance and the rendering code, none of which FerriteCore modifies.
• Frame time is how long each individual frame takes. A game can average 120 FPS and still feel bad if one frame in fifty takes 300 ms. That hitch is what people usually mean by "lag" or "stutter".

The link between memory and smoothness runs through that last term. Java reclaims unused memory by periodically pausing to collect garbage. The more live data sits on the heap, the more often those pauses happen and the longer they take, and a long pause shows up as a dropped frame. Cut the amount of live data and you reduce the pressure that causes the pauses.

So the honest framing is: FerriteCore reliably lowers memory use, and lower memory use can reduce stutter on an instance that was under memory pressure. It will not raise the average frame rate of a machine that had plenty of memory to begin with. No official benchmark measures FPS at all, and any page quoting a percentage FPS gain for this mod invented it.

What the current version actually optimizes

FerriteCore is a targeted mod rather than a general one: it rewrites a small number of internal data structures that happen to be enormously duplicated. Reading the source of the branch that produces the current builds, version 9.0.0 changes four things:

• Blockstate neighbour lookup. Every block state needs to find its neighbouring states, the same block with one property changed, which is what happens when a fence connects or a stair rotates. Vanilla gives each state its own lookup table. FerriteCore replaces those with one compact map per block. In a pack with thousands of blocks this is the single largest saving, and it applies on both the client and the server.
• Blockstate property storage. Rather than each state storing its own map of properties, the properties are read back out of the structure above. Both sides again.
• Blockstate cache deduplication. Blocks cache their collision and render shapes. Enormous numbers of blocks share identical shapes, so FerriteCore points the duplicates at one shared instance instead of storing thousands of copies. Both sides.
• Data component patches. The newer data-component system attaches a map to items and blocks; most of those maps are empty, and an empty map still costs memory. This removes that overhead.

Notice what these have in common: they are all about block states and item data, not about models or rendering. That is why three of the four help a dedicated server as much as they help a client.

The current build does less than the famous benchmark suggests

This is the part almost nobody mentions, and it changes how you should read every number written about this mod.

FerriteCore used to include a second family of optimizations aimed at the client's model system: deduplicating multipart model predicates, model instances, resource-location strings and baked-quad vertex data. In the mod's own historical measurements those were worth several hundred megabytes on their own. Minecraft 1.21.5 rewrote the model system entirely, and version 8.0.0 removed all of them, describing the removal as temporary pending re-evaluation. As of version 9.0.0 they have not returned: the source tree for the current branch contains no model, quad or resource-location optimization code.

The practical result is that the version you install today is a blockstate-and-item-data mod. It is still doing real work, and the largest single optimization was never a model one, but a client-side player who reads an old article promising savings from model deduplication will not get them on Minecraft 26.2.

One wrinkle worth knowing if you go reading the source: the project's summary.md technical document still describes the removed optimizations. It has not been updated to match the code.

What the official benchmark says, and what it doesn't

The project page gives one measurement, and it is a good one because it states its conditions:

In version 2.5.9 of All Of Fabric 3, heap usage falls from 1,792 MB to 984 MB, measured after generating a world with a fixed seed and waiting two minutes. The same setup using Hydrogen instead reaches 1,335 MB.

Four things to hold onto. First, it is heap usage, not allocated RAM and not system memory. Second, it is one specific modpack: the project's own wording is that the amount saved depends on the pack, and a lightly modded or vanilla profile has far less duplication to remove, so it saves far less. Third, it is a fixed, artificial moment: a freshly generated world after two minutes, not an hour into a long-running save. Fourth, and most importantly given the section above, that measurement dates from a period when the model optimizations were still present.

Treat it as evidence that the mod does something substantial in a heavy pack, not as a figure to expect on your own instance.

Client, server, or both

Both, and the reasoning is unusually clean on current versions. Three of the four remaining optimizations operate on block state data, which exists on the client and the server alike. The project's own FAQ asks players to install it on both sides, and on 26.2 that advice is stronger than it used to be, because the client-only model optimizations that once made it feel like a client mod are gone.

• Single-player. Install it in your client. Your game runs an internal server, so one install covers both roles.
• Running a server. Install it server-side. A server holds block state data for every loaded chunk across every dimension, so this is genuinely worth doing, and it is independent of what players have installed.
• Joining someone else's server. Install it client-side and it works. Modrinth marks FerriteCore optional on both sides, so it does not have to match the server, and it will not stop you connecting to a server that lacks it.

Loaders and Minecraft versions

FerriteCore's project listing names four loaders, and the Loaders row on this page reflects that, because the mod has genuinely shipped for all four across its life. For a current install only two of them matter, because the other two stopped years ago.

• Fabric: current. Version 9.0.0 covers Minecraft 26.1 through 26.2.
• NeoForge: current. Same 9.0.0 release, same Minecraft range, separate file.
• Forge: discontinued. The last Forge build is 6.0.1, for Minecraft 1.20.1, published in October 2023. There is no Forge build for any newer version, and a NeoForge file is not a substitute.
• Quilt: discontinued. The last build tagged for Quilt is 6.0.3, for Minecraft 1.20.4, published in December 2023.

Version 9.0.0 was published on 24 March 2026 for Minecraft 26.1, and its Minecraft 26.2 support was added to the same files rather than by a new release, so seeing a March date on a build that supports a June game version is expected, not a sign that it is out of date.

It needs nothing else

FerriteCore has no required dependencies on either loader. The current Fabric and NeoForge files each declare an empty dependency list.

That includes Fabric API, which is worth stating plainly because so many Fabric mods do need it and guides tend to recommend it reflexively. FerriteCore does not, and in fact removed an incorrect Fabric API dependency years ago. Installing Fabric API anyway is harmless (plenty of your other mods will want it), but nothing breaks if FerriteCore is the only mod you have.

It also does not need Sodium, Lithium, or any other performance mod. It runs alone perfectly well.

Where it sits next to Sodium and Lithium

These three are frequently installed together and are frequently confused with each other. They address different bottlenecks and none replaces another:

• Sodium rewrites the renderer. It is the one that raises frame rates.
• Lithium optimizes game logic: the tick, mob AI, physics. It is the one that helps server tick rate.
• FerriteCore reduces memory footprint. It is the one that helps when you are short on RAM.

If your problem is a low frame rate at high render distance, Sodium is the mod to reach for. If your server's tick rate sags with a lot of entities loaded, Lithium is. If your game hitches periodically and your allocated memory is nearly full, FerriteCore is.

Compatibility between them is normally fine, and the project's FAQ answers "is this compatible with other mods" with "most likely yes". Two footnotes are worth keeping in mind. Conflicts have occurred in the past: version 8.0.2 fixed a log warning that appeared when Lithium was installed, and 8.2.0 fixed a loading slowdown with ModernFix's dynamic resources, which is a reason to keep all of them current rather than a reason to avoid combining them. And Hydrogen is the one documented exception: it was archived years ago and never released for Minecraft 1.18 or later, so it is not a mod you will encounter on a current version.

The two switches that are off by default

FerriteCore has a configuration file, but no in-game screen. Four of its optimizations are enabled out of the box and need no attention. Two more exist and are deliberately disabled:

• useSmallThreadingDetector replaces the objects Minecraft uses to detect multi-threaded chunk access with a much smaller field. It is off by default, and the config's own comment explains why: rare, hard-to-reproduce crashes. It is labelled use-at-your-own-risk in the mod itself, so leave it alone unless you are prepared to debug it.
• compactFastMap stores block states more compactly at a small cost in speed. It is off by default, trading a little CPU for a little memory. Only worth touching if you are genuinely memory-limited and have measured the difference.

For nearly everyone the right configuration is the default one.

Java Edition only

FerriteCore is a Java Edition mod. It is written in Java against Minecraft's own code, and there is no Bedrock version: no Windows 10/11 edition, no console, no mobile. It is open source under the MIT licence, written by malte0811, with the full source on GitHub.

FerriteCore installs like any single-file mod, and the only thing you can really get wrong is downloading the wrong file. There are two current files and they are not interchangeable.

Choosing between the two current files

Both are version 9.0.0 and both cover Minecraft 26.1 through 26.2. They differ only in loader:

• ferritecore-9.0.0-fabric.jar, for Fabric
• ferritecore-9.0.0-neoforge.jar, for NeoForge

The loader name is in the filename, which makes this easy to check after downloading. If you are on Minecraft 1.21.11 or older, you need a different release entirely: the build table on this page lists every release against the Minecraft version and loader it fits, so picking the row that names your version is the reliable way to do it. If you are running Forge or Quilt on a modern version, stop here: there is no current build for either, and this is covered in more detail on the description tab.

Both files sit in the Download section on this page, where the loader is a filter rather than something to spot in a filename, and each row links to the official Modrinth release. The CurseForge project and the GitHub repository carry the same builds. Sites that repackage mod JARs are not worth the risk for a mod this small.

On Fabric

1. Install Fabric Loader for your Minecraft version and start the launcher once so the profile exists.
2. Download ferritecore-9.0.0-fabric.jar.
3. Drop it into the mods folder of that instance. On Windows the default is %appdata%\.minecraft\mods; a launcher such as Prism or MultiMC keeps a separate folder per instance, and that is the one to use.
4. Launch. There is no dependency to install and nothing to configure.

You do not need Fabric API for FerriteCore specifically: it declares no dependencies at all. Most modded setups end up with Fabric API for other reasons, and having it changes nothing here.

On NeoForge

1. Install NeoForge for your Minecraft version and run the profile once.
2. Download ferritecore-9.0.0-neoforge.jar.
3. Place it in that instance's mods folder.
4. Launch.

Same story: no required dependencies.

On a dedicated server

Worth doing, because most of what the current version optimizes is block state data that a server holds for every loaded chunk.

1. Stop the server.
2. Put the file matching the server's loader and Minecraft version into the server's mods directory.
3. Start the server and watch the console until it reports it is done.

Players do not need FerriteCore to join (it is marked optional on both sides), so you can add it without coordinating with anyone. If you also want the client-side benefit, install it on your own client separately.

Checking it loaded, when there is nothing to look at

FerriteCore adds no button, no overlay and no menu entry, so the usual "look for the new screen" check does not apply. Use one of these instead:

• The mod list. On Fabric, Mods in the main menu (with Fabric API installed) or your launcher's mod list. On NeoForge, the Mods button. FerriteCore should be listed at version 9.0.0.
• The log. Open logs/latest.log and search for ferritecore. It appears during startup as the mod loads and its mixins are applied. This works on a server too, where there is no menu to check.
• The config file. After the first successful launch, a FerriteCore configuration file appears in the instance's config folder. If it never appears, the mod never loaded.

Do not try to verify it by watching the F3 memory readout. That figure moves constantly as Java allocates and collects, and eyeballing it before and after tells you very little.

When it goes wrong

The game will not start, and the loader names a mod. Read which one. A loader refusing to start usually names the exact problem (wrong Minecraft version, wrong loader, missing dependency), and that message is more reliable than guessing.

Two copies in the folder. Updating by dropping in a new JAR without deleting the old one leaves two FerriteCore versions present, which fails immediately. Check the mods folder for a stale file before anything else.

Fabric JAR in a NeoForge instance, or the reverse. The loader will not load a file built for the other one. The filename tells you which you have.

A crash mentioning mixins. FerriteCore works by patching Minecraft's classes, so it appears in a lot of crash reports without being the cause; its name in the log is not a verdict. Look for the actual exception and which two mods are involved, update both, then test with only those two installed to confirm. Historical conflicts have all been version-specific and subsequently fixed, so an outdated mod on either side is the most likely explanation.

Memory dropped but the frame rate is the same. That is the mod working as designed rather than failing. FerriteCore does not target frame rate, and if yours is limited by the renderer then Sodium is the mod that addresses it.

Nothing seems different at all. On a vanilla or lightly modded profile, that is the expected outcome. The savings come from duplication across large numbers of blocks and items, and a small instance does not have enough of them for the difference to be noticeable.

New to installing mods? The step-by-step mod installation guide covers loaders and the mods folder in more detail, and our guide to mods that are not working covers narrowing down a game that will not start.

FAQ