Not an official Minecraft product. Not approved by or associated with Mojang or Microsoft.
HubNow, next and how to help
Where Horizon is going
What is being done, what comes next, what shipped and where you can help. No dates: things are Now, Next or Later. Read it in plain words, or switch to the technical picture.
Horizon is Minecraft: Java Edition 26.3 rewritten from scratch in Rust, so it runs faster on the same computer. Single player, LAN, servers, resource packs and Horizon's own mods work today, on your own copy of the game.
A native Rust and wgpu reimplementation of Java 26.3: the same saves, rules and terrain, checked against the real game by more than 300 differential harnesses (a Java oracle and a Rust probe on the same inputs). Single player runs on its own server thread, like vanilla's integrated server.
Play it and tell us what differs from vanilla (Discord or GitHub), run the benchmark on your computer, vote for what you want next, or pick one of the Help wanted items.
Read CONTRIBUTING.md, pick a Help wanted item or a To do card, check vanilla's code for the behaviour, and paste the block python3 tools/pr_ready.py prints in your pull request.
Being worked on, with pull requests open or just merged.
Performance
Steady frames at long render distances
Making Horizon faster than vanilla on every computer, with smooth camera movement even at 32 chunks, by spreading the work better over the processor's cores.
Frame pacing at render distance 32 (#678): long frames come from work competing with the render thread. In review: world generation workers build free structure starts instead of queueing them (#1760), the worker pool leaves one core as vanilla does (#1778), and the terrain vertex arena is read as storage where flat draws run (#1742). Still open: far terrain at 48 to 64 chunks (#718) and CPU-bound fields of block entities (#717). Every change shows before and after numbers from tools/perf_bench.py against vanilla 26.3 (docs/benchmark.md).
Speeding up the code that reads and writes the blocks of the world, which almost everything in the game goes through: generation, lighting, meshing and ticking.
PalettedContainer and PackedStorage find an entry's word by multiply and shift instead of an integer division (#1790, #1794); meshing looks up baked models by index, not by name (#1747). Each change keeps the paletted storage harnesses identical and shows its microbenchmark (docs/performance/paletted-container-access-results.md).
Making the world-generation mods of popular modpacks (new structures, YUNG's dungeons and mineshafts, packs built on Lithostitched) generate their worlds in Horizon, natively and fast.
horizon-port-pack carries a pack's data-driven content over; structure mods that need code get a native port: YUNG's worldgen as written (#1746), Lithostitched's limited and guaranteed elements with pool and processor modifiers (#1777), its processors as the game's own types (#1765). Proved by the structure blocks and layout harnesses (#1753, #1757). Mods whose Java code does more than world generation don't run (docs/modpacks.md).
When you play on a server, other players, mobs, items and menus look and behave as in vanilla: skins, poses, item names, inventories and server networks.
Client-of-a-server fixes in game/remote*.rs and horizon-protocol: mobs' aggressive and item-use flags (#1802, #1798), ghost items after a remote menu (#1795), skins (#1652), cookies and transfer packets for proxy networks (#1650), firework boosts (#1671), living-entity attributes and simulation distance (#1731), styled item names (#1702), primed TNT between updates (#1710).
A /pregen command that builds an area of the world ahead of time, so players don't wait for new terrain when they explore.
Generates, lights and saves an area before anyone walks there (#1805, a contributor's pull request, in review). Useful on servers, and it moves the generation cost away from the first visit; the generation speed-ups are under 'Steady frames at long render distances'.
One place for mods, modpacks and resource packs made for Horizon: browse them on the website and install them from the launcher in one click.
Merged: the registry index (schema 1, .hpack, checks before install, #1634), cargo horizon-mod check (#1642) and the submission service (crates/horizon-mod-registry, #1659). In review: the website's /mods (#1596) and /mods/submit (#1635), and in the launcher the registry as a source (#1636), install, enable and takedowns (#1637), the Mods page (#1638) and modpacks as their own profiles (#1640).
Mods that run on the server side of a world, so a dedicated server or a LAN world can have mods that react to players joining, chat and blocks being broken or placed, and that add commands.
API 0.3, experimental first (#1833, in review): the same sandboxed component runs on the server thread and the dedicated server, with world events (block broken or placed, entity spawned or killed, player joined or left), game rules and server commands with typed arguments. The world, item and entity interfaces come after (see 'Mods that read and change the world'). docs/api/mods.md, docs/mods.md.
Mods will be able to open their own screens and settings pages and react to keys and item use, so bigger mods, such as the Orbital Laser, can run on the normal game.
Capability ui is in review (#1864): mod-owned screens and a settings page under Options > Mods, built from vanilla's widgets. Still to design: input (an item's use, key binds, the crosshair target), render (a budgeted draw list on the native shader API) and world (changing blocks). Orbital Laser is the acceptance test: it needs all four today through its author's fork (see 'Orbital Laser on the normal game').
Better tools for mod makers: a test runner that needs no game window, templates for each kind of mod, and clear promises about what keeps working from one version to the next.
cargo horizon-mod test runs a mod's test scripts against a fake game snapshot (#1816) and, for server mods, scripted server events (#1837); the content template and the guides are merged (#1859, #1810, docs/api/stability.md). Left: templates for hud, server and machine mods, typed wrappers in the SDK, a frozen 0.1 compatibility mod that every runtime must load, a CI check that fails when a stable reference entry is removed without a new major version, and the SDK on crates.io once the API is stable.
Single player now runs a small server in the background, as vanilla does. We are fixing what still behaves differently there; every fix also works for LAN and server players.
Since #1514 single player runs on the server thread (game/integrated.rs) and the window joins it as a client; --in-frame keeps the old path. The open [server-thread] issues list the gaps. In review: a tool that changes a block ends the click (#1797), potions keep their potion over the connection (#1796), mobs' aggression and arm swings (#1802). docs/server-levels.md.
Item names, container titles and server messages follow the language you pick, as in vanilla. Today parts of the game stay in English.
Translatable components resolved through the selected language for items, containers and server text (#1806), on top of the bundled languages the prepared resources carry (#1594). Left: the client's own screens (#1672) and the main menu with zh_cn (#1774).
After you throw an ender pearl, its slot should show the cooldown sweeping away, as in vanilla.
Vanilla draws ItemCooldowns' percent as a white overlay over the slot (GuiGraphicsExtractor.itemDecorations and itemCooldown) in the hotbar and in inventories. Issue #1763.
The Hidden and Commands Only chat settings should hide chat, and team prefixes should appear before names in chat.
Vanilla checks ChatVisiblity before it delivers chat and system messages (#1376), and chat uses the team-formatted display name (#1378). Both issues have exact steps to reproduce.
Shader packs were removed and are being rebuilt from scratch. They come back, off by default, once the best-known packs draw properly.
A clean-room rewrite in horizon-shaderpack, from the packs' public format documentation only: reading packs, the preprocessor and .properties files are merged (#1584, #1585, #1586); translating programs to WGSL through naga, buffers, uniforms and the terrain, entity, sky, weather and hand stages are in review (#1698 to #1801).
Horizon's own way to make shader packs, with tools to write and test them. Every pack is checked before it runs, and the registry will list them.
horizon-shader-api (API 0.1, experimental): WGSL stages with typed inputs inside the renderer's passes, options as WGSL override constants, and the horizon-shader new|check|pack tool with templates and the example pack Golden Hour. Merged: the check every pack passes (#1820) and the tool, templates and guide (#1822). In review: the post stage running in the game with hot reload (#1861), the sky stage (#1863) and registry checks that use the game's own check (#1855). Left: the material, lighting and shadow stages, a last-good fallback on reload, a GPU-time overlay per stage and budgets (docs/shaders.md, docs/api/shaders.md). The Iris/OptiFine loader is a separate item, 'Shader packs, written again from scratch'.
Cleaning up Horizon's code: removing what nothing uses and making it quicker to build, so fixes and new features land faster.
A review of the whole tree: dead code and stubs removed (#1432, #1658), one probe binary per crate (#1453, #1454), shared harness helpers (#1448), clippy clean on the whole tree (#1707). docs/architecture.md maps each feature to its files and harnesses.
New public numbers comparing Horizon with vanilla on many kinds of computers, measured the same way every time, with a history that shows what each release changed.
Redo the comparison after the current performance work (#1073); reliability, coverage and presentation (#1346); a scene must count as loaded only once its first chunk arrives (#1749). Next: a performance history across releases (an automatic comparison of each release with the last, on a timeline), more report fields (server TPS and MSPT, power, battery drain, temperature, throttling) and more hardware (a MacBook on battery, low-end laptops, community reports). Players' reports come in through --benchmark and horizon-launcher data benchmark (docs/benchmark.md).
Creating a world and joining it should be quick even on a four-thread laptop, where a fresh world at 32 chunks can make you wait minutes for the first terrain.
Cut the per-column generation cost (noise sampling, surface rules, aquifers) and the lock convoy on structure starts, and leave one core free for the rest of the game as vanilla does (#1760 and #1778, in review, are listed under 'Steady frames at long render distances'). Still to profile on small CPUs: the first seconds of a fresh world deliver no chunk, and fluids remesh for about a minute after loading. Measured with tools/perf_bench.py (docs/benchmark.md, docs/profiling.md).
Servers that keep 20 ticks per second with 50 to 100 players. Today Horizon holds it up to 50 bots and drops to about 10 at 100.
Measured against vanilla on equal work (docs/server.md, Scale): Horizon is ahead with few players and when exploring, but vanilla's tick is shorter with 25 to 50 players near spawn. Ideas on the list: send entity changes instead of rebuilding every entity each tick (about 15 percent), fewer memory reads in random ticks and collision scans, cheaper item collision checks, mob AI and natural spawning. The bot benchmark (horizon-bots) is the proof.
Horizon should run well on small machines: integrated graphics, the Steam Deck, older Macs and 8 GB of memory, with a battery mode that saves power on laptops.
Partly done: an opt-in 60 FPS cap with fewer workers on battery, Far Detail Reduced for integrated GPUs and animated textures on the GPU (both shipped). Left: measured targets and fixes per class of machine (memory use, worker counts, startup) on a Steam Deck, old Intel and Apple Silicon Macs and 8 GB computers, reported on the Benchmarks page.
Draw the game at a lower resolution and sharpen it to your screen's size, in the way of FSR or DLSS, to gain frames on weaker graphics cards. An optional graphics setting.
A render-scale setting below the window size with an upscaler of our own that runs on every wgpu backend. Proof: frame time against native resolution on integrated GPUs, and screenshots for image quality. Issue #1403.
Several smaller speed-ups, each measured: idle block entities that sleep, cheaper particles, faster structure placement, high-rate mice and very large texture packs.
Block entities and hoppers that skip work when idle (the hopper item scan is already skipped when no item is near); a particle frustum test first (also a parity gap), then particle quads built on the GPU; jigsaw shortcuts that skip blocked connectors and pool elements known not to fit, with layouts unchanged (trial chambers and ancient cities first); batched raw mouse input on Windows for 8000 Hz mice; a better atlas packer for huge resource packs (a 64x pack builds a 704 MiB atlas for 452 MiB of textures); sign-heavy scenes (#1461). Profile first, keep what pays, show before and after numbers.
Coming soon: search and download CurseForge mods and modpacks from the launcher, as you can with Modrinth today.
The mod browser lists CurseForge as coming soon (docs/mod-browser.md): it needs CurseForge API access. Meanwhile packs import from a CurseForge zip or instance folder, and jars only CurseForge hosts come from the player's own instance (docs/modpacks.md).
A Convert to Rust button for what isn't rewritten yet
When a mod, shader pack or modpack hasn't been rewritten for Horizon, one button converts what can be converted, so you don't have to wait for the rewrite.
Generalise the mod browser's Port step (horizon-port-pack: the data, assets, worldgen and block and item definitions of Java mods, .mrpack and CurseForge zips) to every kind of content: code mods where the API allows it (see 'Mods with code') and shader packs, converting an Iris/OptiFine pack into Horizon's format. The browser says what works before the install. Java code itself does not run (docs/modpacks.md, docs/mod-browser.md).
Making mods that add machines, magic and mobs work in Horizon, in steps, starting with machines. They are most of what a big modpack is made of.
333 of the 496 mods in a big pack (ATM10) contain code. Issue #1854 ranks the API gaps (ticking block entities, networking, rendering, menus, inventories) that unlock them in tiers, with machines first as the recommended path and a furnace ported tick for tick as proof. The first API step is a draft (#1189, see 'Machines and blocks with inventories'). The path isn't started yet (docs/modpacks.md).
Search and install data packs from the launcher's mod browser, for the world you choose, as you do mods and resource packs.
A Datapacks tab beside Mods and Resource packs: install into a chosen world's datapacks folder, with the same checks and 'works in Horizon' notes as the other kinds (docs/mod-browser.md).
Set up Horizon, a server first, without Java on your computer: published tables are combined with your own copy of the game.
Today horizon-prepare runs Mojang's exporters with Java. Issue #1750 proposes publishing the computed version tables once from CI and assembling the rest locally from the player's own jar and assets, provided the tables hold no Mojang content; a contributor offered a pull request, and it would help phones too. A server-only prepare from server.jar alone is the first step (docs/server.md).
Manage a server from a console, ban and pardon players, and drive it from other tools through a full admin API and an MCP server for AI agents.
horizon-server console (a text interface), ban, pardon, ban-ip and mcp over stdio. Admin API additions: the player list, kick, ban, op and whitelist, an SSE stream of logs and events, a text metrics endpoint, config GET and PATCH, backup delete and download. The panel's later features (bans, worlds, server.properties import, logs and crash reports, modpacks) and vanilla's management protocol (the JSON-RPC over WebSocket that the management-server-* keys configure), so vanilla's tools can manage a Horizon server. docs/server.md, docs/api/server.md.
Smoother hosting: a real Windows service, a backup before every update, backups that keep the world and each player's state, and a changed view distance or message without a restart.
A Windows service wrapper instead of the logon scheduled task; backups.before_update; hot reload of config for view distance and the message of the day (needs engine support); backups that keep world and player state (#1808, a contributor's draft, in review). docs/hosting.md, docs/server.md.
Guided hosting with Tailscale and an invite button
In the launcher, a guide and a button to host a server and invite friends over Tailscale, so nobody has to open ports on a router.
On the Servers page (create, start, back up, update and invite are shipped) add a Tailscale setup that explains and checks each step, and an invite button that hands friends what they need to join over the tailnet. Buttons first, no docs needed, with the details in an Advanced section. Remote access over Tailscale is already described in docs/server.md.
An official image to run a Horizon dedicated server in Docker with one command, your own copy of the game files mounted in.
The repository has the Dockerfile (packaging/server/Dockerfile: a multi-stage build on Debian bookworm-slim, user horizon, volume /data, port 25565, game files mounted read-only, HORIZON_EULA and friends answering the first-start questions), and anyone can build it (docs/hosting.md, section 9). Left: publish the image to a public registry from the release workflow, tagged per release, so it follows the same checks, and update the docs and the launcher. The image never holds Mojang's files.
Install and run a Horizon dedicated server from a terminal with a single command, no launcher needed, for VPSes and headless machines.
A player's idea (#horizon-ideas). horizon-server already runs headless; left: an install script (Linux/macOS shell, Windows PowerShell) that fetches the signed release, checks it, asks for or points at the player's own game files and starts the server, documented in docs/hosting.md.
Mods that can see and change blocks, read inventories and items, and find and affect entities, all through the server so every player sees the same thing.
After server mods: read blocks, states and biomes in loaded chunks and change them through the server's block log, so clients and the parity harnesses see vanilla's updates; the player's inventory, held item, open container and item stacks with components; entity queries near a position, a safe subset of entity data and data-driven mod entity types. Snapshots and batched calls per tick, never per-block host calls in hot paths. docs/api/mods.md ('Not there yet').
Mods that add machines: blocks that tick, hold items and have their own menus. This unlocks the technology mods of big modpacks.
Block entities and menus: ticking machines with slots, server menu logic and the menu protocol to clients, energy, item and fluid transfer, data attachments, accessory slots and custom recipe types, with a typed client and server channel and typed config beside them. A draft (#1189) proves a furnace ported tick for tick and holds the ATM10 code-mods plan; the design is redone through the API policy before it merges (docs/modpacks.md, docs/api/stability.md).
Write mods as Lua scripts, in the style of KubeJS, with no compiler, and later in other languages that pass the tests. Every language runs in the same sandbox.
Lua first: Horizon ships a Lua interpreter that is itself a WebAssembly mod, and a script mod's manifest names it and the capabilities it uses, so a script can do exactly what a compiled mod with the same manifest can, with hot reload of main.lua. Then C, C++, Zig, Go (TinyGo), AssemblyScript and JavaScript or TypeScript are measured against Rust on the same tick-heavy example, and each is supported only with a template, an example and a CI test. docs/api/mods.md ('Ways in').
Pistons and slime blocks will push players, mobs and items as in vanilla. Today moving blocks pass through them.
Port PistonMovingBlockEntity.moveCollidedEntities and moveStuckEntities (honey), the slime bounce and Entity.limitPistonMovement for MoverType.PISTON, in single player and for a server's players. Issues #1496, #1609, #1608, #1704, #1758.
Single player will have one way to run, the server thread, so every fix works everywhere and there are fewer bugs. The older in-frame mode goes once everything passes without it.
--in-frame (also --no-server-thread and HORIZON_SERVER_THREAD=0) still ticks the world inside the window's Game, and most harnesses test that path. Delete it once lan_e2e --server-thread and the parity harnesses pass on the server thread, which also halves the bug surface. See also 'Single player as a server' and docs/server-levels.md.
Villages and fights behaving as in vanilla: iron golems defending villages, villagers remembering their homes, mace smashes and knockback.
Villages: iron golem village goals, villager memories across saves, villager age, job-site claiming on dedicated servers, flower offers (#1639 is one report). Combat: the mobs' attack_knockback attribute, mace smash logic, the hit knockback source on the host, the fire burnout biome tag. Each is checked against vanilla by a harness (docs/rust-parity.md).
Pick the speakers or headphones Horizon plays through, in Music & Sounds.
An output device list in Music & Sounds, falling back to the system default. #1035 started it: a player on an older Windows computer had no sound at all, and a device choice is how such cases are found and fixed.
Popular shader packs rewritten in Horizon's format, so good packs exist from the start. Only packs whose licence is open source and compatible with ours are rewritten, never anything else.
The first candidates are Photon, Chocapic13 and MakeUp Ultra Fast, each only after its licence is read and recorded: a pack is rewritten only if it is open source and compatible with Horizon's licence, and the rewrite is written from the shader format's documentation and the look on screen, not from anyone's code. Today only the Golden Hour example exists ([crates/horizon-shader-api/packs/golden_hour](https://github.com/ludovic111/horizon/blob/main/crates/horizon-shader-api/packs/golden_hour)).
Coming soon: sign in with your Microsoft account to play on online-mode servers. The code is ready; it waits for Microsoft's approval.
Device-code sign-in in the launcher and online-mode login in the client (docs/microsoft-account.md). It is turned on by setting the app's client id once Minecraft API access is approved; until then the launcher shows "Coming soon".
Builds of the game and the launcher for Macs with an Intel processor.
x86_64 game and launcher builds, picked per processor (#1171). Before it ships it needs a run on a real Intel Mac: Rosetta on Apple Silicon only proves the CPU code. Requests: #1161, #1792.
Fixes for Linux desktops that use Wayland and Hyprland: fullscreen, the clipboard, the GUI scale after a restart and the like.
Open: the GUI Scale is clamped to 2 after a restart under Hyprland, while XWayland keeps it (#1866). Earlier reports covered fullscreen dropping on menu clicks, the clipboard and a white overlay (#1007, closed). Checked on a real Wayland session.
A stable, documented way for AI agents and scripts to drive the game and the launcher, with versions and an event stream so tools keep working as Horizon changes.
hello answers with the API version, the release and the features; horizon-ctl --api; MCP serverInfo; reply schemas generated into the reference; a test. namespace for hooks; transcript compatibility tests; subscribe as a stream of events on one connection; Horizon option files by key and saved-server commands. Agent control itself (horizon-ctl, both MCP servers, the No AI switch) is done: docs/agent-control.md, docs/api/agent-control.md.
You can port a mod to Horizon with your own AI agent on your own computer. Horizon documents how and gives you the tools, but provides no hosted agents.
A player runs their own agent locally with horizon-ctl and the MCP servers (docs/agent-control.md), cargo horizon-mod, horizon-port-pack and the parity harnesses as the check. Horizon writes the guide (website/docs/agents.md, docs/modpacks.md) and runs no agents, accounts or keys for players. The No AI switch turns all of it off.
Coming soon: an official Horizon account on X, used to announce releases and the weekly summary.
Kira already posts the roadmap items marked announce = true when they ship, and the weekly summary, as soon as the account's credentials exist (roadmap/README.md, 'The journal'). Waiting for the account itself.
Safer releases: changes to the release machinery need the owner's review, and AI agents use a smaller identity of their own instead of a personal account.
.github/CODEOWNERS lists the workflows, the release and signing tools, the update-checking code and the installers (#1015); the branch protection that makes it count waits for the horizon-agent GitHub App, which reads and writes code, pull requests and issues but can't change settings, workflows, secrets or members, and whose tokens last an hour. It needs the owner to create the App and switch the protection on (docs/security.md).
Every download Horizon makes is checked against the project's signature, including the first install with install.sh and install.ps1.
Releases carry signed checksums, and the launcher and horizon-server update refuse anything unsigned (#1011, #1014). Left: the first install through install.sh and install.ps1 still trusts only the checksum GitHub publishes, because verifying Ed25519 signatures needs OpenSSL 3, which macOS doesn't ship (docs/security.md).
Far terrain drawn from the world you really built and explored, caves and builds included, not only a preview from the seed.
Keep a 3D mip store on disk built from real chunks, drawn by the GPU beside the seed preview for areas nobody has visited. Written from scratch and measured before it is kept. Builds on Far Detail and the far-terrain levels of detail already shipped; the open work on them is #718.
Recognise mods built for versions before 26.1 in the mod browser, so they can be checked and carried over like newer ones.
A mapping table from intermediary and SRG names so pre-26.1 jars can be classified, and a rename for mod ids with dashes (fabric-api); the port step then treats them like newer jars (docs/mod-browser.md).
Importing a modpack also brings the resource packs and shader packs it ships with, where Horizon can use them.
Porting a pack carries data, assets and worldgen today; the resource packs and shader packs bundled with it are left out. Resource packs can be carried as they are; shader packs go through the converter (docs/modpacks.md).
Rewriting a complete big modpack for Horizon so it runs far better than the original. Not a priority now: the work above comes first.
The project's first goal for modpacks: support them ten times better than vanilla and port any of them. It was set aside in favour of compatibility through the browser. What exists: ATM10's world generates and 42 of its 496 mods are carried at least in part (docs/modpacks.md). It depends on 'Mods with code' and the native mod API.
Run Java mods that nobody has rewritten for Horizon yet, through a bridge or a converter. Hard and not started: the Convert button and native rewrites come first.
Earlier research (#527, closed) found that Java mods can't simply run, because they call Minecraft's own classes. Options to look at again: a jar-to-WebAssembly backend, or a bridge for simple Fabric mods. Whatever is chosen has to run inside the same sandbox and capability checks as native mods.
Sign in with other account providers, such as Ely.by or any Yggdrasil-compatible one, beside Microsoft.
Issue #1270 asks for Ely.by and Yggdrasil-compatible servers with an account selector in the launcher. It builds on the Microsoft sign-in (docs/microsoft-account.md).
Friends who join through an invite code could prove who they are with their Microsoft account, as on online-mode servers.
Play with Friends joins over an encrypted tunnel with an invite code (docs/play-with-friends.md, 'Identity'). Online-mode checks against Mojang's session servers can be added on top of the same tunnel; they need Microsoft sign-in first, which is coming soon. Play with Friends stays self-hosted between players, with no relay run by the project.
The community mod Orbital Laser, made for a fork of Horizon, running on the normal game and listed in the registry as the showcase of the mod API.
A pull request on https://github.com/Stink-O/orbital-laser (MIT) once the input, ui, render and world capabilities exist (see 'Screens, input and drawing for mods'): today the mod needs them through its author's fork. Tested in the game, and listed in the registry.
Built-in versions of the client mods players ask for: block info on hover, a recipe viewer like JEI, a world map and schematic overlays.
Done as extras: a mod list and menu, a minimap and a zoom (docs/extras.md). Left: block info tooltips, a recipe viewer (a contributor offered to port JEI if it becomes a native feature), a world map and a schematic overlay. They need the read-only interfaces inventory-read, recipes, world-read and render in the mod API, or they go into the game directly.
Contraptions and physics like the Create and Aeronautics mods, as a mod for Horizon rather than part of the base game.
Issue #805 (porting QOL mods) closed with this answer: it would come as a native Horizon mod on the mod API. It needs server mods, entities and rendering first.
Every past and future Minecraft version prepared for Horizon automatically. When Mojang releases one, Horizon follows it, and every system is checked against it again.
The port pipeline (docs/version-ports.md, tools/version_port.py) detects a release, prepares it, diffs its classes against the pinned 26.3, regenerates the data-driven tables, runs every parity harness on it and writes a port report that becomes issues. The goal is as little human work as possible for any version, past or future. Detection and the first slices are merged; the scheduled agent that runs it every day isn't installed yet. Two versions in one build are out of scope.
Controllers: tested on real pads, and in the launcher
Make controller support solid: tested with real PlayStation and Xbox pads and a Steam Deck, and usable in the launcher too.
The game side is merged (docs/controllers.md): pads read with gilrs, menus, rumble, glyphs, remapping and DualSense adaptive triggers, lightbar and haptics, but not yet confirmed on real pads or a Steam Deck (DualSense haptics stay behind a switch until then). Left: a test pass on real hardware, and the same focus navigation in the GPUI launcher.
Vanilla's complete F3 screen: debug options, a profiler chart, ten-second captures and an atlas dump.
Today F3 shows position, chunk, light, biome and FPS (docs/native-client.md). Vanilla also has F3+F6 debug options with profiles, F3+1 the profiler pie, F3+L a ten-second capture and F3+S the atlas dump (#562 asked for the F3 editor).
A small built-in look (tone mapping, colour grade, a cheap vignette) that costs almost nothing, for players who want a nicer picture without a heavy pack.
An opt-in, composite-only pack on the native shader API, under about 0.3 ms at 1080p, shown on the Shader Packs page. Pack option sliders and profiles, and a Failed row with the full error, belong with it.
An optional ray-tracing mode for graphics cards that support it (RTX and recent AMD): shadows, water reflections and global lighting on top of the vanilla look.
A spike with ray-traced sun shadows, off by default, is a draft (#1180). Reflections, global illumination, Apple M3 and newer if it is cheap, and a performance report per card come after.
More graphics options: multisample anti-aliasing, anisotropic filtering and an exclusive fullscreen mode. Today Horizon has FXAA and borderless fullscreen.
Not implemented (docs/graphics.md). Anisotropic filtering needs linear magnification in wgpu, which blurs close blocks, so close-up sharpness has to be kept first; MSAA would sit beside FXAA; exclusive fullscreen where the backend supports it.
Smaller installs: Horizon keeps one shared copy of the prepared game files and removes what only the preparation needed.
A shared resource store keyed by the preparer's digest, no prepare intermediates left behind, the current and the previous version kept, and an automatic clean-up. Not started.
Platforms
Horizon on Linux ARM64
Game and launcher builds for 64-bit ARM Linux computers.
Issue #1709: aarch64 builds of the game and the launcher in the release workflow, tested on a real ARM machine with its Vulkan driver. The server build already drops audio and controllers (--no-default-features).
Versions of Horizon for Android, iOS and web browsers. Nothing official yet; contributors have started the first pieces.
No official build. Android was first closed as not planned, with touch controls, a mobile interface, packaging and loading the player's own assets all missing; the roadmap now includes it, iOS and a WebAssembly build for the browser as long-term goals. First pieces from contributors: horizon-dualsense compiling on iOS (#1813) and helper-thread limits on Android (#1751). Preparing without Java (#1750) matters here too. Horizon ships none of Mojang's files on any platform.
Install Horizon on any Linux distribution as an AppImage, and on NixOS through a Nix flake.
A player's idea (#horizon-ideas). An AppImage of the launcher and game from the release workflow, and a flake.nix packaging the release binaries with their runtime libraries (Vulkan loader, X11/Wayland, ALSA), the way horizon-parity's NixOS setup runs them today.
Horizon extras
A complete video studio inside the game
Record, replay and edit videos without leaving the game: record in a keypress, replay a session, cut and finish the video. One of Horizon's original goals.
Three stages. Recording: capture gameplay in a keypress with an encoder thread and little frame-time cost. Replay: a replay mode for recorded sessions. Editing: cuts, camera paths, titles and export. None of it exists yet; the agent-control socket (docs/agent-control.md) already lets tools drive the game for scripted shots.
An optional look for the game's own menus and options that matches the Horizon launcher. Off by default: the vanilla menus stay as they are.
A player's idea (#horizon-ideas). A built-in resource pack or a Horizon setting that restyles the title, pause and options screens with the launcher's design tokens (crates/horizon-theme), following docs/design-system.md; off by default because it changes the vanilla look.
An optional AI teammate you can talk to by voice. It plays beside you, helps or finishes the game with you, runs on your computer first, and exists only if you turn it on. The No AI switch hides it.
Draft pull requests: the companion (#1068), its safety modes and their evaluation (#1069) and a route that finishes the game (#1070). In the drafts: a companion that follows, fights, mines, crafts, sleeps and respawns; chat and push-to-talk voice, with speech recognition and a choice of voices; presets (very strong, helper, beat the game); a guard model with Clean, Kid and Salty modes; perception levels from Fair to All-knowing; hardware detection with a simple mode and an Advanced tab; local models first, cloud keys optional. The No AI switch is already in the game. Left: the speedrun route doesn't finish the game reliably yet, voices for more languages, and the safety evaluation, which must pass before it ships.
A series of videos about how Horizon is made and what is new, with each upload announced on Discord.
Kira already shows new uploads in a read-only Discord channel (done). The series follows each stage of the project: a script, edits, titles and a thumbnail per video.
Help wanted
Good first contributions: a clear vanilla behaviour, an issue with the steps, a place to start.
Performance
Benchmark your computer
Run Horizon's built-in benchmark and share the report: every new computer makes the performance work more accurate. No coding needed.
horizon-launcher play --arg=--benchmark --arg=standard writes a JSON report; horizon-launcher data benchmark <report> shows what would be sent and uploads it (website/docs/performance.md). Results from three installs with the same hardware appear on the Benchmarks page. Example: #1711.
Banners in End cities show as plain magenta instead of with their pattern.
Compare the banner block entities the End city templates place with vanilla's (EndCityPieces, the templates' block entity NBT, BannerBlockEntity's patterns), in crates/horizon-world/src/worldgen/structure/. Issue #1438; possibly related: #526.
Armour and tools in End city chests should come enchanted, as in vanilla.
loot.rs implements enchant_with_levels: find why the End city chest table's rolls come out bare, and compare them with vanilla's for a few seeds. Issues #1437, #1660.
Horizon now starts on old PCs whose graphics card has no Vulkan or DirectX 12 driver: it switches to OpenGL by itself, and Options > Graphics can pick OpenGL by hand.
wgpu's GL backend (WGL on Windows, EGL on Linux) as the last fallback after Vulkan and DirectX 12 (#1917), sprite arrays and CPU sprite animation for drivers without compute (#1920), no indirect draws below GL 4.3 (#1936). Minimum OpenGL 3.3 core. Shader packs don't run on it yet.
Servers can send you their resource pack: Horizon asks, downloads it and applies it, like vanilla.
The dedicated server offers server.properties' pack (#1562); the client's pack manager, downloads, prompt and Server Resource Packs setting (#1569, #1570).
Search Modrinth for mods, modpacks and resource packs from the launcher; it says before installing what works in Horizon.
The Mods page (#1154), Java mods checked before install (#1242), project pages, filters and galleries (#1243), modpacks ported in the same step (#1246). docs/mod-browser.md.
Single player now runs on its own server thread, as vanilla does, and a run of fixes made shields, tridents, elytra, maps, fishing, signs and books work there and for every server player. Servers can send you their resource packs, the launcher got its blocky new look, and the first pieces of Horizon's mod registry landed. Shader packs were taken out, to come back written from scratch.
The server thread became the default (#1514), after guests and server-thread players reached parity: totems (#1463), death drops (#1464), signs and books (#1465, #1466), shields, tridents, crossbows and spyglasses (#1476), elytra (#1475), maps (#1510), fishing (#1509), wind charges (#1508), strikes and mob effects (#1512), the cursor stack on close (#1513). Server resource packs: the dedicated server offers them (#1562) and the client downloads, asks and applies them (#1569, #1570). Mod registry: index schema 1 and .hpack (#1634), cargo horizon-mod check (#1642), the submission service (#1659). Shader packs were removed (#1561) and the clean-room rewrite started from the format's documentation (#1584 onward). Releases now ship in batches of five pull requests, or six hours after the oldest (#1554).
Pick a good first task or an open issue. On Discord, /claim 1234 tells everyone you are on issue 1234, so nobody starts the same work; /unclaim frees it.
On Discord, /agent connect gives your coding agent a personal token for Kira's MCP server: it reads the work board, claims tasks and posts its progress in your name.
One bug per report: something that breaks, or doesn't play like vanilla. It becomes an issue on GitHub, public, and you get its link to follow it. Search the open bugs first.
An idea for Horizon, or about something on the roadmap. The maintainers read every one, and the good ones become roadmap items. Nothing you send here is published.
Vanilla is the specification. Wherever Minecraft 26.3 has the feature, Horizon does exactly what it does: read vanilla's code, then match it.
Small pull requests, proven. One change each, under about 500 lines, with the block python3 tools/pr_ready.py prints: formatting, Clippy, tests and the harnesses your change can affect.
Say who wrote it. If an AI agent wrote or posts it, the pull request says so, and commits keep its co-author line.
Never commit Mojang's files. No game jars, assets, decompiled code or prepared resources, and nothing taken from other mods' code.
