---

name: notion-cost-tuning description: >- Reduce Notion integration waste across requests, workers, storage, and downstream processing without inventing API pricing. Use when a workload is noisy, slow, or infrastructure-heavy. Trigger with "reduce Notion cost", "audit Notion request waste", or "tune Notion polling". allowed-tools: Read,Glob,Grep,Write,Edit argument-hint: " " version: 1.40.0 license: MIT author: Jeremy Longshore jeremy@intentsolutions.io tags: [saas, notion, cost] model: inherit effort: high compatibility: "Designed for Claude Code; live Notion actions require network access and explicit approval"

Notion Workload Cost and Waste Review

Overview

Reduce Notion integration waste across requests, workers, storage, and downstream processing without inventing API pricing.. This workflow produces an auditable decision or artifact before any live action.

Prerequisites

• Current first-party Notion documentation and the selected integration's tested API-version contract.
• A named workspace owner, content or data owner, and operation owner.
• Synthetic or approved non-production fixtures with secrets and workspace content removed.

Current Contract

Notion publishes operational limits, not a universal per-request price contract. Measure application infrastructure, queue, storage, observability, and downstream processor costs separately from Notion plan terms. Recheck the dated evidence map before relying on mutable fields, endpoints, versions, limits, or delivery behavior.

Authentication

Use read-only telemetry and redacted request classes. Do not expose content or tokens to cost-analysis systems.

Instructions

1. Establish the workload owner, measurement window, freshness objective, and current cost allocation.
2. Count requests by operation, outcome, tenant, retry, page, and bytes without high-cardinality content labels.
3. Identify full scans, duplicate reads, unused fields, failed retries, polling overlap, and repeated transformations.
4. Model filtered queries, cursor checkpoints, webhook signals plus reconciliation, caching, and batching.
5. Rank changes by saved work, correctness risk, implementation effort, and rollback speed.
6. Pilot one change with freshness, completeness, error, and cost guardrails.

Tool Discipline

Use Read, Glob, and Grep to inspect documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Invocation alone does not authorize network access, credentials, workspace content, user data, file transfer, deployment, capability or sharing changes, writes, spend, or deletion.

Approval Boundaries

Require data-owner approval for caching content, reducing freshness, changing retention, adding webhooks, or sharing telemetry with a vendor.

Error Handling

• Do not call an unpriced API request free.
• Do not reduce reconciliation until completeness evidence exists.
• Never cache sensitive page content merely to lower compute cost.

Output

Return the baseline, cost boundaries, waste ledger, ranked changes, expected range, pilot result, and rollback threshold. Identify assumptions, owners, expirations, and evidence gaps explicitly.

Examples

• Replace redundant full scans with cursor-based reconciliation.
• Reduce retries that repeat permanent validation failures.

Validation

Exercise and record these paths with expected and observed results:

• cost attribution
• freshness
• completeness
• cache isolation
• error rate
• rollback threshold

Resources

• Current first-party evidence map — recheck dated sources before relying on mutable behavior.
• Treat observed tenant behavior as environment-specific evidence, never a universal Notion guarantee.