Exit code: 0
Wall time: 0.3 seconds
Output:
Valheim 1.0 Achievement Rules: Cheats, Spawned Items, Hammer Mode, and Mods
Valheim 1.0 will not retroactively turn every old save into an achievement run. Iron Gate says existing worlds remain usable, but tracking begins when you download 1.0, and the save history that matters includes more than whether cheats are switched off when you start playing. A character can carry a permanent cheat flag, a clean character can temporarily become ineligible by picking up a marked item, and Hammer-mode sits in a separate category that the FAQ calls a temporary cheat.
The practical problem is that the official rules stop short of a complete whitelist. Iron Gate has not published a safe list for every console command, world modifier, Global Key, or mod. This guide separates what the 1.0 documentation confirms from what it leaves open, then turns those boundaries into the safest setup for players who want achievements without sacrificing a separate sandbox for testing.
Quick boundary:
- Permanent: Most devcommands, including
spawn, flag the current character and world save. - Temporary: Picking up a marked cheated item can block that character; discarding all cheated items is the documented recovery path. Hammer-mode is also temporary, but its recovery boundary is unspecified.
- Undocumented: Iron Gate has not published a complete eligibility list for individual world modifiers, Global Keys, or mods.
When 1.0 achievement tracking begins
Valheim 1.0 is scheduled for September 9, 2026, and Iron Gate has set a clear boundary for achievement statistics: tracking begins when you download the 1.0 update. Existing saves remain usable, so you do not have to abandon an established world simply because it began in Early Access. Usable, however, does not mean that its earlier progress is converted into achievement progress.
Consider two characters fighting Eikthyr. If the first character kills Eikthyr before downloading 1.0, that victory is part of the old save history and is not counted retroactively. If the second character defeats Eikthyr after downloading 1.0, that action occurs inside the new tracking period. The distinction is the date of the action relative to the 1.0 download, not whether the character or world was newly created.
The same boundary applies to cheat history. A character that used cheats before 1.0 remains marked after the update, even if cheats are disabled before continuing the save. Before choosing an old character–world pair, check both what progress it already contains and whether the character has any pre-1.0 cheat history. Once 1.0 is installed, treat that moment as the beginning of the achievement run; the next concern is which cheat actions permanently bind a character to its world save.
Most cheats permanently bind a character to a world save
The strongest confirmed rule is persistent: most devcommands, including spawn, place an achievement-blocking flag on both the current character and the world save. The console itself is not identified as a violation; on supported setups, -console enables it, while most commands require devcommands. The risk begins when you enter a cheated state, and after 1.0 the game requires confirmation before that happens.

The console exposes commands, but the 1.0 FAQ does not publish a complete safe-command list.
Consider a player who uses spawn Iron before 1.0, turns cheats off, and keeps playing. The character’s pre-1.0 cheat history still carries into 1.0, while the world used by the command remains permanently marked.
Iron Gate does name an exception: freefly. That does not create a complete safe-command list. Commands such as fly, ghost, god, and debugmode are therefore not confirmed safe merely because they are useful for movement, combat, or building. Unless a command is explicitly documented as an exception, keep testing it outside the character–world pair reserved for achievements.
Treat the confirmation prompt as a warning, not a reversible toggle. Use a separate character and world for unlisted cheat-command experiments, and never assume that turning cheats off resets the save. A permanent command flag is not the only risk, because picking up a marked item can temporarily make a clean character ineligible.
Spawned items create a separate temporary risk
A spawned item is not treated like an ordinary item simply because it is now sitting in a chest or on the ground. Iron Gate says items created through commands such as spawn are visibly marked as cheated, making them identifiable before you use them or pass them to another player.
That marker matters to a clean character. If you join a friend’s world and pick up one of those items, your character enters a temporary cheat state. Achievements are blocked while that state lasts, even though you did not create the item or activate the command yourself.
Iron Gate’s documented recovery path is to throw out all cheated items from the character’s inventory. Once the marked items are gone, the character can become eligible again. This is a temporary character-level risk, distinct from the permanent character-and-world flag caused by most cheat commands.
The documentation does not explain every downstream case. It does not establish whether storing a marked item, transferring it between containers, crafting with it, or using it in construction propagates the temporary state through a character or shared world. Until Iron Gate clarifies those paths, treat storage, transfer, crafting, and construction involving marked items as unresolved.
For an achievement-focused character–world pair, refuse marked items rather than relying on cleanup later: do not transfer them, store them, craft with them, or pick them up casually. If a clean character picks one up, discard every cheated item as the documented recovery step. That recovery path is documented for removing cheated items from the character’s inventory; Hammer-mode is a separately classified temporary cheat with a less clearly defined exit condition.
Hammer-mode is temporary, but its recovery boundary is unspecified
Hammer-mode blocks achievements while it is active, and Iron Gate explicitly classifies it as a temporary cheat. That makes it different from an ordinary difficulty preset, even though its main effect looks builder-friendly: it removes material costs for hammer-buildable pieces, while crafting-station gear still requires its usual costs.
For example, enabling Hammer-mode to construct a large base without gathering hundreds of pieces is still an achievement-blocking cheat state. Turning it off afterward may feel like returning the world to normal, but Iron Gate has not documented whether leaving or resetting Hammer-mode automatically restores achievement eligibility. The word “temporary” distinguishes it from the permanent flags attached to most cheats; it does not provide a documented recovery procedure.
Keep Hammer-mode outside the character–world pair reserved for achievements unless you accept uncertainty about recovery. Do not promise that resetting the setting makes the world clean again. Because Hammer-mode is the only specifically named world-modifier blocker, the next question is whether other modifiers have the same status—or whether their achievement behavior remains undocumented.
Other world modifiers remain only partly documented
World modifiers can be configured through the Join World screen, dedicated-server startup settings, or console commands. Those interfaces document how settings are applied, not whether each setting preserves 1.0 achievement eligibility.

The interface shows where modifiers are applied; it does not by itself prove which settings preserve 1.0 achievements.
Iron Gate says that some world modifiers block achievements, but it does not publish a complete list. Resource rates, combat settings, portal rules, raid frequency, death penalties, and related options are documented gameplay mechanics without a confirmed achievement classification. If you raise resource rates or change portal settings through the world menu, the available documentation cannot classify that world as guaranteed achievement-safe—or prove that the setting is universally disqualifying.
The same uncertainty applies to Global Keys. setkey can manipulate world behavior, including keys without corresponding menu sliders, but no source confirms that every key permanently flags achievements. Likewise, setworldpreset, setworldmodifier, and resetworldkeys show that settings can be changed or reset; a reset restores world settings, not documented achievement eligibility.
Dedicated-server hosting is not an automatic exception. In-game cheat commands may be unavailable there, but server-side presets, modifiers, and keys remain configurable. The server type therefore cannot establish that every resulting world is achievement-safe.
For a guarantee-focused run, avoid unlisted modifiers and setkey changes. Do not infer safety from the Join World interface, a preset name, a reset command, or dedicated-server hosting. The same documentation gap applies to mods, whose official status concerns compatibility and support rather than achievement eligibility.
Mods have no confirmed achievement status
Mods remain outside Iron Gate’s confirmed achievement rules. Its official guidance says that Iron Gate provides no official mod support and cannot guarantee that mods will remain compatible when Valheim 1.0 releases. That is a compatibility warning, not a statement that loading mods disables achievements.
The platform limitation does not resolve the eligibility question. Console versions will have no official mod support or Steam Workshop support at 1.0, but Iron Gate still has not published a rule saying that PC mods disable achievements or that any particular mod is safe.
Consider a quality-of-life inventory mod that does not spawn items. The absence of spawned items does not prove that the setup is achievement-eligible. Iron Gate has not ruled on whether that kind of mod preserves achievements, nor has it established whether mod-created items receive the same cheated-item marker as items created with spawn.
Treat every modded setup as unguaranteed for achievement purposes. Compatibility guidance can tell you whether a mod may work; it cannot serve as an achievement whitelist. With cheats, modifiers, and mods separated into confirmed rules and unknowns, you can choose the safest practical setup.
The strongest clean-run setup is separate and conservative
If you want the strongest practical guarantee, reserve a separate, unmodded character–world pair for achievement tracking after downloading 1.0. This is an editorial recommendation based on the documented boundaries, not an official whitelist. Iron Gate confirms that tracking begins with 1.0, that pre-1.0 cheat history carries forward, and that most cheat commands permanently affect the current character and world save.
Keep an existing modded or cheat-tested save for experimentation, building, shared-world testing, and spawned-item checks. Do not treat it as the clean run merely because cheats are later disabled, marked items are discarded, or a setting is reset. Hammer-mode is explicitly a temporary cheat, but its recovery procedure is unspecified; other world modifiers and Global Keys also lack a complete achievement classification.
The clean pair should therefore exclude permanent cheat commands, spawned or visibly marked cheated items, Hammer-mode, and unlisted modifiers. Mods belong in the experimental environment as well: Iron Gate’s statements address compatibility and support, not whether achievements remain enabled, and they do not establish that mod-created items receive the same marker as spawn items.
After downloading 1.0, use the isolated pair for normal progression and keep every undocumented exception outside it. That separation preserves the freedom to test the game elsewhere while giving guarantee-focused play the clearest available boundary.
