How to track your commitments with AI: 48-Hour Context Window — Expand or Trim?

This guide defines a 48-hour context-window decision for AI commitment tracking: trim to a structured commitment ledger plus rolling 48-hour recall, or expand when handoffs span more than two days of unlogged conversation. It gives a one-week audit rule and monthly re-audit to verify whether the window should be expanded or trimmed.

How a 48-Hour Window Actually Works

A context window is finite working memory. As a conversation grows, the space available for tokens runs out, and to make room for new messages, the oldest tokens are evicted first. This is a positional cutoff, not a filter based on importance. Because of that, a commitment stated at the beginning of a long chat thread can be pushed past that cutoff by later messages, leaving it outside of the prompt entirely even though it was made in the same session.

The failure happens at the eviction boundary, not at inference. The model never deliberately chooses to forget a commitment. If the exact text of that commitment is no longer present in the tokens it receives for a given turn, there is simply nothing for it to reference. A follow-up question about it will be answered only from what remains in that truncated slice, so the commitment can disappear from the model's awareness without any explicit notice that it was dropped.

This is what makes the expiration silent. The visible chat history in the interface can still show every message you sent, creating the illusion that the full thread is available. The check to make here is the distinction between those two things: what you can see, and what the model is actually being given. If you cannot point to the commitment text inside the current prompt slice, you cannot rely on the model to act on it, regardless of how recent or clear it was when you first stated it.

The mechanism itself points to one direct response: externalization. Since position in the thread determines survival, the commitment must be written to a persistent place outside of the session, such as a file, database, or task tool. By removing the commitment from the stream of tokens that are subject to eviction, its existence no longer depends on how old it is within the chat. This breaks the link between context aging and commitment visibility, which is the only way to prevent those silent expirations from occurring in the first place.

Audit Your Drops Before You Expand

Before changing window size, run the one-week handoff-receipt audit that decides expand vs. trim. For every commitment made to the AI or by the AI over seven days of sessions, make a receipt: date stated, date due, and where it lives (thread only vs. ledger).

Only log explicit commitments with an action or deliverable, not general questions. Do not rely on guesswork or session length alone to make the expand-or-trim call — the audit receipts are the decision input.

For each receipt, check if it was still honored after 48 hours from the moment it was stated. Sort any failures by timing, not by how many occurred. A commitment dropped while still inside the window is a prompt or orchestration problem. A commitment dropped after eviction past 48 hours is a window-size problem. This split is the threshold for action, because the fix for each failure mode is different and one cannot stand in for the other.

To judge the weight of post-eviction drops, you do not need a global total. As noted by The $8.9 Trillion Cost of Broken Commitments at Work, broken commitments carry broad organizational impact, but for your personal tracking you only need your own count of commitments that aged out past 48 hours. If zero commitments aged out past 48 hours during your audit week, expansion buys you nothing for commitment tracking, so trim to a ledger-plus-recall design and re-audit monthly. If at least one did age out past 48 hours, expansion can be justified for that handoff pattern, but only to cover those unlogged spans.

Keep every receipt from that week in one place until your next monthly re-audit. Do not collapse the two failure modes into one score, and do not change window size until you have completed all seven days. The decision must come strictly from post-eviction drops found by this audit, or the lack of them.

Expand vs. Trim vs. Ledger: Compared

When comparing the three architectures for keeping personal commitments alive, the tradeoff comes down to precision versus prompt size. Expanding to a larger window can seem like the safest route, but it only helps when commitments genuinely span more than two days of continuous unlogged conversation. Outside of that narrow case, adding more tokens costs more space and degrades retrieval as the prompt grows. The agent is not choosing what is important, so more history does not guarantee better recall, it just makes the search harder.

Aggressive trimming by summarization takes the opposite approach by keeping the prompt small. On the surface, this preserves room for new messages, but compression is inherently lossy. A commitment summarized as "follow up soon" loses its deadline with no way to recover it from that phrase alone. For any commitment that requires a specific action, that loss of detail is the exact kind of failure that cannot be fixed by making the summary shorter.

Between these two, the ledger-plus-recall design is the winner. Instead of forcing every promise to compete for space inside an evicting window, commitments live in a structured store that the agent reads on demand. Only the current working slice stays in the rolling recall, so the window carries what is being acted on right now, not every past handoff. The store becomes the source of truth for survival, while the slice exists purely for immediate context. This split keeps the prompt lean without relying on vague compression.

The key check is not which option is universally better, but which one matches the shape of your handoffs. If your commitments never outlast the recall slice, you gain nothing from expansion and you risk losing precision from trimming. If they do outlast it, the store must cover them regardless of window size. By treating the ledger as the anchor and the recall slice as temporary, you avoid bloating the prompt while still preserving the exact actions that would otherwise vanish. This comparison alone shows that the ledger-plus-recall design is the correct default for the general case.

Costs and Numbers That Matter

Once the audit tells you which architecture fits, the decision comes down to what each one costs you — and all three costs are measurable in your own logs. Expansion costs tokens; trimming costs re-explanations; being wrong costs either waste or a dropped commitment. None of these require a vendor quote to price.

Expansion cost scales roughly linearly with retained history: double the retained conversation, roughly double the prompt tokens on every session. To price it, pull your provider's per-token rate from its published pricing page, measure your average session length in tokens after expansion, and multiply. The result is a per-session figure you can annualize against your session frequency. If that number feels abstract, compare it to what you already pay for the sessions themselves — expansion is a multiplier on your existing usage, not a new line item.

Trimming has a different cost structure. The ledger-plus-recall design keeps prompt tokens low, but its real price is the re-explanation event: every time a commitment ages out of the recall slice and you have to restate it from the ledger, that costs minutes. Log those minutes for a week. Multiply by how often you'd realistically hit that event, and you have your trim tax. If the tax is near zero — because your ledger entries are terse and restating one takes seconds — trimming wins on cost alone.

Being wrong in either direction is the expensive case. Expand when you don't need to, and you pay the token multiplier on every single session for nothing. Trim when your commitments genuinely span more than two days of unlogged conversation, and you pay in drops — and broken commitments are not a trivial loss; analyses of workplace follow-through attribute trillions in lost productivity to them (heywren.ai). A dropped commitment is the one cost with no recovery mechanism in the session itself.

Re-run the pricing monthly alongside the audit. Token rates and your own session patterns both drift, and the cheap option last month is not guaranteed to stay cheap.

What the Evidence Does Not Establish

The evidence does not establish any universal 48-hour threshold. For the purpose of this design, it is only a default, not a measured constant. Your own sessions may show your real boundary is shorter or longer, so the number itself should never be treated as fixed.

With that in mind, the trim rule does not hold in every case. For multi-day negotiations, such as contract redlines, the full thread can be the commitment itself. In that edge case, trimming to a ledger-plus-recall design will lose what needs to be carried forward, and the correct action is to either expand the window or export that thread directly into the ledger.

However, there is also a case where expansion cannot help at all. If a commitment is stated verbally outside the AI entirely, no window size will recover it. The fix is capture, not expansion.

The point is not to chase the largest window possible, but to know exactly when the trim rule breaks versus when it still wins. That distinction is the limit, and it is the only one this section establishes.

One Week, One Ledger

Here is the concrete 7-day audit with checkpoints and the commitment-ledger layout. Start on Monday by logging every commitment you make with the AI into a single place.

For each entry, you must record the exact commitment, when it was stated, when it is due, whether it lives in the thread only or in the ledger, and its status. The point of this split is to test two groups against each other, not to catalog everything for its own sake.

By Wednesday, run your first checkpoint. Only test the thread-only items from your Monday log by asking the AI to recall them unprompted, with no pasted exchange. Do not test ledger items at this time. For each thread-only item you test, mark it as recalled or unrecalled. Keep a running count of how many of those tested thread-only items fell into unrecalled. This is a check of presence, not a check of effort.

By Friday, run your decision checkpoint using those counts. For example, if 3 of 5 thread-only commitments were unrecalled by Friday while all ledger items were honored, the thread is losing commitments to eviction — trim to ledger-plus-recall and skip expansion. Judge each unrecalled item against the 48-hour threshold: a drop past 48 hours points to window size, a drop inside 48 hours points to prompt design.

The comparison is between the two groups: the ledger group shows what is preserved by logging, and the thread-only group shows what is lost to position. This is a direct comparison of counts, not a projection of the entire window.

To make this repeatable, use a commitment ledger with one row per entry. A worked example row looks like this:

The thread-only rows are the ones exposed to eviction; the ledger rows are the control group.

Fill it in full on Monday, update status as you go, and only use it to hold the items you do not want to rely on thread position for. The grounding sources for this article cover organizational productivity costs and contract-clause language, not personal AI commitment tracking, so treat the ledger design here as an untested default: verify with your own one-week audit whether logging commitments actually prevents drops before relying on it.

Close out the week by recording only your tested counts and the outcome for both groups. If the ledger group had no drops and the thread-only group had drops at or before Friday, move those dropped items to the ledger going forward and keep a rolling recall slice for the rest. If no thread-only items were dropped by Friday, you can still trim to ledger-plus-recall, but do not expand without seeing a drop beyond the boundary you just measured. Re-audit monthly using this same Monday-Wednesday-Friday checkpoint to catch any shift.

Decision Rules: Expand or Trim

Your audit is done; now apply the rules. If your audit shows a commitment was dropped because it aged out past 48 hours of an active thread, then expand the window or export the thread into your ledger.

Do not simply re-prompt. Re-prompting re-creates the commitment in the same fragile position it occupied before, and the next eviction cycle will take it again. The fix is structural: either give the thread more room or move the commitment out of the thread entirely.

If every drop happened inside the window — the commitment was stated and forgotten while both messages were still in context — then trim. The problem is prompt design, not capacity. Adding more context in this case makes retrieval worse, not better: a larger haystack buries the commitment deeper, and the model's attention dilutes across more tokens competing for the same recall. Trim to the ledger-plus-recall design, tighten how commitments are phrased when entered, and re-audit monthly to confirm the drops stop.

If your commitments span multiple days of negotiation — terms evolving across several sessions before they settle into something actionable — do not pay for permanent window expansion. Instead, move the full thread into the ledger as an artifact. The ledger holds the negotiated outcome and its history as a durable record; the live session only needs the rolling 48-hour recall slice to stay oriented. This is the same logic behind formal productivity commitments in contract clauses, where Law Insider's sample agreements show organizations writing down agreed terms and retention periods rather than relying on anyone's memory of the negotiation.

One boundary check before you commit to a choice: expansion only wins when your handoffs genuinely span more than two days of unlogged conversation. Verify this by timestamping each dropped commitment against the thread it lived in. If the gap between the commitment's statement and its expiry is under 48 hours, expansion is buying you nothing. If it crosses that line repeatedly across the audit week, expansion — or thread export — is justified.

Re-audit monthly regardless of which path you take. Commitment patterns drift: a month of ledger discipline may shrink your multi-day negotiations, or a new project may push handoffs past the two-day line. The decision rule is not permanent architecture; it is a recurring check that the window size matches the actual lifespan of your commitments.

What to do next

Frequently Asked Questions

When should I expand the AI context window instead of trimming it?

Expand only when handoffs cross more than two days of unlogged conversation.

What should I audit before choosing whether to expand or trim?

Audit one week of AI sessions before deciding whether to expand or trim the context window.

What should I do if a commitment was dropped because its context aged out beyond the window?

If any commitment was dropped because its context aged out beyond the context window, expand; otherwise trim.

What is the default design if I trim the context window?

Trim to a structured commitment ledger plus a rolling recall slice unless commitment handoffs span more than two days of unlogged conversation.

What follow-up policy applies after trimming to the ledger-plus-recall design?

Re-audit the ledger-plus-recall design monthly after trimming.

What should the monthly re-audit verify?

Re-audit monthly to verify whether commitments still fit the structured ledger plus rolling recall.

Quick answers

Also worth reading: How to Beat the 60% Retention Cliff: 89% Context Loss Reduction: How to Beat the 60% · AI Context Switch: 23-Min Median Is Worst Case, Not Universal: AI Context Switch: 23-Min Median · What Happens When Your AI Agent Takes Over Meeting Prep: A 2026 Field Report: What Happens When Your AI