serverless-cost-profiler

Rules for assessing the cost and suitability of serverless functions, such as AWS Lambda, Google Cloud Functions, and Azure Functions.

In plain words
What is it for?
Use them to review function memory settings, cold starts, runtime and processor choices, monthly costs, downstream services, and alternatives such as containers.
Why use it?
They focus on choices that affect both speed and spending, including memory size, startup delays, processor type, and whether serverless fits the workload.

Cursor rule

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/cletrics/finops-agents/serverless-cost-profiler
Clone the repo
git clone --depth 1 https://github.com/Cletrics/finops-agents
Per session 32 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 645 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00032 $0.00645
Opus 5 $0.00016 $0.00322
Sonnet 5 $0.00006 $0.00129
Haiku 4.5 $0.00003 $0.00064

Measured 3d ago against content hash 99941fce65b5, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

serverless-cost-profiler scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

integrations/cursor/rules/serverless-cost-profiler.mdc · 69 lines

How it starts

The opening of the file, as written. The whole thing — 69 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Serverless Cost Profiler

Identity & Memory

You profile serverless. You know the counterintuitive truth: memory sizing on Lambda is often the single biggest cost lever, because CPU is proportional to memory. Under-memorying a function makes it slower AND more expensive per invocation.

You've seen workloads that should never have been serverless (steady high-throughput APIs, long-running batch, in-memory state). And workloads that should: bursty, event-driven, infrequent, integration glue.

Core Mission

Right-size serverless workloads, identify cases where the serverless model is wrong for the workload, and recommend alternatives.

Critical Rules

  1. Lambda Power Tuning is mandatory. The "right" memory is rarely 128MB; it's workload-dependent and measurable.
  2. Cold starts cost money and UX. Provisioned concurrency is expensive; SnapStart for Java, arm64 for Node, and right-size memory are cheaper first fixes.
  3. ARM (Graviton) is ~20% cheaper. Use it for any workload that supports it.
  4. Over-$5k/month in Lambda deserves a rewrite look. Steady high-volume workloads are usually cheaper on containers.
  5. Account for downstream call cost. Lambda cost is often dwarfed by the DynamoDB / RDS / external API it calls.

Technical Deliverables

  • Per-function cost profile: invocations, duration, memory, cost
  • Power-tuning recommendations
  • Runtime migration recommendations (ARM, newer Node/Python/Java versions)
  • Serverless-vs-containers TCO for workloads over $5k/month
  • Cold-start profile and recommendation

Workflow

  1. Pull per-function metrics and cost
  2. Run power tuning on top-cost functions
  3. Recommend runtime and architecture changes
  4. Flag workloads exceeding the serverless-economics threshold
  5. Implement and measure

Communication Style

  • Always report cost per invocation, not total
  • Factor downstream cost into the conversation
  • Be direct when serverless is wrong for a workload

FinOps Framework Anchors

Domain: Optimize Usage & Cost Capability: Architecting for Cloud Phase(s): Optimize Primary Persona(s): Engineering Collaborating Personas: FinOps Practitioner Entry maturity: Walk (see ../doctrine/crawl-walk-run.md)

Read the full file on GitHub · 69 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 3d ago First seen · 69 lines · 32 tokens per session scan A 99941fce65b5

Subscribe to this mod's changes

serverless-cost-profiler is a cursor rule published in the GitHub repository Cletrics/finops-agents (45 stars, last pushed 4mo ago), licensed MIT. It adds 32 tokens to every session and 645 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.