सीमाएँ और खर्च

आपके अपने provider key की कोई धन सीमा नहीं होती। Managed Keys एक प्रीपेड बैलेंस खर्च करते हैं, इसलिए वे समाप्त हो सकते हैं। दो रिस्पॉन्स हेडर बताते हैं कि आपके पास क्या बचा है। GET /v1/limits एक ही कॉल में पूरी जानकारी देता है।

आपके अपने key की कोई धन सीमा नहीं होती

हम कोई रिक्वेस्ट अलाउंस और कोई मासिक कैप निर्धारित नहीं करते हैं। आपके पास खर्च करने के लिए कोई बैलेंस नहीं होता। मूल्य निर्धारण और बिलिंग देखें। एक सीमा लागू होती है। आपकी संस्था एक समय में निश्चित संख्या में flex race चलाती है। उस संख्या से अधिक होने पर हम रिक्वेस्ट को स्टैंडर्ड टियर पर चलाते हैं। आप छूट खो देते हैं, उत्तर नहीं। रिपोर्ट उस संख्या को own_keys.flex_race_slots कहती है।

Managed Keys की क्या सीमाएँ हो सकती हैं

सीमा	यह क्या गिनता है	सीमा पर
प्रीपेड बैलेंस	पहले नकद, फिर प्रोमो क्रेडिट।	`insufficient_balance`, स्टेटस `402`।
दैनिक खर्च की सीमा	आज का तय किया गया खर्च, साथ ही आज की इन-फ्लाइट रिक्वेस्ट। विंडो एक UTC दिन है।	`spend_velocity_exceeded`, स्टेटस `429`।
मैनेज्ड कॉन्करेंसी	आपकी इन-फ्लाइट मैनेज्ड रिक्वेस्ट।	`rate_limit_exceeded`, स्टेटस `429`, `Retry-After` के साथ।
शेयर्ड पूल रेट	हर मैनेज्ड संस्था द्वारा साझा किए गए पूल पर प्रति मिनट रिक्वेस्ट। आज वह Workers AI और Foundry है।	`rate_limit_exceeded`, स्टेटस `429`।

एक जोखिम समीक्षा उन चारों के अतिरिक्त मैनेज्ड रिक्वेस्ट को रोक सकती है। यह account_under_review लौटाता है। आपके अपने key route काम करते रहते हैं। चार और सीमाएँ हर संस्था को कवर करती हैं। तीन एक संस्था से, एक key से, और एक IP address से प्रति मिनट रिक्वेस्ट गिनते हैं। चौथा एक IP address से विफल प्रमाणीकरण प्रयासों को गिनता है। हम 50,000,000 बाइट्स से अधिक के body को request_too_large के रूप में भी अस्वीकार करते हैं। रिपोर्ट प्रत्येक प्रति-मिनट सीमा को उसकी विंडो और उसके scope के साथ नाम देती है। यह संख्या को छोड़ देती है, क्योंकि Cloudflare प्रत्येक को हर उस स्थान पर गिनता है जहाँ वह चलता है और एक संख्या ऐसा बजट नहीं होगी जिसके खिलाफ आप योजना बना सकें। इसके बजाय Retry-After में सेकंड के लिए पीछे हटें।

दो रिस्पॉन्स हेडर आपके खर्च की रिपोर्ट करते हैं

एक own-keys रिस्पॉन्स उन्हें तब ले जाता है जब उसके route हल हो जाते हैं, और एक मैनेज्ड रिस्पॉन्स उन्हें बैलेंस होल्ड से ले जाता है। तीन रिस्पॉन्स में कोई हेडर नहीं होता: एक जिसे हमने पहले ही अस्वीकार कर दिया था, मॉडल कैटलॉग, और एक मैनेज्ड रिक्वेस्ट जिसका बैलेंस हम पढ़ नहीं पाए। हम अनुमान लगाने के बजाय हेडर को छोड़ देते हैं।

हेडर	यह क्या कहता है
`x-flexinference-spend-remaining`	जब कोई धन सीमा लागू नहीं होती है तो `unlimited` शब्द। अन्यथा एक हस्ताक्षरित micro-USD पूर्णांक। यह आपके बैलेंस और दैनिक सीमा द्वारा अभी भी अनुमत राशि में से छोटा होता है।
`x-flexinference-spend-as-of`	जब हमने उस संख्या को पढ़ा, epoch milliseconds में। यह केवल एक संख्या के साथ आता है, क्योंकि `unlimited` को किसी ताजगी के निशान की आवश्यकता नहीं होती।

हमने इस रिक्वेस्ट को स्वीकार करते समय दोनों को पढ़ा। यह संख्या बताती है कि इस रिक्वेस्ट के अपने खर्च को तय करने से पहले आपके पास क्या बचा था। एक नकारात्मक संख्या का मतलब है कि हम हर मैनेज्ड रिक्वेस्ट को अस्वीकार कर देते हैं। पैसे जोड़ने से नकारात्मक बैलेंस ठीक हो जाता है। एक नकारात्मक दैनिक शेष अगले UTC मध्यरात्रि को या बढ़ी हुई सीमा के साथ ठीक हो जाता है, कभी भी टॉप-अप से नहीं। आप पहले से भेजे गए ट्रैफिक पर इन हेडर को पढ़ें। हर रिक्वेस्ट से पहले endpoint को पोल करने से एक राउंड ट्रिप का खर्च आता है और यह आपको हेडर से ज्यादा कुछ नहीं बताता।

limits endpoint

GET /v1/limits आपकी FlexInference key लेता है। यह उन सीमाओं की रिपोर्ट करता है जिनके तहत आपकी संस्था चलती है। यह उन रिकॉर्ड्स को पढ़ता है जो आपकी रिक्वेस्ट को स्वीकार करते हैं, इसलिए यह कभी भी ऐसी जगह का दावा नहीं करता जिसे हम अस्वीकार कर देंगे। हम उत्तर को कभी भी कैश नहीं करते हैं।

curl https://api.flexinference.com/v1/limits \
  -H "Authorization: Bearer $FLEXINFERENCE_API_KEY"

{
  "object": "limits",
  "as_of": 1769558400123,
  "own_keys": {
    "unlimited": true,
    "flex_race_slots": {
      "limit": 40,
      "scope": "organization",
      "on_exceed": "degrade_to_standard"
    }
  },
  "managed": {
    "providers": ["anthropic", "openai"],
    "serving": "ok",
    "paused_reason": null,
    "binding": "daily_spend",
    "spend_remaining_micro_usd": 41200000,
    "currency": "USD",
    "balance": {
      "remaining_micro_usd": 94880000,
      "cash_micro_usd": 84880000,
      "credit_micro_usd": 10000000,
      "reserved_micro_usd": 120000
    },
    "daily_spend": {
      "limit_micro_usd": 250000000,
      "used_micro_usd": 208800000,
      "remaining_micro_usd": 41200000,
      "window": "utc_day",
      "resets_at": 1769644800
    },
    "concurrency": {
      "limit": 10,
      "scope": "organization",
      "on_exceed": "refuse"
    },
    "ramp_week": 1,
    "ramp_defaults": {
      "concurrency": 10,
      "daily_spend_micro_usd": 250000000
    },
    "override_in_force": {
      "concurrency": false,
      "daily_spend": false
    },
    "rates": []
  },
  "abuse_limits": {
    "counted_per_cloudflare_location": true,
    "request_body_bytes": 50000000,
    "rates": [
      {
        "name": "organization_requests",
        "scope": "organization",
        "window_seconds": 60,
        "limit": null,
        "on_exceed": "refuse"
      },
      {
        "name": "api_key_requests",
        "scope": "api_key",
        "window_seconds": 60,
        "limit": null,
        "on_exceed": "refuse"
      },
      {
        "name": "client_ip_requests",
        "scope": "client_ip",
        "window_seconds": 60,
        "limit": null,
        "on_exceed": "refuse"
      },
      {
        "name": "failed_authentications",
        "scope": "client_ip",
        "window_seconds": 60,
        "limit": null,
        "on_exceed": "refuse"
      }
    ]
  }
}

हर मनी फील्ड एक micro-USD पूर्णांक है। एक USD उनमें से 1,000,000 है।

फील्ड	यह क्या कहता है
`as_of`	Epoch milliseconds। बैलेंस की अपनी घड़ी जब हमने बैलेंस पढ़ा, और हमारी जब हमने नहीं पढ़ा।
`own_keys.unlimited`	हमेशा `true`।
`own_keys.flex_race_slots`	एक समय में कितने flex race चलते हैं। संख्या पार करने पर छूट का खर्च आता है, उत्तर का नहीं।
`managed`	जब कोई provider मैनेज्ड key पर सेवा नहीं देता है तो `null`।
`managed.serving`	`ok`, या `paused` उन तीन स्थितियों में से प्रत्येक में जो हर मैनेज्ड रिक्वेस्ट को अस्वीकार कर देती हैं।
`managed.paused_reason`	कौन सी स्थिति। `account_under_review`, `spend_velocity_exceeded`, या `insufficient_balance` में से एक। जब serving `ok` पढ़ता है तो यह `null` होता है।
`managed.binding`	कौन सी सीमा पहले लागू होती है। `balance`, `daily_spend`, `paused`, या `exempt` में से एक।
`managed.spend_remaining_micro_usd`	वह संख्या जो `x-flexinference-spend-remaining` हेडर ले जाता है।
`managed.balance`	`remaining_micro_usd` नकद और क्रेडिट का योग है। यही वह मात्रा है जिसकी हम शून्य से तुलना करते हैं। `reserved_micro_usd` वह पैसा है जो आपकी इन-फ्लाइट रिक्वेस्ट रखती हैं, और हम इसे घटाते नहीं हैं।
`managed.daily_spend`	सीमा, आज क्या उपयोग किया गया है, और क्या बचा है। `resets_at` epoch seconds में अगली UTC मध्यरात्रि है।
`managed.concurrency`	आपकी संस्था एक समय में कितनी मैनेज्ड रिक्वेस्ट चलाती है।
`managed.ramp_week`	आप अकाउंट-एज शेड्यूल के किस सप्ताह में हैं। सप्ताह 0 उस अकाउंट को कवर करता है जिसने कभी टॉप-अप नहीं किया है।
`managed.ramp_defaults`	वह सप्ताह अकेले आपको क्या देता है। एक concurrency संख्या और एक दैनिक सीमा।
`managed.override_in_force`	प्रति रैम्प्ड सीमा एक फ्लैग। `true` का मतलब है कि एक एडमिन ने वह संख्या निर्धारित की है, इसलिए साप्ताहिक शेड्यूल इसे नहीं बदलेगा।
`managed.rates`	इस संस्था द्वारा सेवा दिए जाने वाले शेयर्ड पूल पर प्रति-मिनट की सीमाएँ।
`abuse_limits`	हर संस्था द्वारा साझा की जाने वाली सीमाएँ, साथ ही बाइट्स में body कैप।

अंतिम तीन फील्ड बताते हैं कि आपकी concurrency संख्या और आपकी दैनिक सीमा वैसी क्यों दिखती है। एक exempt संस्था के पास समझाने के लिए कोई सीमा नहीं होती, इसलिए तीनों null पढ़ते हैं। एक रुका हुआ बैलेंस संख्या के बजाय विराम की रिपोर्ट करता है। तब कोई भी सकारात्मक आंकड़ा भेजने की अनुमति के रूप में नहीं पढ़ा जा सकता। ये संख्याएँ as_of पर मान्य हैं और आपकी अगली रिक्वेस्ट के बारे में कुछ भी वादा नहीं करती हैं। एक और रिक्वेस्ट उन्हें बदल देती है, और ऐसा ही एक सेटलमेंट, एक टॉप-अप, या एक रिफंड भी करता है। एक गुम या गलत key invalid_api_key के साथ 401 लौटाती है। जब हम इनमें से किसी एक रिकॉर्ड को पढ़ नहीं पाते हैं, तो endpoint limits_unavailable के साथ 503 लौटाता है। यह आपको एक कैश की गई संख्या देने के बजाय अस्वीकार कर देता है, जो ऐसी जगह का दावा कर सकती है जो आपकी अगली रिक्वेस्ट को नहीं मिलेगी। रिक्वेस्ट किसी भी तरह से काम करती रहती हैं।

स्ट्रीम के अंदर लागत

एक रिस्पॉन्स जिसे आपने स्ट्रीम नहीं किया, उसकी लागत दो बार रिपोर्ट करता है, x-flexinference-cost हेडर में और usage.cost ब्लॉक में। एक स्ट्रीम किया गया रिस्पॉन्स हेडर का उपयोग नहीं कर सकता, क्योंकि हम उत्तर मौजूद होने से पहले हेडर भेजते हैं और तब हमें लागत का पता नहीं होता। लागत को स्ट्रीम के अंदर ले जाने के लिए include_cost: true भेजें।

{
  "model": "gpt-5.5",
  "start_within": "00h-00m-30s",
  "stream": true,
  "include_cost": true,
  "input": "Summarize this contract."
}

लागत फिर उस usage frame में जाती है जिसे endpoint पहले ही भेजता है। एक usage.routing ब्लॉक इसके बगल में बैठता है और उस route का नाम बताता है जिसने रिक्वेस्ट चलाई।

"usage": {
  "input_tokens": 412,
  "output_tokens": 128,
  "cost": { "total_micro_usd": 1840, "currency": "USD" },
  "routing": {
    "provider": "openai",
    "requested_provider": "openai",
    "tier": "flex",
    "reason": "flex_won",
    "fallback_attempts": 0,
    "mode": "byok"
  }
}

स्विच डिफ़ॉल्ट रूप से बंद रहता है। एक स्ट्रीम जिसके लिए आपने यह नहीं पूछा, वह provider द्वारा भेजे गए से बाइट-दर-बाइट मेल खाती है। /v1/chat/completions OpenAI पर usage frame को स्वयं opt-in बनाता है। "stream_options": {"include_usage": true} भी भेजें। इसके बिना लागत के लिए कोई frame नहीं होता। एक मैनेज्ड रिक्वेस्ट रिपोर्ट करती है कि provider ने हमसे क्या चार्ज किया। एक own-keys रिक्वेस्ट उस tier पर provider की सूची मूल्य रिपोर्ट करती है जिसने इसे चलाया। एक रिक्वेस्ट जिसकी हम कीमत नहीं लगा सकते, वह कोई cost रिपोर्ट नहीं करती। एक गुम ब्लॉक को रिपोर्ट करने के लिए कुछ भी नहीं, शून्य के रूप में नहीं पढ़ें। दो routing हेडर किसी भी तरह हर रिस्पॉन्स पर आते हैं। वे x-flexinference-served-provider और x-flexinference-routing-reason हैं। एक स्ट्रीमिंग कॉलर जो include_cost को छोड़ देता है, वह अभी भी देखता है कि किस route ने रिक्वेस्ट चलाई और क्यों। परिणाम पढ़ना देखें। include_cost कभी भी provider तक नहीं पहुँचता। हम रिक्वेस्ट को फॉरवर्ड करने से पहले इसे body से हटा देते हैं।

शुरू करें

अवधारणाएँ

API का उपयोग

Agent Keys + Integrations

सामान्य प्रश्न

सीमाएँ और खर्च

आपके अपने key की कोई धन सीमा नहीं होती

Managed Keys की क्या सीमाएँ हो सकती हैं

दो रिस्पॉन्स हेडर आपके खर्च की रिपोर्ट करते हैं

limits endpoint

स्ट्रीम के अंदर लागत

​आपके अपने key की कोई धन सीमा नहीं होती

​Managed Keys की क्या सीमाएँ हो सकती हैं

​दो रिस्पॉन्स हेडर आपके खर्च की रिपोर्ट करते हैं

​limits endpoint

​स्ट्रीम के अंदर लागत

आपके अपने key की कोई धन सीमा नहीं होती

Managed Keys की क्या सीमाएँ हो सकती हैं

दो रिस्पॉन्स हेडर आपके खर्च की रिपोर्ट करते हैं

limits endpoint

स्ट्रीम के अंदर लागत