vastai-rate-limits
Handles Vast.ai API rate limits by implementing request optimization and exponential backoff.
Install
mkdir -p .claude/skills/vastai-rate-limits && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/6863" && unzip -o skill.zip -d .claude/skills/vastai-rate-limits && rm skill.zipInstalls to .claude/skills/vastai-rate-limits
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Handle Vast.ai API rate limits with backoff and request optimization.Key capabilities
- →Implement exponential backoff for HTTP 429 errors
- →Enforce minimum request delays to prevent throttling
- →Poll instance status with adaptive intervals
- →Batch GPU search queries with inter-request delays
- →Cache search results to reduce API call frequency
How it works
The client enforces a minimum delay between requests and uses an adaptive backoff loop to handle HTTP 429 status codes by waiting for the duration specified in the Retry-After header.
Inputs & outputs
When to use vastai-rate-limits
- →Handling API 429 throttling errors
- →Optimizing request throughput
- →Implementing retry logic for API calls
About this skill
Vast.ai Rate Limits
Overview
Handle Vast.ai REST API rate limits gracefully. The API at cloud.vast.ai/api/v0 returns HTTP 429 when request limits are exceeded. Most operations (search, show) are read-heavy and rarely hit limits, but automated scripts doing rapid provisioning or polling can trigger throttling.
Prerequisites
- Vast.ai CLI or REST API client
- Understanding of exponential backoff
Instructions
Step 1: Rate-Limited HTTP Client
import requests
import time
class RateLimitedVastClient:
BASE_URL = "https://cloud.vast.ai/api/v0"
def __init__(self, api_key, min_delay=0.5, max_retries=5):
self.session = requests.Session()
self.session.headers["Authorization"] = f"Bearer {api_key}"
self.min_delay = min_delay
self.max_retries = max_retries
self.last_request = 0
def request(self, method, endpoint, **kwargs):
# Enforce minimum delay between requests
elapsed = time.time() - self.last_request
if elapsed < self.min_delay:
time.sleep(self.min_delay - elapsed)
for attempt in range(self.max_retries):
self.last_request = time.time()
resp = self.session.request(method, f"{self.BASE_URL}{endpoint}", **kwargs)
if resp.status_code == 429:
retry_after = int(resp.headers.get("Retry-After", 2 ** attempt))
print(f"Rate limited. Waiting {retry_after}s (attempt {attempt+1})")
time.sleep(retry_after)
continue
resp.raise_for_status()
return resp.json()
raise RuntimeError("Max retries exceeded due to rate limiting")
Step 2: Polling with Adaptive Backoff
def poll_instance_status(client, instance_id, target="running", timeout=300):
"""Poll instance status with increasing intervals."""
start = time.time()
interval = 5 # Start at 5s, increase to max 30s
while time.time() - start < timeout:
info = client.request("GET", f"/instances/{instance_id}/")
status = info.get("actual_status", "unknown")
if status == target:
return info
if status in ("error", "offline"):
raise RuntimeError(f"Instance {instance_id} failed: {status}")
time.sleep(interval)
interval = min(interval * 1.5, 30)
raise TimeoutError(f"Instance did not reach '{target}' within {timeout}s")
Step 3: Batch Search with Throttling
def batch_search(client, gpu_configs):
"""Search for multiple GPU types with rate-limit-safe delays."""
results = {}
for config in gpu_configs:
query = GPUQuery(**config).to_filter()
offers = client.request("GET", "/bundles/", params={"q": str(query)})
results[config.get("gpu_name", "any")] = offers.get("offers", [])
time.sleep(1) # Be polite between searches
return results
# Usage
configs = [
{"gpu_name": "RTX_4090", "max_dph": 0.30},
{"gpu_name": "A100", "max_dph": 2.00},
{"gpu_name": "H100_SXM", "max_dph": 4.00},
]
all_offers = batch_search(client, configs)
Step 4: Request Optimization
Strategies to reduce API calls:
- Cache search results: Offers change slowly; cache for 60-120 seconds
- Use
--limit: Restrict search results to what you need - Batch instance checks: Use
show instances(lists all) instead of individualshow instance IDcalls - Avoid polling loops: Use longer intervals (15-30s) for status checks
Output
- Rate-limited HTTP client with automatic retry on 429
- Adaptive polling for instance status changes
- Batch search with inter-request delays
- Request optimization strategies
Error Handling
| Scenario | Response |
|---|---|
| First 429 | Wait Retry-After header value, then retry |
| Repeated 429s | Double wait time between retries |
| 429 during provisioning | Instance creation is idempotent; safe to retry |
| 429 during search | Cache previous results and use them temporarily |
Resources
Next Steps
For security best practices, see vastai-security-basics.
Examples
Safe multi-instance provisioning: Create 10 instances with 2-second delays between each create instance call to avoid triggering rate limits during cluster setup.
Efficient monitoring: Poll all instances with a single show instances call every 30 seconds instead of individual calls per instance.
When not to use it
- →When performing non-API operations
- →When the API is not returning 429 status codes
Prerequisites
Limitations
- →Max retries are limited to 5 attempts
- →Polling intervals are capped at 30 seconds
How it compares
Unlike a standard HTTP client, this implementation includes built-in retry logic and request throttling specifically tuned for the Vast.ai REST API.
Compared to similar skills
vastai-rate-limits side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| vastai-rate-limits (this skill) | 1 | 25d | No flags | Intermediate |
| telegram-bot-builder | 106 | 6mo | Review | Intermediate |
| mcp-integration | 21 | 8mo | Review | Intermediate |
| n8n-workflow-patterns | 16 | 2mo | No flags | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
telegram-bot-builder
davila7
Expert in building Telegram bots that solve real problems - from simple automation to complex AI-powered bots. Covers bot architecture, the Telegram Bot API, user experience, monetization strategies, and scaling bots to thousands of users. Use when: telegram bot, bot api, telegram automation, chat bot telegram, tg bot.
mcp-integration
anthropics
This skill should be used when the user asks to "add MCP server", "integrate MCP", "configure MCP in plugin", "use .mcp.json", "set up Model Context Protocol", "connect external service", mentions "${CLAUDE_PLUGIN_ROOT} with MCP", or discusses MCP server types (SSE, stdio, HTTP, WebSocket). Provides comprehensive guidance for integrating Model Context Protocol servers into Claude Code plugins for external tool and service integration.
n8n-workflow-patterns
czlonkowski
Proven workflow architectural patterns from real n8n workflows. Use when building new workflows, designing workflow structure, choosing workflow patterns, planning workflow architecture, or asking about webhook processing, HTTP API integration, database operations, AI agent workflows, or scheduled tasks.
n8n-code-javascript
czlonkowski
Write JavaScript code in n8n Code nodes. Use when writing JavaScript in n8n, using $input/$json/$node syntax, making HTTP requests with $helpers, working with dates using DateTime, troubleshooting Code node errors, or choosing between Code node modes.
n8n-expression-syntax
czlonkowski
Validate n8n expression syntax and fix common errors. Use when writing n8n expressions, using {{}} syntax, accessing $json/$node variables, troubleshooting expression errors, or working with webhook data in workflows.
n8n-node-configuration
czlonkowski
Operation-aware node configuration guidance. Use when configuring nodes, understanding property dependencies, determining required fields, choosing between get_node_essentials and get_node_info, or learning common configuration patterns by node type.