Memory retention after days
After 7 days at a forgetting rate of 0.1 per day, about 49.66% of a fully learned lesson is still remembered. Enter the days and the rate, and you also get the share forgotten and the half-life of that rate. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Days
- 7
- Decay rate
- 0.1
- Initial percent
- 100
- Retention percent
- 49.6585303791
- Forgotten percent
- 50.3414696209
- Retention fraction
- 0.4965853038
Teachers, tutors, and learning-app designers often need a single honest number for how much of a lesson is still available to recall after a delay, not another essay on memory theory. This memory retention after days calculator applies the classic first-order exponential forgetting model: remaining percent equals the starting percent times e to the power of minus decay rate times days. You choose the decay rate in inverse days, enter how many days have passed since encoding, and optionally start from a percent already below one hundred when some forgetting has already occurred. Seven days at a decay rate of 0.1 per day from a full encoding returns about 49.66 percent still remembered, plus the complementary forgotten percent, the unitless decay factor, and the half-life in days implied by that same rate. A zero-day delay returns the starting percent unchanged.
What exponential forgetting after a delay actually computes
Human recall after a single encoding session is often modelled as a smooth exponential fade rather than a linear drop or a sudden cliff. The model used here is the same first-order law that appears in Ebbinghaus-style forgetting curves and in every introductory treatment of memory retention as a function of time: retention percent equals initial percent times exp of minus decay rate times days.
The decay rate k is a positive constant with units of one over a day; a larger k means the trace fades faster, and a smaller k means the material is more stable. Multiplying k by the elapsed days produces the dimensionless product kt that sits in the exponent, so doubling either the rate or the delay multiplies the exponent and squares the remaining factor when the other term is held fixed.
The complementary forgotten percent is simply the starting percent minus the remaining percent, which keeps the two shares adding back to the start instead of inventing a third residue. The half-life field is ln(2) divided by k and answers a related planning question: how many days until the remaining share is half of whatever you started with. A delay of zero days is a valid identity case—the decay factor is one and the remaining percent equals the start—because no time has elapsed for the trace to fade.
The model does not claim to be a full spaced-repetition engine: it does not schedule reviews, change k after a successful retrieval, or mix in item difficulty. It answers one search intent cleanly: given a chosen decay rate, what percentage of the material is still remembered after a stated number of days.
Who uses a forgetting estimate, and why
Exam-prep coaches and tutoring platforms embed the free browser path so a learner can see why waiting two weeks without review leaves far less of a lecture than waiting two days, using a decay rate the coach picked from classroom data rather than a hidden default. Flashcard and LMS backends call the same pure module when they need a transparent preview of remaining recall before they invest in a heavier spaced-repetition scheduler that updates stability after each review.
Teachers can demonstrate the half-life reading: pick k so that ln(2)/k is seven days, then show that one week later the remaining share is half of the start, which is a cleaner classroom check than asking students to evaluate e to a messy power by hand. Failed validation does not consume balance, which keeps exploratory scripts cheap when developers intentionally send a negative delay or a zero rate.
Prefer this capability when you already have a decay rate and only need the remaining percent after a delay; if your plan includes review scheduling, difficulty, or a stability update after retrieval, layer those policies outside this pure exponential evaluation.
What you can do with it
Exam delay previews
Show a student how much of a lecture is still available to recall after 3, 7, or 30 days at the decay rate their coach calibrated.
Flashcard and LMS planners
Preview remaining retention before a review is due so dashboards can flag items that will fade below a chosen percent.
Classroom forgetting-curve demos
Let teachers vary k and days live, then check the half-life identity ln(2)/k against the remaining percent by hand.
FAQ
Can I start from a percent that is already below 100?
The next interval multiplies that start by exp(−k × days).
How much do I remember after a week?
It depends on the decay rate you pick. At 0.1 per day and a full start, about 49.66% remains after 7 days, so roughly half the material is gone. A smaller rate leaves more, a larger one less.
What is the half-life of a memory in this model?
It is the number of days until the remembered share falls to half of where it started, found by dividing the natural log of 2 by the decay rate. At 0.1 per day it is just under 7 days.
What decay rate should I use?
Classroom and flashcard estimates usually sit between 0.05 and 0.25 per day. A larger rate means the material fades faster, and a smaller one means it stays more stable over the days.
Does it plan my review sessions?
No. It answers one question: how much is left after a given number of days at a given rate. It does not schedule reviews or change the rate after you study the material again.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/edu/memory-retention-after \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"days":7,"decay_rate":0.1}'const res = await fetch("https://api.kit.forhosting.com/edu/memory-retention-after", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"days": 7,
"decay_rate": 0.1
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/edu/memory-retention-after",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"days": 7,
"decay_rate": 0.1
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/edu/memory-retention-after", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"days":7,"decay_rate":0.1}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"days":7,"decay_rate":0.1}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/edu/memory-retention-after", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"days": 7,
"decay_rate": 0.1
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "edu.memory_retention_after",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Negative days, a missing decay rate, or a non-positive rate fail with invalid_input instead of inventing a growth curve.
Input contract, response shape, and error behaviour
Prefer plain numbers over percent signs or unit suffixes; numeric strings are accepted only when they match a strict finite number pattern. POST a JSON body with two required finite numbers and one optional starting percent. days (aliases elapsed_days, t, time_days, after_days) is the non-negative elapsed delay since encoding. decay_rate (aliases k, lambda, rate, decay, forgetting_rate) is the strictly positive forgetting constant in inverse days; typical classroom and flashcard calibrations sit near 0.05 to 0.25 per day, but any positive finite value inside the absolute limit is accepted. initial_percent (aliases initial, r0, start_percent, initial_retention) defaults to one hundred when omitted and must be greater than zero and at most one hundred when present, so a second call can start from yesterday’s remaining percent instead of resetting the encoding. Absolute values stay within one trillion so the product kt and the exponential stay finite on the Worker and in the browser. On success the response echoes rounded days, decay_rate, and initial_percent; sets retention_percent to the remaining share; forgotten_percent to the complementary drop from the start; retention_fraction to remaining over one hundred; decay_factor to exp of minus kt; half_life_days to ln(2) over k; kt to the dimensionless product; formula to the documented identity; message to a short English summary; and steps to an ordered array of substitution lines you can print next to a worksheet. Validation failures—missing fields, non-finite numbers, values outside absolute limits, a negative delay, a zero or negative decay rate, or a starting percent outside the open-closed (0, 100] window—return invalid_input and are not billed. Pricing is a fixed $0.002 per successful call with unit item.
Technical questions
How do I predict memory retention after a number of days?
Send days (non-negative) and decay_rate (strictly positive, in 1/day). Optionally send initial_percent (default 100). The API returns retention_percent = initial_percent × exp(−decay_rate × days).
What does the decay rate mean in this forgetting model?
decay_rate is the exponential constant k with units of inverse days. Larger k fades faster. The implied half-life is ln(2)/k days: after that many days the remaining share is half of the start.
What happens if days is zero?
A zero-day delay is valid. The decay factor is 1 and retention_percent equals initial_percent, because no time has elapsed for the trace to fade.
What does the memory retention after days calculator cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.