What are the rate limits for Fikra API?

Unverified accounts receive 30 Requests Per Minute (RPM). Your first wallet top-up unlocks the Trusted tier at 100 RPM.

How does Fikra API track usage limits?

Every HTTP response injects decoupled Redis tracking headers: x-ratelimit-limit-requests, x-ratelimit-remaining-requests, and x-ratelimit-reset-requests.

What are the production rate limits for Fikra API?

Fikra API enforces strict throughput boundaries at the proxy layer using a high-concurrency Redis token bucket infrastructure. These caps abstract upstream provider limits, pooling multi-engine capacity internally while shielding clients behind deterministic constraints.

Operational Account Tiers

Quotas are computed primarily on a frequency basis (Requests Per Minute) by our Redis proxy engine, completely independent of upstream hardware tracking.

Account Tier	Requests Per Minute (RPM)	Access Condition
Unverified	30 RPM	Default sandbox evaluation state. Free tier usage limits apply.
Trusted	100 RPM	Unlocked permanently following your first successful wallet top-up.
Growth	500 RPM	For production organizations with high concurrent traffic. Requires active platform fee.
Scale	2,000 RPM	High-throughput enterprise deployments. SLA included. Requires active platform fee.

Decoupled Limit Tracking

Because Fikra handles automatic fallback routing and key rotation across Groq and Alibaba instances, upstream `x-ratelimit` headers are highly volatile. Fikra completely strips these upstream headers and injects decoupled metadata based purely on your Fikra account tier via our internal Redis bucket.

Response Header Key	Returned Value Type	Metric Description
x-ratelimit-limit-requests	Integer	The hardcoded cap permitted under your assigned Fikra tier (e.g., 100 for Trusted).
x-ratelimit-remaining-requests	Integer	Remaining request count within your current 60-second sliding window.
x-ratelimit-reset-requests	Integer (Seconds)	Seconds remaining before your Redis sliding window resets completely.

Handling Rate Limits (429) & Upstream Backoffs

When request thresholds breach the assigned Fikra token bucket boundary, the system returns a standard 429 Too Many Requests. You must implement exponential backoff logic in your client.

Internal Retry Architecture

Note that temporary upstream 429s originating directly from hardware providers (like Groq) are caught and silently retried by Fikra's fallback router using backup API keys. If your application receives a 429, you have explicitly breached your Fikra-assigned Redis limits, not the upstream limit.

Python Backoff Implementation

import time
import openai

def execute_safe_call(prompt):
    for attempt in range(5):
        try:
            return client.chat.completions.create(
                model="fikra-flash",
                messages=[{"role": "user", "content": prompt}]
            )
        except openai.RateLimitError:
            # Backoff exponentially on Fikra limit exceptions
            wait_time = (2 ** attempt)
            time.sleep(wait_time)
            
    raise Exception("Inference execution abandoned after multiple timeouts.")

← Previous Topic

Model Registry

Review latency configurations and token limits across the engine matrix.

Next Topic →

Error Codes

Deconstruct server validations and identify client integration issues.