attio-cost-tuning
Analyze and reduce avoidable Attio integration cost and load by measuring request volume, query complexity, synchronization churn, and retained data before changing architecture. Use when an Attio workload is wasteful or operationally expensive. Trigger with "Attio cost", "reduce Attio API usage", or "Attio sync efficiency".
Allowed Tools
Provided by Plugin
attio-pack
Attio CRM integration pack with 18 operator skills
Installation
This skill is included in the attio-pack plugin:
/plugin install attio-pack@claude-code-plugins-plus
Click to copy
Instructions
Attio Workload Cost Review
Overview
This skill optimizes application-controlled workload rather than guessing at plan prices. It converts observed traffic and synchronization behavior into a ranked change proposal.
Prerequisites
- A representative measurement window and environment
- Request counts grouped by endpoint, method, status, and caller
- Query shapes, pagination behavior, and retry counts
- Current account terms for any commercial decision
Tool Discipline
Use Read, Glob, and Grep to locate polling loops, duplicate writes, query construction, caches, and telemetry. Use WebFetch only for current official Attio documentation. Use Write or Edit after a measured baseline and rollback plan exist.
Current Contract
- Do not encode fixed prices, entitlements, or savings claims in code or durable guidance.
- Read and write requests have different published rate-limit tiers; record and entry queries can also incur score-based limits.
- A lower request count is not automatically better if it increases query complexity or stale-data risk.
- Webhooks can replace some polling, but delivery is at least once and requires deduplication.
Authentication
Use the existing least-privilege Bearer credential for observation. Cost analysis never requires broader scopes than the workload already uses.
Instructions
- Establish request volume, retry amplification, polling frequency, and duplicate-write baseline.
- Identify calls that fetch unused fields, repeat stable discovery, or write unchanged values.
- Separate offset/cursor traversal costs by endpoint and inspect expensive record or entry filters.
- Model candidate changes: cached schema discovery, change detection, bounded concurrency, webhook-assisted sync, or shorter retention.
- Quantify impact with ranges and state freshness, reliability, and complexity tradeoffs.
- Implement one reversible change and compare it with the same measurement window.
Approval Boundaries
Do not change commercial plans, delete retained data, reduce audit history, or replace polling with webhooks without owner review of reliability and recovery behavior.
Output
Return baseline metrics, top cost or load drivers, ranked proposals, assumptions, selected change, rollback trigger, and post-change comparison.
Error Handling
| Condition | Response |
|---|---|
| No reliable telemetry | Instrument first; label estimates as unverified. |
| Provider pricing is needed | Consult the current account and official commercial source. |
| Optimization increases 429s | Reduce concurrency or query complexity and roll back. |
| Fewer calls create stale data | Restore the prior freshness boundary. |
Examples
Input:
window=seven representative days; symptom=repeated object-schema reads
Expected handoff:
baseline=measured; change=bounded schema cache; freshness=preserved; rollback=defined