Last reviewed: 2026-08-31

Direct answer

A safe file search vector store expiration policy starts with inventory, not deletion. Enumerate every store across the relevant providers, projects, and regions. For each store, record its owner, workload, status, provider-reported size, last activity, retention class, expiration setting, and restore path. Then notify the owner, apply an inactivity-based policy, and verify both retrieval behavior and the billed storage meter after the policy takes effect.

Do not infer this exposure from token traffic alone. The OpenAI vector-store API reference exposes lifecycle fields including usage_bytes, last_active_at, status, file counts, and an expires_after policy anchored to last activity. The Azure OpenAI pricing page publishes File Search and vector-storage pricing entries separately. That separation is the reason to keep persistent retrieval storage on its own ledger line rather than hiding it inside input-token cost.

Expiration is a safety rail, not an instant cost switch. Its result depends on what counts as activity, how long the inactivity window is, and what the provider does when a store expires. Microsoft documents that conversation-helper stores have a seven-day inactivity default and that response generation fails after the attached store expires. A production policy therefore needs an owner, a warning period, and a tested recovery procedure.

Who this is for

This guide is for AI platform engineers, retrieval owners, FinOps practitioners, and service operators who use managed file search or vector indexes. It is especially relevant when temporary conversations, evaluations, support cases, or sandbox applications create stores automatically and no person is clearly responsible for removing them later.

It also applies to teams using an AI gateway. Gateway token records can explain model consumption, but they may not contain the provider-side state needed to govern retained vector data.

Key takeaways

  • Treat each vector store as a billable resource with an owner, purpose, retention class, and restore path.
  • Use the provider-reported storage measure for the store. Uploaded source-file size is not a reliable substitute for processed retrieval storage.
  • Keep storage, file-search calls, reads, writes, and model tokens as separate cost categories.
  • Apply expiration only after confirming the activity anchor and testing what happens to an attached application.
  • Stop destructive work when inventory coverage is incomplete, ownership is unresolved, or ingestion is still changing state.
  • Delete the narrowest object that meets the policy. Removing one store association is not always equivalent to deleting an underlying file everywhere.

Sources checked

  • The OpenAI Create vector store reference defines usage_bytes, last_active_at, file_counts, lifecycle status, and expiration anchored to last_active_at. It permits an expiration interval from 1 through 365 days.
  • The Microsoft Foundry vector-store guide explains asynchronous ingestion, attachment limits, file-removal scope, configurable expiration, and the seven-day default for conversation-helper stores.
  • The Azure OpenAI pricing page is the source to check for current File Search and vector-storage pricing units. Copy the applicable displayed terms into the cost record at review time instead of hard-coding a rate into a permanent runbook.
  • The Pinecone cost guide separates serverless vector costs into storage, read units, write units, and egress. It also describes storage as a function of index size, reinforcing the need for a distinct storage budget line.

Contract details to verify

Before enabling automatic expiration, create a provider contract sheet and verify these details:

  • Inventory scope: Identify every organization, project, region, environment, and pagination boundary that the inventory job must cover.
  • Object state: OpenAI reports expired, in_progress, or completed store states and separate file counts. Microsoft recommends waiting until ingestion is complete before relying on the store for responses.
  • Attachment scope: Microsoft currently documents at most one store attached to an agent and one attached to a conversation. An attachment view is therefore not a substitute for an organization-wide store inventory.
  • Activity semantics: Confirm which operation updates the activity clock. OpenAI supports last_active_at as the expiration anchor, while Microsoft describes conversation-store activity as use during response generation.
  • Expiration bounds: Confirm the allowed interval and whether a default exists for the exact creation path. The OpenAI reference permits 1 to 365 days; the Microsoft seven-day default applies specifically to stores created through conversation helpers.
  • Deletion scope: Confirm whether an operation removes a file from one store, deletes the store, or removes the underlying file from every association. Microsoft warns that deleting the underlying file removes it from all vector-store configurations in the organization.
  • Billing terms: Record the current storage unit, time unit, applicable allowance, currency, and reporting boundary. Normalize those units before comparing providers.
  • Recovery behavior: Document how to recreate a store, wait for ingestion, reattach it, and run a retrieval smoke test.

Happy-path operator workflow

  1. Run an inventory-only collection. List stores from every in-scope project and region, follow pagination, and retrieve details for each result. Do not change state during this pass.
  2. Map ownership. Join each store to an application, environment, cost center, and accountable team. If that mapping does not exist, use the process in Allocation Owner Mapping for AI API Costs .
  3. Measure exposure. Capture usage_bytes or the provider’s equivalent and normalize it to the pricing page’s storage unit. Use this general calculation only after matching the provider’s units:
estimated_storage_cost = normalized_billable_size × current_storage_rate × billed_time
  1. Assign a retention class. Separate temporary conversation stores, test stores, active shared knowledge stores, and records subject to an approved retention hold. Set an explicit interval or manual-review rule for each class.
  2. Notify and protect recovery. Give the owner a clear expiration date, the measured size, the reason code, and instructions for requesting an exception. Confirm that the source files and attachment procedure needed for recovery still exist.
  3. Test the policy in a nonproduction store. Apply the expiration setting, verify the returned policy and anchor, and confirm that normal retrieval still works before expiry.
  4. Expire or delete deliberately. At the end of the warning period, re-read the store. Proceed only if its owner, status, last activity, and policy still match the approved decision.
  5. Verify service and cost evidence. Confirm the resulting state, inspect attachments, run the planned smoke test, and reconcile the storage meter in the next available usage record. Keep this reconciliation separate from model-token evidence; Trace CometAPI Cost and Usage for Token Budgets provides a useful evidence pattern.

Error-path operator workflow

  • If any inventory request fails or a page cannot be retrieved, mark the run incomplete and stop all automated deletion. Retry within the approved request budget, then escalate with the affected provider, project alias, region, operation, status category, and observation time.
  • If a store is in_progress, has failed files, or changes while the decision is being reviewed, move it to a manual queue. Do not treat incomplete ingestion as evidence that the store is abandoned.
  • If last_active_at is null, do not convert null into an old timestamp. Use creation time, application evidence, and owner confirmation to make a manual decision.
  • If the owner cannot be resolved, apply the organization’s orphan-resource process and warning window. Do not silently retain the store forever, but do not delete it solely because a tag is missing.
  • If a policy update is rejected or the provider does not support inactivity expiration, open a scheduled review or deletion task with the same approval and verification controls.
  • If response generation fails because a conversation store expired, follow Microsoft’s documented recovery path: recreate the store from the approved files, wait for ingestion, reattach it, and rerun the retrieval test.
  • If a delete request appears successful but a subsequent read shows the resource remains, record the mismatch and investigate. Repeating destructive calls without checking state can obscure the original failure.

Sanitized evidence record

Log operational facts without storing file content, search queries, full filenames, personal identifiers, or authentication material. A compact record can look like this:

event_name: vector_store_retention_review
provider: example-provider
project_alias: search-sandbox
region: region-a
store_id: store-demo-42
owner_team: support-search
workload_class: temporary-conversation
status: completed
file_count_total: 18
file_count_failed: 0
usage_bytes: 24000000
last_active_at: 2026-08-20T14:00:00Z
expiration_anchor: last_active_at
expiration_days: 14
decision: retain-until-expiry
reason_code: owner-approved-policy
change_record: change-204
observed_at: 2026-08-31T00:00:00Z

Use controlled aliases for projects and teams if their real names reveal customer or internal details. Store source extracts and approvals in the evidence system, not in general application logs.

Failure modes

  • Expiration breaks an active conversation. A policy that is shorter than the real return interval can expire the attached store before a user comes back. Test recovery and warn the owner before enforcement.
  • A background check keeps resetting activity. If a health check performs response generation against the store, it may make an abandoned workload appear active. Separate service-health evidence from business use.
  • The wrong file object is deleted. Deleting an underlying file can remove it from multiple agents or conversations. Resolve association scope before changing state.
  • Uploaded bytes are used as billed bytes. Managed services parse, chunk, embed, and index files. Use the provider’s reported store measure and verify its relationship to the billing meter.
  • The inventory misses resources. An omitted project, region, or pagination page produces a false clean result. Record coverage and fail closed on partial collection.
  • Automatic deletion races ingestion. A store that is still processing can look unused while files are not yet searchable. Gate lifecycle actions on stable state.
  • Expiration is mistaken for verified deletion. An expired status proves that the store is unavailable under that contract; it does not by itself establish every data-removal or billing consequence. Verify those separately.
  • Cleanup operations create their own cost. Other managed vector systems can meter delete operations. Pinecone, for example, includes deletes in write-unit accounting. Include cleanup-operation cost when the provider contract requires it.

FAQ

Does setting an expiration policy reduce cost immediately?

Not necessarily. The OpenAI contract schedules expiration after the selected number of days from last_active_at. Verify the resulting status and the provider’s billed storage record rather than recording savings when the policy update is merely accepted.

Should I delete a vector-store file or the underlying file?

Choose the narrowest operation that satisfies the retention decision. Microsoft distinguishes removing a file from a vector store from deleting the underlying file, which removes it from all vector-store configurations in the organization. Use the broader operation only when that wider effect is intended and approved.

What should I do when last_active_at is null?

Treat null as unknown, not inactive. Check the store’s creation time, attachment, application deployment state, recent service evidence, and owner confirmation. If the evidence remains ambiguous, quarantine the decision for manual review.

How is this different from limiting RAG context or embedding dimensions?

Expiration controls how long a retained retrieval resource continues to exist. A RAG context cap limits retrieved material passed into an individual model request. Embedding dimension controls affect the size of each stored vector. These controls complement one another but address different cost drivers.

What happens if an attached conversation store expires?

Microsoft documents that response generation for that conversation fails. Recovery requires recreating a store from the files and reattaching it. Test that path before applying an aggressive policy to user-facing workloads.

What if a provider has no native inactivity policy?

Use an external scheduler to inventory and flag candidates, but preserve the same safeguards: complete coverage, a fresh state read, owner notice, an approved warning period, a restore plan, and post-change verification. Native expiry reduces manual work; it does not replace governance.

Reader next step

Start with one nonproduction project and run an inventory-only review. Export the sanitized fields above, map every store to an owner, and calculate storage exposure using the current provider terms. Select one temporary store with a recoverable source set, apply a policy-approved expiration interval, and test both expiry and restoration before expanding automation.

Record the inventory snapshot, approval, policy response, retrieval test, resulting status, and billing follow-up in one change record. The checklist in Change Control Evidence for AI API Token Budgets can be adapted for this evidence trail. Scale the process only after the first store completes both the happy path and the recovery path successfully.