Yesterday Google switched on the meters for Memory Bank and Sessions, and the expensive one is not the one you were watching. Memory Bank and Sessions began billing on September 1, 2026, according to Google's Agent Platform pricing page. Memory Bank storage is charged on total data stored, including revisions, at $0.30 per GiB-month. Revisions are the snapshots Memory Bank keeps every time a memory changes. Nobody was billed for them before yesterday, so few teams had any reason to configure them — and the parent memories they attach to have no expiry at all unless you set one.
The dollar figure is small. The shape is not. This is the first meter on the platform whose October invoice depends on a configuration decision somebody made in April, not on how much traffic you served in September.
What Actually Turned On, and What It Costs
Memory Bank and Sessions are now billed on three separate lines each, and none of them is a per-conversation price. Per Google's pricing page, Memory Bank bills storage as Agent Storage at $0.30/GiB-month on total data stored including revisions; operations as Agent Compute at $0.085 per vCPU-hour, converted at 3 million read operations or 1 million write operations per vCPU-hour; and model tokens for memory generation and embeddings separately, under their own model SKUs. Sessions bills storage on the same Agent Storage rate and reads at the same 3-million-per-vCPU-hour conversion.
This was the last switch in a staged sequence. Agent Gateway billing commenced on July 13 at $0.085 per 15,000 API or authorization calls, and Memory Bank plus Sessions yesterday — dates given in this breakdown of the platform's billing dates and corroborated by a second pricing FAQ. Google announced the Gemini Enterprise Agent Platform on April 22, 2026 with Memory Bank, Agent Sessions, Agent Registry and Agent Gateway named as components. That is 132 days between launch and the first metered day for agent state.
Seats are a separate contract entirely. Gemini Enterprise editions run $21 per user per month for Business and $50 for Plus, both on annual commitment, per this pricing teardown dated 9 May 2026 — which makes the point that "the seat fee is one of two charges." Consumption is the other one, and it does not appear on the seat invoice. If you are running agents on the Gemini Enterprise Agent Platform, you now have two bills with different owners.
The Unit Changed From Events to Bytes
The old meter counted flow. The new one counts stock, and that is the entire story.
Under the predecessor product, Vertex AI Agent Engine, Sessions and Memory Bank were billed at $0.25 per 1,000 events or memories, with billing that began on February 11, 2026 — a figure independently reported at the same rate and date. A per-event price is forecastable. You multiply conversations by turns, and if traffic stops, the bill stops.
A per-GiB-month price on total data stored behaves differently. It does not stop when traffic stops. It compounds with every user you have ever served, and it keeps billing for state generated by a pilot that ended in June. Amazon took the other road: AgentCore Memory bills short-term memory at $0.25 per 1,000 events, long-term storage at $0.75 per 1,000 records per month with built-in extraction or $0.25 self-managed, and retrieval at $0.50 per 1,000 calls. That is still a record count. You can look at a number in a dashboard and know what next month costs. On Amazon Bedrock the question is how many memories; on Google's platform it is now how many bytes of memory and revision history, which is a question no product dashboard answers directly.
Steel-manning Google here: a byte meter is fairer. A user whose memory is one sentence should not pay what a user with a 40 KB profile pays, and the old per-record price charged both the same. The problem is not the fairness of the unit. It is that the unit is invisible until the invoice.
A Revision Is Created Every Time a Memory Moves
Memory Bank keeps version history by default, and that history is what "including revisions" on the pricing page is pointing at.
Google's documentation defines the object plainly: "MemoryRevisions resources represent the historical states of the parent memory. Each revision is a snapshot of the memory at a mutation event." A new immutable revision is saved on CreateMemory, UpdateMemory, DeleteMemory and GenerateMemories. And a revision is not a diff — each one holds both the intermediate output of the extraction step (extracted_memories) and the final consolidated fact. Every version of the memory carries the raw extraction that produced it.
Two consequences follow. First, the revision chain for an active user can exceed the size of the memory it describes, because each link stores the working-out as well as the answer. Second, revisions outlive the thing they revise: Google's docs state that child memory revisions remain accessible for up to 48 hours after the parent memory's deletion, which is a recovery window you may want and also a two-day tail on every deletion request you process.
Revisions do expire on their own. The default TTL is 365 days, and you can override it per request with revision_ttl or revision_expire_time. Which means the oldest revisions on the platform — the ones written the week it launched in April — will not begin aging out until roughly April 2027. The stock is at its thickest right now, on the first month it bills.
Your Memories Themselves Have No Expiry Date
This is the part that is genuinely off by default, and it is not the revisions.
Google's Memory Bank setup documentation is explicit: "If the configuration is not provided, expiration time won't be dynamically set for created or updated memories, so memories won't expire unless their expiration time is manually set." The parent memory is indefinite. Only the revision chain has a default.
The controls exist and are straightforward. ttl_config takes a default_ttl applied uniformly, or a granular_ttl_config with separate create_ttl, generate_created_ttl and generate_updated_ttl values so a memory written by hand can outlive one the model inferred. Memory Bank's own overview recommends you "set a time to live (TTL) on memories to ensure stale information is automatically deleted" — advice that reads differently now that stale information has a price per gibibyte.
There is a second reason to care that has nothing to do with the invoice. These records are model-extracted facts about named individuals, generated from their conversations and scoped to their user identity. Indefinite retention of that by default is a data-retention posture nobody chose. It is the same class of problem as the retention defaults that quietly overrode zero-data-retention terms elsewhere: the setting was always there, the default was just never examined, because nothing forced anyone to look.
The Compute Meter Is Almost Certainly Not Your Problem
Read the operations line carefully before you spend a sprint optimising it, because the arithmetic says most teams will never pay it.
The published free tier is 50 vCPU-hours of Agent Compute per month. At Google's conversion of 1 million write operations per vCPU-hour, that absorbs 50 million memory writes a month before the first cent — or 150 million reads. It is the same allowance that swallows 750,000 Agent Gateway calls at that meter's 15,000-per-vCPU-hour rate. Unless you are running consumer-scale traffic, the operations line rounds to zero.
Agent Storage does not have that cushion — its free allowance is 1 GiB-month. And the honest magnitude is worth stating plainly rather than dressing up: at $0.30/GiB-month, 100 GiB of accumulated memory and revision history costs $30 a month. This is not a budget emergency. It is a line that grows when nothing else does, that nobody owns, and that will be quietly larger every quarter until someone sets a policy — which is exactly the profile of the costs that turn into six-figure surprises two years later.
The real spend is upstream, and it is the token line. Google bills memory generation and embedding tokens separately under their model SKUs. Every generation pass runs an extraction model over the buffered events and an embedding pass over the result — so the same trigger configuration drives four meters at once: extraction tokens, embedding tokens, write operations, and the revision bytes each pass leaves behind. Memory Bank's continuous ingestion exposes exactly that knob. Generation fires on event_count, idle_duration, fixed_interval or force_flush, with a default auto-flush 24 hours after the last event. Tighten the trigger and all four lines fall together. Analysts covering AWS's equivalent make the same point from the other direction, warning that turning on "all Memory strategies" and "online evals at 100%" during a pilot "is the fastest way to make AgentCore look expensive relative to a thin LangGraph service on ECS".
What to Do Before the October Invoice
This Week:
- Pull your current Agent Storage volume for Memory Bank and Sessions and write the number down. It is the denominator for every decision below, and it is the first month you can actually see it.
- Check whether
ttl_configis set on your Memory Bank instance. If it is absent, every memory you have generated since April is indefinite. Set adefault_ttlyou can defend — 90 or 180 days for inferred memories is a starting position, not an answer. - Decide whether you need revision history at all.
disable_memory_revisionsturns it off entirely on ingestion. If nobody on your team has ever calledListMemoryRevisionsorRollbackMemory, you are paying storage for an audit trail nobody reads.
This Month:
- Read your generation trigger. If you left the 24-hour auto-flush default, or you are firing
GenerateMemorieson every turn, that value is setting your extraction-token bill, your write count and your revision volume simultaneously. Move it to anevent_countoridle_durationthreshold matched to how your agent is actually used, then re-measure all four lines. - Delete the pilot state. Sessions and memories from proofs of concept that ended months ago bill at the same rate as production. Google's Sessions documentation supports deleting session objects and their associated data when conversations are finished; nothing does it for you.
- Test that memory removal actually removes everything. Delete a test memory, then confirm what survives — and remember the revisions stay readable for 48 hours afterward. If you have a deletion-request process, that window belongs in it.
Before Renewal:
- Split the invoice by owner. Seats and consumption are separate charges under separate teams, the same two-meter structure we saw when Claudeforce split throttling from billing. Whoever signs the seat renewal is usually not the person whose config drives the storage line.
- Put a retention clause in the agent-platform section of your contract, not just the data-processing addendum. Ask for a committed-use discount on Agent Storage only after you have set a TTL — otherwise you are committing to volume you have not yet decided to keep.
The Bottom Line
Every agent platform is converging on the same billing structure: a cheap runtime, a generous compute allowance, and a storage line that quietly accrues state you never explicitly agreed to keep. Google's version is more honest than most — the pricing page says "including revisions" in plain text, and the TTL controls have been documented since launch. It just spent 132 days not charging for any of it, and defaults set in a free period are defaults nobody read.
We have argued before that consumption pricing without a cap is a contract you have not finished negotiating, and that a promotional rate is a budget with an expiry date attached. Agent memory adds a third pattern: a meter whose bill depends less on what you do next month than on what you left switched on five months ago. It also comes with a reason to be selective independent of price — memory measurably degraded agent accuracy in benchmark testing, so the cheapest memory is often the one you never generated. The three-layer agent infrastructure Google shipped in April was always going to have a price. Now every layer has one.
Storage is the only meter that bills you for a decision you already made. Go make it again, deliberately, before October.
Continue Reading
- Google Built What OpenAI Couldn't: 3-Layer Agent Infrastructure
- Agent Memory Cost 14 Points at Best. Test With It Off.
- Agentic AI Pricing: Don't Buy Consumption Without a Cap
- GPT-5.6 Sol Is $20 Until Nov 21. Budget Both Rates.
- Agent Orchestration Platforms: Score Exit, Not Features
- Claudeforce Runs Two Meters. One Throttles, One Bills.