FFXIV Tomestone Cap Guide: Weekly vs Inventory Limits

Why one “tomestone total” is not enough

A character can hold 200 tomestones after buying an item while still having obtained the full weekly allowance. The low balance does not mean more can be earned before reset. Conversely, a character early in the week can have weekly room but be close to maximum inventory. A correct plan therefore starts with two observed values: current balance and already obtained this week.

The FFXIV Tomestone Cap Calculator combines those values with two limits: weekly obtainment cap and maximum inventory. It reports the amount blocked by each constraint separately.

Patch 7.4: exact sourced example

Square Enix's Patch 7.4 Notes introduced Allagan tomestones of mnemonics with a weekly obtainment cap of 450 and maximum inventory of 2,000. The related tomestone changes notice explains what happened to older currencies at the same transition.

These values belong to mnemonics in that patch. They are not a universal cap for every FFXIV currency. Always name the currency and version in a saved plan, and replace the limits when the current official note or in-game display differs.

The current-week calculation

1. remaining weekly room = weekly cap − already obtained this week
2. amount passing weekly cap = min(planned additional, remaining weekly room)
3. inventory room = maximum inventory − current balance
4. credited this week = min(amount passing weekly cap, inventory room)

The planned amount above step two is weekly-cap overflow. The amount that passes step two but fails step four is inventory overflow. These labels matter because the corrective actions differ.

Worked example

For mnemonics, enter weekly cap 450 and inventory maximum 2,000. Suppose current balance is 200, already obtained this week is 100, and the player plans another 400. Weekly room is 350, so 350 passes and 50 is blocked by the weekly limit. Inventory room is 1,800, so all 350 can be held. Ending balance is 550.

If the target is 500, it is reached this week. If the balance were 1,900 instead, only 100 of the weekly-approved 350 could be held, creating 250 of inventory overflow. Spending enough before the reward can resolve inventory pressure, but it does not alter the weekly-earned counter.

Plan activities without hardcoding rewards

Read current rewards in game and sum only activities you intend to complete. Keep a short note showing that arithmetic. A useful plan might say “planned additional: 270, from the three current rewards recorded below,” rather than assuming every reader runs the same daily content. If a reward changes, update the note and total without waiting for the calculator code to change.

A planning total is not a guarantee. Queue availability, weekly restrictions, missed sessions, and spending can change the state. Reconcile the calculator after each material event instead of carrying a stale projection forward.

Empty currency-log schema

timestamp_utc,character_label,patch,currency,source_url,balance_before,weekly_earned_before,activity_or_purchase,amount_obtained,amount_spent,balance_after,weekly_earned_after,verified_by

This header is a record template, not observed data. Add rows only from real in-game events. Avoid publishing character identifiers or screenshots containing personal account information.

Future reset boundaries

After current-week credit, the calculator divides the remaining target deficit by the lesser of your planned future amount and weekly cap, rounding up to whole boundaries. It returns zero if the target is already met and “unreachable” if future credited progress is zero. It does not produce a calendar date because maintenance, time zones, and the moment the user starts are not inputs.

Contradictory states

Stop and reconcile when already obtained exceeds the entered weekly cap, balance exceeds maximum inventory, or target exceeds what can be held. Possible causes include selecting the wrong currency, using an old cap, mixing characters, or typing a target that represents several purchases rather than one held balance. The safe response is to fix the state, not to make the formula silently wrap values.

Model purchases as a sequence

A budget for several items is not one oversized inventory target. Suppose a character wants an item costing 500 and then another costing 300. First plan until the held balance reaches 500. When the first item is bought, record a 500-unit spend and start a new scenario from the remaining balance. The obtained-during-period counter stays at the amount displayed by the game; spending affects inventory, not the acquisition history for that reset period.

This transaction approach also handles partial plans. If the first purchase is abandoned, the second scenario begins from the actual held amount rather than a fictional deduction. If the player changes jobs, only the target changes; the currency state remains the observed state of that character.

Keep characters and currencies isolated

An alt and a main may share play time, but they do not share one balance or obtainment counter. Create one record per character label. Likewise, do not add two tomestone types together merely because both can buy gear. Each currency needs its own source, current limits, balance, counter, and target. This makes it possible to explain why one plan is blocked by inventory while another is blocked by its acquisition limit.

Use privacy-safe labels when sharing a plan. “Main healer” and “crafting alt” are usually enough. A copied calculator URL contains the labels and numbers in its query string, so it should not contain account credentials, private identifiers, or screenshots with personal information.

Review evidence, not memory

At each reconciliation, keep a current Lodestone source, a capture of the in-game counters, the arithmetic behind planned rewards, and the current target cost. Mark a number as an assumption when its source is unavailable. Preserve prior scenarios as dated forecasts and append actual transactions to the log; do not rewrite earlier rows to make a projection appear accurate.

A second member should be able to start with the saved balance and obtained amount, apply each recorded earn or spend event, and arrive at the same ending state. If that check fails, pause the forecast and repair the ledger before using it for another purchase decision.

Weekly checklist

• Verify currency name, patch, weekly cap, and inventory maximum.
• Read balance and weekly-earned values directly from the same character.
• Record planned activity totals with their current in-game evidence.
• Check weekly and inventory overflow before claiming a reward.
• After a purchase, lower balance but preserve the weekly-earned value.
• At reset, verify the weekly counter changed before starting a new plan.