Why AI Agents Should Sleep Cheap

TL;DR

• An AI agent is busy for ~1% of its life. The other 99%, it's waiting. For the user to type, for a cron to fire, for a webhook to arrive.
• Minimum commitments and provisioned capacity can add costs between agent requests. Pinecone Standard currently lists a $50/month minimum applied toward usage; its other plans have different terms.
• Separate idle compute charges from the cost of retained data. With LambdaDB, compute costs nothing between requests, while storage remains metered outside the free allowance.
• LambdaDB uses on-demand compute and object storage. An agent that never wakes up has no request-driven compute charge, but its retained data still counts toward storage.
• Code below shows the full memory loop. Copy, paste, ship.

---

The math that kills side projects

If you're building an AI agent (coding assistant, support bot, personal helper, research crawler) you've seen this thread on Reddit and Hacker News. We get it in our inbox too:

"Pinecone's new $50/mo minimum just nuked my hobby project."
"$50 to $380 to $2,847 in three months."
"Vector database costs that scale linearly with usage don't align with predictable infrastructure budgets."

I've kept those quotes on a wall since we started LambdaDB. They're real, and they're strangely polite about what's happening. Here's the less polite version.

There are two cost problems, and they hit you at different stages.

A minimum commitment matters when your workload uses less than the plan's floor. Pinecone Standard lists a $50/month minimum applied toward usage, not a separate minimum for each project or agent. Pinecone also offers other plans, including free Starter and flat-rate Builder; check the current plans rather than assuming every deployment starts at $50. One developer summed it up: "I generally managed to keep my bills under US$10. By storing only the most essential data in the Vector DB."

Then linear-scaling metering kills you at growth. Past the floor, the bill grows with usage. The customer who went $50 → $2,847 wasn't doing anything exotic. It was a RAG-based support chatbot. Read units, storage, write operations, all metered. As one HN commenter put it: "it's extremely hard to dilute pricing into a simple equation like $x/months because sometimes there are multiple variable parts."

Either failure mode wrecks the unit economics of an agent product. Same shape both times: the bill is shaped like a server, but the workload isn't.

This is what I mean when I say agents should sleep cheap. The product hasn't started yet. The user hasn't typed yet. The model hasn't been called. And your invoice is already growing. For compute that didn't run.

Why AI agents are idle 99% of the time

People model AI agents like web servers. Always on, always serving traffic. That model is wrong.

A coding agent is busy when you're paired with it. Then it sits there for 8 hours while you sleep. A support agent is busy when a ticket arrives. Then it waits for the next one. A scheduled research bot runs once a day and is dead the rest of the time.

Even being generous, the duty cycle of an individual agent looks like this:

Active:  ~1% of wall-clock time
Idle:    ~99% of wall-clock time

This isn't a bug. It's what an agent is. An AI agent is an event-driven workload pretending to be a service.

The infrastructure underneath should match that shape. If your storage layer charges per hour of "the index exists" (or imposes a monthly floor before you've sent a single request) you're paying for 99% of nothing.

What "serverless" was supposed to mean

Most vector databases sell a "serverless" tier today. Look at the bill and you'll notice they kept the server. They put a router in front of a fleet of warm pods, called it serverless, and rounded up to a minimum monthly charge so the pods would still be there when you came back.

A minimum commitment describes a billing floor; it does not establish the provider's underlying compute model. As one developer wrote in a thread about the Pinecone price hike: "True serverless architecture requires building on serverless primitives rather than just putting a serverless API on top of server clusters." Compare that architectural argument separately from the published plan terms.

For intermittent agent workloads, examine compute scaling, storage and compute separation, and billing independently. LambdaDB uses on-demand compute with no always-on compute charge between requests. Stored data remains metered outside the free allowance.

LambdaDB is built this way because it has to be. The whole engine uses per-request compute and decoupled object storage. No fleet. No warm pods. When your agent goes to sleep, the only thing still ticking is the bytes its memory occupies in storage. Measured in cents per gigabyte per month, not dollars per project per month.

That's why we can charge per query and start at $0. The architecture allows it. Server-based competitors can't follow without rewriting the product.

Inside LambdaDB in three boring boxes

Quick, because the cost story is the interesting part.

A request hits the API. A per-request worker spins up, reads the relevant shard from object storage, runs the hybrid search (vector + full-text + filter in one query), returns the result, and goes away. Cold start is sub-second for typical agent payloads. We keep enough infra primed at the platform level that user-perceived p99 latency stays in the same envelope as a "warm" managed DB for the write-then-read patterns agents run. Storage is decoupled object storage. The idle cost for an entire agent's memory (say, 50 MB of vectors and metadata) is rounding error.

What this looks like for your wallet, before any usage:

Pinecone Standard minimum usage:         $50.00 / month
LambdaDB storage, 0.05 GB at $0.33/GB-mo:  $0.0165 / month

The LambdaDB figure is an illustrative storage-only calculation using 50 MB = 0.05 GB, before free allowances, and excludes reads, writes, inference, and other metered usage. A plan minimum and a storage-only charge are different billing dimensions, so these figures are not a complete monthly cost comparison.

How LambdaDB compares for agent memory

Every "serverless" tier in the market keeps the server somewhere. Either as a warm-pod fleet behind a router, or as an always-on cluster you provision. Only serverless components takes the server away.

What about pgvector?

Most-asked counter-question on Hacker News, and the honest answer: if your dataset fits comfortably in your existing Postgres and you have one service querying it, pgvector is fine. "Show me what I can't do in pgvector" is a fair challenge, and most teams under ~1M vectors and one app shouldn't bother switching.

Where pgvector breaks down is the shape this post is about. Many small, mostly-idle, per-user namespaces. Postgres wants one HNSW index that fits in RAM. You don't get one HNSW index per user without paying for a lot of RAM. That's the workload that needs a different storage substrate, and that's the workload serverless components fits.

If you're not in that workload, stay on Postgres. I'd rather you keep your stack simple than switch for the wrong reason.

How to build agent memory: full TypeScript example

Promised you agents that sleep cheap. Here's the whole memory loop. Copy and paste.

Install:

npm install @functional-systems/lambdadb

Set up a memory collection shared across users. Filter by user_id on every query so each user only sees their own memory. And a single delete by filter call wipes a user's data when needed.

import { LambdaDBClient } from "@functional-systems/lambdadb";

const client = new LambdaDBClient({
  projectApiKey: process.env.LAMBDADB_API_KEY!,
  baseUrl: process.env.LAMBDADB_BASE_URL!,
  projectName: process.env.LAMBDADB_PROJECT!,
});

await client.createCollection({
  collectionName: "agent_memory",
  indexConfigs: {
    content:    { type: "text", analyzers: ["english"] },
    vector:     { type: "vector", dimensions: 1536, similarity: "cosine" }, // text-embedding-3-small
    user_id:    { type: "keyword" },
    role:       { type: "keyword" },     // user | assistant | system
    created_at: { type: "keyword" },
  },
});

const memory = client.collection("agent_memory");

Write a memory on every turn:

async function remember(userId: string, role: string, content: string) {
  const [vector] = await embed([content]); // your embedding call

  await memory.docs.upsert({
    docs: [{
      id: crypto.randomUUID(),
      content,
      vector,
      user_id: userId,
      role,
      created_at: new Date().toISOString(),
    }],
  });
}

Read relevant memory on the next turn. Hybrid search (vector + full-text + filter in one request) which is what you want when an agent reasons over its own past. (Pure vector search will happily return "Error 222" when you asked about "Error 221"; full-text catches the literal match.)

async function recall(userId: string, query: string, k = 8) {
  const [queryVector] = await embed([query]);

  const result = await memory.query({
    size: k,
    query: {
      rrf: [
        { queryString: { query, defaultField: "content" } },
        { knn: { field: "vector", queryVector, k } },
      ],
    },
    filter: {
      queryString: { query: `user_id:${userId} AND (role:user OR role:assistant)` },
    },
    consistentRead: true,
  });

  return result.docs.map(h => ({
    role:    h.doc.role,
    content: h.doc.content,
    score:   h.score,
  }));
}

Glue it into a turn:

async function turn(userId: string, userMessage: string) {
  const memories = await recall(userId, userMessage);

  const response = await llm.chat({
    messages: [
      { role: "system", content: buildContext(memories) },
      { role: "user",   content: userMessage },
    ],
  });

  await remember(userId, "user",      userMessage);
  await remember(userId, "assistant", response.content);

  return response.content;
}

That's the whole loop. Nothing to provision before it works. No monthly minimum sitting under it. If turn() never gets called, the only thing on your bill is the bytes the memory takes up in storage.

If users go quiet, request-driven compute charges stop. The remaining storage bill depends on the total retained data and the applicable free allowance.

What changes when idle compute costs $0

Once idle compute charges go away, you can design for intermittent use while still budgeting for retained data.

Per-user namespaces become normal. When the platform charges a $50/mo floor or per-pod overhead, you cram everyone into one index and reinvent multi-tenancy in your application code. When namespaces are free, you give every user their own. Deletes become trivial. Privacy boundaries become trivial. GDPR-style data deletion becomes one API call.

Agent fan-out becomes affordable. Spawn a research sub-agent with its own memory namespace, let it run for an hour, throw it away. Budget for its reads, writes, inference, and retained data. No fleet "we kept around just in case."

Long-tail products become viable. The hobby project that only wakes up when someone hits the URL? It costs roughly nothing when nobody uses it and pennies when someone does. The economics that nuked indie AI projects under the Pinecone floor stop applying.

And you can keep more memory. Most teams I talk to are aggressively pruning agent memory because storage and per-namespace overhead punishes them for keeping it. With S3 underneath, the calculus flips. Keep the conversation. Keep the embeddings. Keep the per-user behavior log. The next version of your model will probably want it.

When LambdaDB isn't the right fit

I try to be honest about when LambdaDB is the wrong tool, because the wrong fit hurts everyone.

A constant, high-throughput query pattern (say, 1,000 QPS 24/7) doesn't have an idle problem to solve. The pricing math becomes a normal cost-per-request comparison, and you should run it before switching. If you're already happy on pgvector at small scale, don't replace it because a blog post said so. And if you need a feature we haven't shipped, check the docs first. Native reranking is now available through the search API; see the reranking guide for supported providers and limits.

The sweet spot is exactly the shape that's been breaking the existing market: many users, each with their own memory, each idle most of the time. Agent products. Per-user RAG. Coding agents. Any workload where the bill should follow the work, not the calendar.

FAQ

What is a serverless vector database? A vector database that handles infrastructure scaling for you. Evaluate its scaling behavior, minimum commitments, storage rates, and request metering separately; a serverless label does not guarantee a zero total bill when idle.

Why are idle compute costs a problem for AI agents? Agents may wait between users, webhooks, or schedules. Measure that duty cycle for your application. A minimum commitment or provisioned capacity can add a billing floor; storage and request usage are separate costs.

Is LambdaDB a Pinecone alternative? Yes. For intermittent agent workloads, compare its hybrid retrieval, data versioning, and usage-based pricing against your requirements. LambdaDB has no minimum charge; retained storage and request usage are metered outside the free allowance.

How is zero idle compute cost possible? LambdaDB uses on-demand compute and separately metered storage. When no requests arrive, there is no always-on compute charge; retained data remains subject to storage allowances and rates.

What about cold start latency? Sub-second for typical agent payloads. Platform-level priming keeps user-perceived p99 latency in the same envelope as warm managed databases for write-then-read agent workloads.

How much does retained agent memory cost? Count the stored documents, vectors, and indexes. At $0.33/GB-month, 0.05 GB costs $0.0165/month before free allowances, excluding requests and inference. Check current pricing and limits for your workload.

Wake up cheap

If you're building agents, your infrastructure should sleep when they sleep. That sentence sounds obvious until you look at your last invoice.

With no always-on compute charge, an intermittent agent workload does not need to pay for dedicated idle capacity. Budget for stored data and request usage as the product grows.

Start at $0. No card, no minimum, no warm pod waiting: lambdadb.ai

Technical pieces referenced above: Quickstart · Collections guide · Hybrid search.