openevidence-rate-limits
Ensures reliable performance by implementing backoff and rate limiting logic for OpenEvidence APIs.
Install
mkdir -p .claude/skills/openevidence-rate-limits && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/6335" && unzip -o skill.zip -d .claude/skills/openevidence-rate-limits && rm skill.zipInstalls to .claude/skills/openevidence-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.
Rate Limits for OpenEvidence.Key capabilities
- →Implement request queuing for clinical queries
- →Apply exponential backoff for API retries
- →Batch process research queries during off-peak hours
How it works
A token-bucket rate limiter tracks request counts per minute, while a retry function handles 429 errors using jittered backoff intervals.
Inputs & outputs
When to use openevidence-rate-limits
- →Handling rate limit errors
- →Implementing backoff strategies
- →Optimizing API throughput
- →Managing query queueing
About this skill
OpenEvidence Access and Capacity Triage
Overview
Distinguish local connectivity, account/feature access, service behavior, and clinical urgency using safe evidence. Keep inputs minimal, separate observed facts from assumptions, and leave consequential decisions with the named accountable owner.
Prerequisites
- A clearly bounded workflow, accountable clinical owner, and organizational policy
- Current first-party OpenEvidence documentation and applicable institution agreements
- Synthetic or properly authorized minimum-necessary data
Tool Discipline
Use Read, Glob, and Grep to inspect supplied policies, plans, and evidence. Use WebFetch only for current first-party OpenEvidence documentation. Use Write or Edit only when the user requests a named deliverable with an approved destination. Never expose credentials, PHI, recordings, or unrestricted environment output.
Current Contract
- No public numeric request limit or API retry contract was found for OpenEvidence.
- Browser/app symptoms must not be translated into invented HTTP limits.
- Urgent care needs must use an independent clinical fallback.
Authentication
Use only the official OpenEvidence web/mobile sign-in or an institution-approved access path. Do not invent API keys, OAuth clients, SDK credentials, service accounts, or private endpoints. Never ask a user to reveal a password, session token, cookie, or recovery code.
Instructions
- Record UTC time, surface, feature, user cohort, duration, impact, and whether patient care is time-sensitive.
- Move urgent work to the approved clinical fallback before diagnosis.
- Check local network/browser/device conditions and current first-party status/support information.
- Reproduce once with synthetic content if safe; do not hammer the service or probe private endpoints.
- Compare affected users/surfaces and capture a redacted support packet.
- Report observed capacity symptoms, not a guessed quota, with workaround, owner, and escalation state.
Approval Boundaries
Do not create or share accounts; change access, roles, agreements, consent, retention, or security settings; enter PHI; record a conversation; copy content into another system; contact a patient; make a diagnosis or treatment decision; submit billing; transmit a support packet; run a production pilot; or represent vendor capabilities without explicit approval from the accountable owner. A qualified professional remains responsible for clinical decisions.
Output
Return scope, current first-party evidence and date, data classification, workflow or findings, citations reviewed, assumptions rejected, clinical and governance owners, approval state, unresolved risk, and the exact next action. Redact patient and credential data.
Error Handling
| Condition | Response |
|---|---|
| Repeated failures | Stop retries and use the approved fallback. |
| Only one account affected | Check authorized account/feature access without credential sharing. |
| No published limit | Say unknown and ask support or the contract owner for written terms. |
Examples
This compact example shows the minimum reviewable handoff; adapt fields to the approved workflow without adding sensitive data.
Input:
symptom=slow Ask response; surface=web; duration=20m; urgency=non-urgent
Expected handoff:
scope=3 users; local-network=cleared; quota=unknown; fallback=active; support=opened
Resources
When not to use it
- →Ignoring 429 status codes in production
- →Retrying synthesis calls without jitter
Prerequisites
Limitations
- →Synthesis limit is strictly 10 requests per minute
- →Bulk evidence export limited to 5 requests per hour
How it compares
This implementation prioritizes graceful degradation in clinical workflows rather than simple retry loops.
Compared to similar skills
openevidence-rate-limits side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| openevidence-rate-limits (this skill) | 1 | 2mo | No flags | Advanced |
| java-pro | 34 | 5mo | No flags | Advanced |
| bullmq-specialist | 25 | 8mo | No flags | Intermediate |
| golang-pro | 14 | 5mo | 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
java-pro
sickn33
Master Java 21+ with modern features like virtual threads, pattern matching, and Spring Boot 3.x. Expert in the latest Java ecosystem including GraalVM, Project Loom, and cloud-native patterns. Use PROACTIVELY for Java development, microservices architecture, or performance optimization.
bullmq-specialist
davila7
BullMQ expert for Redis-backed job queues, background processing, and reliable async execution in Node.js/TypeScript applications. Use when: bullmq, bull queue, redis queue, background job, job queue.
golang-pro
sickn33
Master Go 1.21+ with modern patterns, advanced concurrency, performance optimization, and production-ready microservices. Expert in the latest Go ecosystem including generics, workspaces, and cutting-edge frameworks. Use PROACTIVELY for Go development, architecture design, or performance optimization.
go-concurrency-patterns
wshobson
Master Go concurrency with goroutines, channels, sync primitives, and context. Use when building concurrent Go applications, implementing worker pools, or debugging race conditions.
rust-async-patterns
wshobson
Master Rust async programming with Tokio, async traits, error handling, and concurrent patterns. Use when building async Rust applications, implementing concurrent systems, or debugging async code.
graphql
davila7
GraphQL gives clients exactly the data they need - no more, no less. One endpoint, typed schema, introspection. But the flexibility that makes it powerful also makes it dangerous. Without proper controls, clients can craft queries that bring down your server. This skill covers schema design, resolvers, DataLoader for N+1 prevention, federation for microservices, and client integration with Apollo/urql. Key insight: GraphQL is a contract. The schema is the API documentation. Design it carefully.