Skip to content
ProductArena

Model Gateways & Routers Arena

Portkey vs Requesty

Portkey logo

Portkey

Portkey, Inc.

Arena20/100AGENT-READY36/100BUILT-IN AI0/100
MCP~CLI~API✓
free-tier6/100 integrity
Requesty logo

Requesty

Requesty

Arena18/100AGENT-READY45/100BUILT-IN AI0/100
MCP✓CLI—API✓
free-tier0/100 integrity

Portkey wins · 19–9 (16 drawn)

Agenticness — how well agents can access and operate the productAgenticness

How well agents can access and operate the product

Agent access

  1. ai-native userPoint an agent at llms.txt or agent-oriented docs

    weight 2 · round drawn
    Portkeyfullprobed8/10

    Portkey hosts a working llms.txt file (HTTP 200) with a description of the product, confirming agents can be pointed at it for agent-oriented docs. Missing for 10: no docs.md fallback (404) or OpenAPI spec confirmation, and no independent/community corroboration of agents actually using it.

    • [probe] “PROBE llms.txt: HTTP 200 at https://portkey.ai/llms.txt # Portkey > Portkey is a production stack for Gen AI builders, equipping AI teams w…”
    • [probe] “PROBE docs-md: HTTP 404 at https://portkey.ai/docs.md”
    proof ↗⚑ flag
    Requestyfullprobed8/10

    Requesty's docs site serves a working llms.txt (HTTP 200) with a structured index, plus .md variants of docs pages that explicitly point agents to llms.txt for the full documentation index, directly enabling an agent to be pointed at agent-oriented docs. missing for 10: no independent/third-party confirmation of agents actually consuming this successfully, and no dedicated docs page describing the llms.txt feature itself.

    • [probe] “PROBE llms.txt: HTTP 200 at https://docs.requesty.ai/llms.txt # Requesty > Requesty is a unified LLM gateway and OpenAI-compatible API for …”
    • [probe] “PROBE docs-md: HTTP 200 at https://docs.requesty.ai/quickstart.md > ## Documentation Index > Fetch the complete documentation index at: http…”
    proof ↗⚑ flag

  2. ai-native userRun the product headlessly / in CI for automation

    weight 2 · round to Requesty
    Portkeypartialclaimed5/10

    Portkey's gateway can be run headlessly via a CLI command (npx @portkey-ai/gateway) and REST API with a base URL, and it is open source and self-hostable, which supports CI/automation usage. However, there is no explicit documentation of CI pipeline integration, GitHub Actions examples, or headless automation testing workflows. missing for 10: explicit CI/CD examples, headless automation guides, non-interactive scripted usage documentation, independent verification of CI usage.

    • [claimed-docs] “npx @portkey-ai/gateway”
    • [claimed-docs] “We've open sourced our battle-tested AI gateway to the community. You can run it locally with a single command:”
    • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey’s features into your existing setup.”
    • [claimed-docs] “The base URL for all REST API requests is `https://api.portkey.ai/v1`”
    proof ↗⚑ flag
    Requestypartialclaimed6/10

    Requesty is an OpenAI-compatible API gateway accessed via simple base_url swap, meaning any script or CI pipeline using the OpenAI SDK can call it headlessly without a UI, and BYOK/API-key auth supports non-interactive use. However, there is no explicit documentation or example showing CI/automation setup (e.g., GitHub Actions, headless auth flow, or CLI for pipelines). Missing for 10: explicit CI/automation docs or examples, headless auth/token provisioning guidance, independent confirmation of CI usage.

    • [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
    • [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
    • [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
    proof ↗⚑ flag

  3. ai-native userPlug MCP servers into this product so it can use their tools

    weight 3 · round to Requesty
    Portkeypartialclaimed6/10

    Portkey's docs explicitly state it can 'Connect to Remote MCP servers, allowing you to connect external tools and data sources' via the AI Gateway, directly supporting the story. However, evidence lacks detail on setup steps, supported MCP transport, or independent/hands-on confirmation of this working in practice. Missing for 10: detailed configuration docs for adding MCP servers, independent verification of MCP tool invocation, and examples of tool-calling via MCP in a live agent workflow.

    • [claimed-docs] “Connect to Remote MCP severs, allowing you to connect external tools and data sources.”
    proof ↗⚑ flag
    Requestyfullclaimed7/10

    Requesty's MCP Gateway explicitly lets AI coding assistants (Claude Code, Cursor, Roo Code) connect to MCP servers through Requesty's unified API, directly matching the story. missing for 10: deeper documentation on configuring specific MCP servers and independent/hands-on corroboration of the gateway working in practice.

    • [claimed-docs] “The MCP (Model Context Protocol) Gateway enables AI coding assistants like Claude Code, Cursor, and Roo Code to securely connect to MCP serv…”
    proof ↗⚑ flag

  4. ai-native userConnect an agent via an official MCP server

    weight 3 · round to Requesty
    Portkeynone0/10

    Portkey's docs describe connecting *to* remote MCP servers as a client-side feature (portkey-docs-17), but there is no evidence that Portkey itself exposes an official MCP server endpoint that external agents can connect to. Missing for 10: any documentation of Portkey hosting/serving an MCP endpoint, MCP server setup instructions, or third-party confirmation of agents connecting via Portkey's MCP server.

    • [claimed-docs] “Connect to Remote MCP severs, allowing you to connect external tools and data sources.”
    proof ↗⚑ flag
    Requestyfullclaimed7/10

    Requesty is a gateway/router (not itself an agent), and it documents an official 'MCP Gateway' that lets AI coding assistants like Claude Code, Cursor, and Roo Code securely connect to MCP servers through Requesty's unified API, directly matching the story. Missing for 10: independent/hands-on corroboration beyond first-party docs and more detail on setup/config specifics.

    • [claimed-docs] “The MCP (Model Context Protocol) Gateway enables AI coding assistants like Claude Code, Cursor, and Roo Code to securely connect to MCP serv…”
    • [claimed-docs] “Using the Requesty integration, you can: Use 300+ models while coding, giving you flexibility to choose the best model for each task.”
    proof ↗⚑ flag

  5. ai-native userUse an official CLI

    weight 2 · round to Portkey
    Portkeypartialclaimed3/10

    The only CLI-like evidence is running the open-source gateway locally via `npx @portkey-ai/gateway`, which self-hosts the gateway rather than offering a full-featured CLI for managing configs, logs, or other Portkey resources. Missing for 10: a documented dedicated CLI tool/command set, CLI-based workflow examples, and independent corroboration of CLI usage.

    • [claimed-docs] “npx @portkey-ai/gateway”
    • [claimed-docs] “We've open sourced our battle-tested AI gateway to the community. You can run it locally with a single command:”
    proof ↗⚑ flag
    Requestynone0/10

    Requesty is presented as a unified LLM gateway/router with SDK compatibility and integrations (Claude Code, Cursor, etc.), but no evidence mentions an official Requesty CLI tool. Evidence only covers API routing, policies, MCP gateway, and dashboard features—no CLI is documented or probed.

      ⚑ flag

    • ai-native userDrive the product through a documented public API

      weight 3 · round drawn
      Portkeyfullprobed8/10

      Portkey exposes a documented REST API (base URL https://api.portkey.ai/v1) with API-reference docs for its inference API, OpenAI-compatible integration, and llms.txt discovery confirms API-first positioning; gateway is also open-sourced and npx-runnable. Missing for 10: a discoverable OpenAPI/swagger spec (probe found all candidate paths 404) and independent/third-party corroboration of API usage.

      • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey’s features into your existing setup.”
      • [claimed-docs] “The base URL for all REST API requests is `https://api.portkey.ai/v1`”
      • [claimed-docs] “Ideal for: if you’re currently utilizing OpenAI’s Python or Node.js SDKs. By changing the base URL and adding Portkey-specific headers, you …”
      • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey's features into your existing setup.”
      • [probe] “PROBE llms.txt: HTTP 200 at https://portkey.ai/llms.txt # Portkey > Portkey is a production stack for Gen AI builders, equipping AI teams w…”
      • [probe] “PROBE openapi: all candidate paths 404 (https://portkey.ai/openapi.json, https://portkey.ai/swagger.json, https://portkey.ai/api/openapi.jso…”
      • [claimed-docs] “We've open sourced our battle-tested AI gateway to the community. You can run it locally with a single command:”
      proof ↗⚑ flag
      Requestyfullprobed8/10

      Requesty exposes a documented, OpenAI-compatible public API (base_url swap, quickstart docs) plus a rich set of documented API-level features (fallback policies, load balancing, caching, structured outputs, BYOK) that let an AI-native user drive the product programmatically. missing for 10: an actual OpenAPI/swagger spec (probe found all candidate spec paths 404) and independent third-party corroboration of API robustness.

      • [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
      • [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
      • [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
      • [claimed-docs] “Load Balancing Policies distribute your requests across multiple models based on weights you define. Perfect for A/B testing, gradual rollou…”
      • [claimed-docs] “Requesty makes every supported model speak structured JSON — from simple json_object mode to strict, schema-enforced json_schema mode.”
      • [probe] “PROBE llms.txt: HTTP 200 at https://docs.requesty.ai/llms.txt # Requesty > Requesty is a unified LLM gateway and OpenAI-compatible API for …”
      • [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
      proof ↗⚑ flag

    • ai-native userIssue scoped/least-privilege API credentials for an agent

      weight 2 · round to Portkey
      Portkeypartialclaimed7/10

      Portkey lets admins issue API keys scoped with budgets, rate limits, and model allow-lists at org/workspace level, and virtual keys keep provider credentials out of code — this maps well to least-privilege credential issuance. However, the docs frame this around human/org governance rather than explicitly per-agent scoped credentials, and there's no independent corroboration of enforcement in practice. Missing for 10: explicit agent-specific credential scoping workflow, independent/hands-on validation of enforcement.

      • [claimed-docs] “Configure budget and rate limits on API keys to effectively manage AI spending and usage across your organization”
      • [claimed-docs] “Budget limits allow you to set maximum LLM spending or token usage thresholds on your API keys, automatically preventing further usage when …”
      • [claimed-docs] “Fine-grained control: budgets, rate limits, and model allow-lists at both org and workspace level.”
      • [claimed-docs] “Set hourly, daily, or per minute rate limits on requests or tokens sent”
      • [claimed-docs] “Provider credentials stored securely, never exposed in code”
      proof ↗⚑ flag
      Requestynone0/10

      Requesty's docs mention BYOK (bringing your own provider keys), analytics, and 'centralized governance,' but there is no evidence of issuing scoped or least-privilege Requesty API keys/credentials specifically for individual agents. No mention of key scoping, permission levels, or per-agent credential issuance appears anywhere in the evidence pack.

      • [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
      • [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
      proof ↗⚑ flag

    • ai-native userBuild against official SDKs

      weight 2 · round to Portkey
      Portkeypartialprobed6/10

      Portkey documents SDK-style integration (base URL swap for OpenAI Python/Node SDKs, REST API reference, open-source gateway installable via npx) supporting AI-native builders, but the evidence pack lacks explicit mention of dedicated first-party SDKs beyond OpenAI-compatible drop-in usage, and OpenAPI spec probes returned 404s. missing for 10: dedicated official multi-language SDK docs (e.g., Python/JS Portkey SDK reference pages), working OpenAPI/spec discovery, independent developer corroboration of SDK usage.

      • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey’s features into your existing setup.”
      • [claimed-docs] “The base URL for all REST API requests is `https://api.portkey.ai/v1`”
      • [claimed-docs] “Ideal for: if you’re currently utilizing OpenAI’s Python or Node.js SDKs. By changing the base URL and adding Portkey-specific headers, you …”
      • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey's features into your existing setup.”
      • [claimed-docs] “We've open sourced our battle-tested AI gateway to the community. You can run it locally with a single command:”
      • [probe] “PROBE openapi: all candidate paths 404 (https://portkey.ai/openapi.json, https://portkey.ai/swagger.json, https://portkey.ai/api/openapi.jso…”
      proof ↗⚑ flag
      Requestypartialprobed5/10

      Requesty documents OpenAI-SDK compatibility (point the OpenAI SDK's base_url at Requesty) so developers can build using the OpenAI SDK's standard interfaces, but there is no evidence of a dedicated first-party Requesty SDK package (e.g., a requesty-python or requesty-node client) or SDKs for other languages beyond OpenAI-compatible clients. missing for 10: dedicated official Requesty-branded SDKs, multi-language SDK coverage, and independent confirmation of SDK maintenance/versioning.

      • [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
      • [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
      • [probe] “PROBE llms.txt: HTTP 200 at https://docs.requesty.ai/llms.txt # Requesty > Requesty is a unified LLM gateway and OpenAI-compatible API for …”
      proof ↗⚑ flag

    • ai-native userSubscribe to events via webhooks

      weight 2 · round drawn
      Portkeynone0/10

      No evidence in the pack mentions webhooks or event subscriptions of any kind; Portkey's docs cover gateway routing, caching, retries, budgets, and logs but nothing about outbound webhook notifications for events.

        ⚑ flag
        Requestynone0/10

        No evidence anywhere in the pack of webhook subscription support for events (e.g., request completion, budget alerts, usage thresholds); the docs cover routing, fallback, caching, analytics, MCP gateway, etc., but no webhook/event-subscription feature is mentioned.

          ⚑ flag

        Agentic features

        1. ai-native userGet AI-generated insights and suggestions from my data inside the product

          weight 2 · round drawn
          Portkeynone0/10

          Portkey's evidence pack covers gateway routing, fallbacks, caching, logging, and budget controls, but there is no mention of AI-generated insights, summaries, or suggestions derived from a user's data within the product itself — logs support manual feedback tagging (portkey-docs-34), not AI-driven analysis. missing for 10: any AI-generated insight/summary feature, anomaly detection or recommendation engine over logs/usage data, in-product AI assistant surfacing suggestions.

          • [claimed-docs] “The Logs section presents a chronological list of all the requests processed through Portkey.”
          • [claimed-docs] “you can also add manual feedback on the logs to be analysed and filtered later”
          • [claimed-docs] “Configure budget and rate limits on API keys to effectively manage AI spending and usage across your organization”
          proof ↗⚑ flag
          Requestynone0/10

          Requesty's docs describe a real-time analytics dashboard for usage/cost/latency tracking, but nowhere is there evidence of AI-generated insights, recommendations, or suggestions derived from that data — the dashboard is purely observational reporting.

          • [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
          proof ↗⚑ flag

        Api quality

        1. ai-native userExplore an interactive API reference with runnable examples

          weight 2 · round to Portkey
          Portkeypartialprobed4/10

          Portkey documents a REST API reference (base URL, headers, SDK compatibility) at /docs/api-reference, but the evidence pack contains no mention of an interactive explorer or runnable code examples, and probes for a discoverable OpenAPI/Swagger spec all returned 404s. Missing for 10: evidence of an interactive 'try it' console, runnable code snippets, and a published OpenAPI/Swagger schema.

          • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey’s features into your existing setup.”
          • [claimed-docs] “The base URL for all REST API requests is `https://api.portkey.ai/v1`”
          • [claimed-docs] “Ideal for: if you’re currently utilizing OpenAI’s Python or Node.js SDKs. By changing the base URL and adding Portkey-specific headers, you …”
          • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey's features into your existing setup.”
          • [probe] “PROBE openapi: all candidate paths 404 (https://portkey.ai/openapi.json, https://portkey.ai/swagger.json, https://portkey.ai/api/openapi.jso…”
          proof ↗⚑ flag
          Requestynone0/10

          The evidence pack shows only markdown-based quickstart docs and code snippets; explicit probes for an OpenAPI/swagger spec all returned 404, and there is no mention of an interactive, runnable API reference or playground.

          • [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
          • [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
          • [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
          proof ↗⚑ flag

        2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

          weight 2 · round drawn
          Portkeynone0/10

          Portkey has an API reference (base URL, inference API docs) but no evidence of a downloadable OpenAPI/Swagger spec; a direct probe for common OpenAPI paths returned 404s, and docs.md also 404s.

          • [probe] “PROBE openapi: all candidate paths 404 (https://portkey.ai/openapi.json, https://portkey.ai/swagger.json, https://portkey.ai/api/openapi.jso…”
          • [probe] “PROBE docs-md: HTTP 404 at https://portkey.ai/docs.md”
          • [claimed-docs] “The base URL for all REST API requests is `https://api.portkey.ai/v1`”
          proof ↗⚑ flag
          Requestynone0/10

          Requesty is an API/gateway product where a downloadable OpenAPI spec would be a natural and expected artifact, so the axis applies, but a direct probe found all candidate OpenAPI/swagger paths returning 404 and no docs page references a spec file. No first-party mention of an OpenAPI spec exists anywhere in the docs pack.

          • [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
          proof ↗⚑ flag

        3. ai-native userRely on versioned APIs with a documented deprecation policy

          weight 2 · round drawn
          Portkeynone0/10

          No evidence of API versioning scheme (e.g., v1/v2 in URLs beyond a single 'v1' base path) or any documented deprecation policy/changelog; OpenAPI spec probe also returned 404s. Missing for 10: versioning scheme documentation, explicit deprecation policy, changelog/migration guides, and any independent corroboration.

          • [claimed-docs] “The base URL for all REST API requests is `https://api.portkey.ai/v1`”
          • [probe] “PROBE openapi: all candidate paths 404 (https://portkey.ai/openapi.json, https://portkey.ai/swagger.json, https://portkey.ai/api/openapi.jso…”
          proof ↗⚑ flag
          Requestynone0/10

          No evidence of API versioning scheme or a documented deprecation policy; OpenAPI spec probes all returned 404, and none of the docs mention version numbers, changelogs, or deprecation timelines.

          • [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
          proof ↗⚑ flag

        Automation depth — how much of the product can run unattendedAutomation depth

        How much of the product can run unattended

        1. ai-native userPerform bulk operations across many items at once

          weight 2 · round drawn
          Portkeynone0/10

          Portkey's evidence covers gateway routing, fallbacks, caching, logging, and budget/rate-limit controls, but nothing describes a bulk/batch operation capability (e.g., batch inference calls, bulk editing of configs/keys, or bulk log actions) that lets a user act on many items at once. Missing for 10: any documentation of a batch API, bulk config/key management, or bulk log/annotation actions.

            ⚑ flag
            Requestynone0/10

            Requesty's docs cover routing, fallback, load balancing, caching, and analytics for individual requests, but there is no evidence of a batch/bulk API or mechanism for processing many items in a single operation.

              ⚑ flag

            • ai-native userDefine rules that trigger actions automatically on events

              weight 3 · round drawn
              Portkeypartialclaimed6/10

              Portkey ships several built-in rule/event mechanisms — fallback triggers on non-2xx status codes, automatic retries with backoff, circuit-breaker/failure handling per strategy, and budget/rate-limit thresholds that automatically send notifications or block further usage — which are automatic actions triggered by defined conditions. However, these are fixed, product-defined automations (reliability/spend rules) rather than a general user-authorable rule engine where an AI-native user can define arbitrary custom triggers/actions. Missing for 10: general-purpose custom rule/trigger builder, arbitrary event types beyond status codes/spend thresholds, user-defined action targets (e.g. webhooks, custom scripts) beyond built-in notifications/fallback/retry.

              • [claimed-docs] “Specify a prioritized list of providers/models. If the primary LLM fails, Portkey automatically falls back to the next in line.”
              • [claimed-docs] “By default, fallback triggers on any **non-2xx** status code. Customize with `on_status_codes`”
              • [claimed-docs] “Automatically retry failed LLM requests with exponential backoff.”
              • [claimed-docs] “Configure per-strategy circuit protection and failure handling”
              • [claimed-docs] “When usage reaches this threshold, notifications will be sent to configured recipients”
              • [claimed-docs] “Budget limits allow you to set maximum LLM spending or token usage thresholds on your API keys, automatically preventing further usage when …”
              • [claimed-docs] “Set hourly, daily, or per minute rate limits on requests or tokens sent”
              proof ↗⚑ flag
              Requestypartialclaimed6/10

              Requesty provides several automatic policy mechanisms that act as event-triggered rules: Fallback Policies automatically retry with different models on failure events, Load Balancing Policies route by defined weights, and Guardrails automatically scan/act on content before reaching a provider. These are rule-based automations tied to conditions/events, but they are fixed policy types rather than a general-purpose custom event/action rule engine that an AI-native user could freely define. Missing for 10: a general rules/automation builder allowing arbitrary custom triggers and actions beyond the predefined fallback/load-balancing/guardrail policy types, and independent evidence of this automation working in production.

              • [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
              • [claimed-docs] “Your request goes to the primary model first. If it fails (timeout, rate limit, error, etc.), the router immediately tries the next model in…”
              • [claimed-docs] “Load Balancing Policies distribute your requests across multiple models based on weights you define. Perfect for A/B testing, gradual rollou…”
              • [claimed-docs] “Guardrails scan AI request content for sensitive information before it reaches a model provider.”
              proof ↗⚑ flag

            Caching performance — stories about caching performance in this arenaCaching performance

            Stories about caching performance in this arena

            Caching

            1. developerCache responses at the gateway to cut cost and latency on repeated requests

              weight 2 · round to Portkey
              Portkeyfullclaimed9/10

              Portkey's docs explicitly describe gateway-level caching (simple and semantic) that serves responses up to 20x faster and cheaper, including semantic matching via cosine similarity for near-duplicate queries. This directly matches the story's cost/latency reduction on repeated requests. missing for 10: independent/hands-on benchmark corroboration beyond vendor docs.

              • [claimed-docs] “Cache LLM responses to serve requests up to **20x faster** and cheaper.”
              • [claimed-docs] “Matches requests with **similar meaning** using cosine similarity, not just identical text.”
              proof ↗⚑ flag
              Requestyfullclaimed8/10

              Requesty documents automatic gateway-level caching of long system prompts and repeated content to reduce costs, with usage analytics tracking cache savings and latency in real-time, directly matching the story's intent. missing for 10: independent/hands-on benchmarks confirming actual latency/cost reduction, and detail on cache TTL/configurability.

              • [claimed-docs] “Requesty's auto caching automatically caches long system prompts and repeated content to reduce costs on any provider that supports prompt c…”
              • [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
              proof ↗⚑ flag

            Latency

            1. platform engineerRun traffic through gateway infrastructure that adds minimal latency overhead to provider calls

              weight 2 · round to Requesty
              Portkeypartialclaimed4/10

              Portkey's docs claim caching can serve responses '20x faster' and market the gateway as 'performant,' but there is no direct benchmark or first-party claim quantifying the gateway's own added latency overhead per provider call, nor independent corroboration of low overhead. Missing for 10: explicit latency/overhead benchmarks for the proxy itself, third-party performance testing, and architecture details (e.g., edge/WASM deployment) that would substantiate minimal added latency beyond the cache-hit speedup claim.

              • [claimed-docs] “Cache LLM responses to serve requests up to **20x faster** and cheaper.”
              • [claimed-docs] “It takes 2 mins to integrate and with that, it starts monitoring all of your LLM requests and makes your app resilient, secure, performant, …”
              • [claimed-docs] “offering advanced tools for control, visibility, and security in your Generative AI apps”
              • [claimed-docs] “We've open sourced our battle-tested AI gateway to the community. You can run it locally with a single command:”
              proof ↗⚑ flag
              Requestypartialclaimed5/10

              Requesty is a gateway/router with caching, fallback, and analytics features that imply performance-conscious design, and analytics dashboard tracks latency, but there is no explicit benchmark or claim quantifying gateway-added latency overhead. missing for 10: published latency benchmarks or overhead numbers, independent performance testing, and any explicit low-latency architecture documentation.

              • [claimed-docs] “Requesty's auto caching automatically caches long system prompts and repeated content to reduce costs on any provider that supports prompt c…”
              • [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
              • [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
              proof ↗⚑ flag

            Cost controls — stories about cost controls in this arenaCost controls

            Stories about cost controls in this arena

            Agent guardrails

            1. ai-native userGive an autonomous agent its own key with budget and rate guardrails so it cannot run away on spend

              weight 2 · round to Portkey
              Portkeyfullclaimed8/10

              Portkey docs explicitly support issuing API keys with budget and rate limits (spend thresholds, hourly/daily/per-minute request/token limits) that automatically block further usage when exceeded, directly matching the guardrail need for an autonomous agent's key. Fine-grained control at org/workspace level and per-key configuration is documented. Missing for 10: no explicit mention of a per-agent key issuance workflow or independent/hands-on verification that the cutoff actually stops an agent mid-run.

              • [claimed-docs] “Configure budget and rate limits on API keys to effectively manage AI spending and usage across your organization”
              • [claimed-docs] “Budget limits allow you to set maximum LLM spending or token usage thresholds on your API keys, automatically preventing further usage when …”
              • [claimed-docs] “Set hourly, daily, or per minute rate limits on requests or tokens sent”
              • [claimed-docs] “Fine-grained control: budgets, rate limits, and model allow-lists at both org and workspace level.”
              • [claimed-docs] “**Reset Weekly**: Budget limits reset every Sunday at 12 AM UTC”
              proof ↗⚑ flag
              Requestynone0/10

              Requesty is an LLM gateway product where issuing scoped API keys with spend/rate limits would be a natural and expected capability, but the evidence pack only shows BYOK (using your own provider keys), content-safety 'guardrails' (sensitive-data scanning, not spend limits), and usage analytics dashboards for visibility — none of which describe issuing an agent its own key with a budget cap or rate limit to prevent runaway spend.

              • [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
              • [claimed-docs] “Guardrails scan AI request content for sensitive information before it reaches a model provider.”
              • [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
              proof ↗⚑ flag

            Budgets

            1. platform engineerSet hard budgets and spend limits per key, team, or user

              weight 3 · round to Portkey
              Portkeyfullclaimed9/10

              Portkey's docs explicitly describe setting budget limits (max spend or token usage) and rate limits on API keys, with org/workspace-level fine-grained control, automatic enforcement when limits are reached, notification thresholds, and weekly resets — directly matching per-key/team/user budget/spend controls. Missing for 10: no independent/hands-on corroboration beyond first-party docs.

              • [claimed-docs] “Configure budget and rate limits on API keys to effectively manage AI spending and usage across your organization”
              • [claimed-docs] “When usage reaches this threshold, notifications will be sent to configured recipients”
              • [claimed-docs] “Budget limits allow you to set maximum LLM spending or token usage thresholds on your API keys, automatically preventing further usage when …”
              • [claimed-docs] “Fine-grained control: budgets, rate limits, and model allow-lists at both org and workspace level.”
              • [claimed-docs] “**Reset Weekly**: Budget limits reset every Sunday at 12 AM UTC”
              • [claimed-docs] “Set hourly, daily, or per minute rate limits on requests or tokens sent”
              proof ↗⚑ flag
              Requestynone0/10

              The evidence pack shows analytics/usage tracking and BYOK/governance mentions, but no documentation of setting hard budgets or spend limits per API key, team, or user. This is a plausible and expected axis for an LLM gateway product like Requesty, so absence of evidence yields 'none'.

              • [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
              • [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
              proof ↗⚑ flag

            Spend tracking

            1. platform engineerTrack spend per model, key, team, or user across all providers in one place

              weight 3 · round to Portkey
              Portkeyfullclaimed7/10

              Portkey's docs describe budget/rate limits and spend caps on API keys, a unified model catalog with org/workspace-level governance and allow-lists, and logs filterable by Config ID for auditing usage, which together give spend visibility across providers/keys/teams. Missing for 10: explicit per-user spend breakdown dashboards and independent/hands-on confirmation of a unified cost dashboard beyond docs claims.

              • [claimed-docs] “Configure budget and rate limits on API keys to effectively manage AI spending and usage across your organization”
              • [claimed-docs] “Budget limits allow you to set maximum LLM spending or token usage thresholds on your API keys, automatically preventing further usage when …”
              • [claimed-docs] “Fine-grained control: budgets, rate limits, and model allow-lists at both org and workspace level.”
              • [claimed-docs] “A single pane to view and manage every AI provider and model in your organization. It provides centralized governance, discovery, and usage …”
              • [claimed-docs] “Filter logs by `Config ID` to see all requests using that config”
              • [claimed-docs] “The core concept remains the same - one Portkey API key gives you access to multiple providers and models.”
              • [claimed-docs] “Set hourly, daily, or per minute rate limits on requests or tokens sent”
              proof ↗⚑ flag
              Requestypartialclaimed6/10

              Requesty's analytics dashboard tracks costs, requests, tokens, cache savings, and latency across all models/providers in real-time, and trace_id/user_id tagging plus BYOK support per-key tracking, which covers most of the story. missing for 10: explicit documentation of per-team breakdowns/team-level grouping, per-user cost attribution dashboards, and independent/hands-on corroboration of the analytics dashboard's granularity beyond vendor docs.

              • [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
              • [claimed-docs] “Requests with the same trace_id or user_id always go to the same model.”
              • [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
              • [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
              proof ↗⚑ flag

            Key management — stories about key management in this arenaKey management

            Stories about key management in this arena

            Byok

            1. developerBring my own provider API keys and have the gateway use them for my traffic

              weight 2 · round drawn
              Portkeyfullclaimed8/10

              Portkey's virtual keys and model catalog explicitly let developers add/store their own provider API keys ('Add a provider, then use @provider-slug/model-name', 'Provider credentials stored securely, never exposed in code'), and the gateway routes traffic through these keys with governance/rate-limit controls layered on top. Missing for 10: independent hands-on verification of the BYO-key flow and no explicit mention of per-key traffic isolation/audit beyond docs claims.

              • [claimed-docs] “The core concept remains the same - one Portkey API key gives you access to multiple providers and models.”
              • [claimed-docs] “Add a provider, then use `@provider-slug/model-name` in your code.”
              • [claimed-docs] “Provider credentials stored securely, never exposed in code”
              • [claimed-docs] “A single pane to view and manage every AI provider and model in your organization. It provides centralized governance, discovery, and usage …”
              • [claimed-docs] “Fine-grained control: budgets, rate limits, and model allow-lists at both org and workspace level.”
              proof ↗⚑ flag
              Requestyfullclaimed8/10

              Requesty explicitly documents a BYOK feature allowing developers to use personal API keys from various providers with the gateway, alongside the standard OpenAI-compatible routing setup. Missing for 10: independent/hands-on confirmation of BYOK working in practice and details on key storage/security guarantees.

              • [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
              • [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
              • [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
              proof ↗⚑ flag

            Programmatic admin

            1. ai-native userProvision gateways, keys, and budgets programmatically through an admin API

              weight 3 · round drawn
              Portkeynone0/10

              Evidence shows budget/rate-limit and key management as dashboard-configurable features (docs-13, docs-25, docs-35, docs-38) but never describes a programmatic Admin API for provisioning gateways, keys, or budgets; the only API reference documented is the inference API (docs-15, docs-16, docs-36), and probes for an OpenAPI/admin API spec returned 404 (portkey-probe-3, portkey-probe-2).

              • [claimed-docs] “Configure budget and rate limits on API keys to effectively manage AI spending and usage across your organization”
              • [claimed-docs] “Budget limits allow you to set maximum LLM spending or token usage thresholds on your API keys, automatically preventing further usage when …”
              • [claimed-docs] “**Reset Weekly**: Budget limits reset every Sunday at 12 AM UTC”
              • [claimed-docs] “The base URL for all REST API requests is `https://api.portkey.ai/v1`”
              • [probe] “PROBE openapi: all candidate paths 404 (https://portkey.ai/openapi.json, https://portkey.ai/swagger.json, https://portkey.ai/api/openapi.jso…”
              • [probe] “PROBE docs-md: HTTP 404 at https://portkey.ai/docs.md”
              proof ↗⚑ flag
              Requestynone0/10

              No evidence of an admin API for programmatically provisioning gateways, keys, or budgets; docs cover BYOK (manual key entry), analytics dashboard, and routing policies, but nothing about API-driven account/key/budget provisioning. The OpenAPI/swagger probe returned 404 for all candidate paths, further indicating no discoverable admin API surface.

              • [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
              • [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
              • [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
              proof ↗⚑ flag

            Virtual keys

            1. platform engineerMint gateway-managed keys for teams and apps without exposing raw provider keys

              weight 3 · round to Portkey
              Portkeyfullclaimed8/10

              Portkey's virtual keys/model catalog explicitly let platform engineers mint provider-agnostic API keys that map to real provider credentials, which are stored securely and never exposed in code, while budgets, rate limits, and model allow-lists can be enforced per key at org/workspace level for teams and apps. This directly matches minting gateway-managed keys without exposing raw provider keys. Missing for 10: independent/hands-on verification beyond vendor docs, and detail on per-team/app key issuance workflow (e.g., self-service or RBAC-scoped key creation) rather than admin-level config.

              • [claimed-docs] “The core concept remains the same - one Portkey API key gives you access to multiple providers and models.”
              • [claimed-docs] “Provider credentials stored securely, never exposed in code”
              • [claimed-docs] “Configure budget and rate limits on API keys to effectively manage AI spending and usage across your organization”
              • [claimed-docs] “Budget limits allow you to set maximum LLM spending or token usage thresholds on your API keys, automatically preventing further usage when …”
              • [claimed-docs] “Fine-grained control: budgets, rate limits, and model allow-lists at both org and workspace level.”
              • [claimed-docs] “Set hourly, daily, or per minute rate limits on requests or tokens sent”
              • [claimed-docs] “Add a provider, then use `@provider-slug/model-name` in your code.”
              proof ↗⚑ flag
              Requestynone0/10

              Evidence covers BYOK (users supplying their own provider keys into Requesty) and general governance/analytics claims, but nothing describes an admin/platform-engineer flow for minting distinct gateway-managed keys per team or app that shield the underlying provider keys. Missing for 10: documentation of virtual/scoped key issuance, team/app-level key scoping, or key rotation/management APIs.

              • [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
              • [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
              proof ↗⚑ flag

            Observability — seeing what the system is doing — logs, metrics, traces, alertsObservability

            Seeing what the system is doing — logs, metrics, traces, alerts

            Integrations

            1. developerExport gateway logs and traces to my own observability stack

              weight 1 · round drawn
              Portkeynone0/10

              Evidence describes Portkey's own logs UI, sharing log URLs, and manual feedback tagging, but there is no mention of exporting logs/traces to third-party observability stacks (e.g., OpenTelemetry, Datadog, Grafana) or any API/webhook for bulk export.

                ⚑ flag
                Requestynone0/10

                Requesty documents an internal analytics dashboard for usage visibility, but there is no evidence of any export mechanism (webhooks, OpenTelemetry, log/trace export API, or third-party observability integrations like Datadog/Grafana) that would let a developer send gateway logs/traces to their own observability stack.

                • [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
                proof ↗⚑ flag

              Logs

              1. platform engineerInspect logged requests and responses with latency, token counts, and cost attached

                weight 3 · round to Requesty
                Portkeypartialclaimed5/10

                Portkey's docs confirm a Logs section showing a chronological list of all requests with unique shareable URLs and manual feedback tagging, supporting log inspection generally, and repeated claims of 'monitoring all LLM requests' and 'visibility' across the gateway. However, the evidence pack never explicitly documents latency, token count, or cost fields being displayed per log entry. Missing for 10: explicit documentation or screenshots showing latency/tokens/cost columns in the logs UI, independent/hands-on confirmation of these fields.

                • [claimed-docs] “The Logs section presents a chronological list of all the requests processed through Portkey.”
                • [claimed-docs] “Each log on Portkey has a unique URL. You can copy the link from the address bar and directly share it with anyone in your org.”
                • [claimed-docs] “you can also add manual feedback on the logs to be analysed and filtered later”
                • [claimed-docs] “It takes 2 mins to integrate and with that, it starts monitoring all of your LLM requests”
                • [claimed-docs] “It takes 2 mins to integrate and with that, it starts monitoring all of your LLM requests and makes your app resilient, secure, performant, …”
                proof ↗⚑ flag
                Requestypartialclaimed6/10

                Requesty's analytics dashboard docs confirm tracking of costs, requests, tokens, cache savings, and latency in real-time, which covers most of the story, but there is no evidence of inspecting individual logged request/response payload content (bodies) rather than aggregate metrics. missing for 10: evidence of per-request log inspection with full request/response bodies, screenshots or independent corroboration of the dashboard UI, and confirmation of per-call cost/latency drill-down rather than aggregate analytics.

                • [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
                proof ↗⚑ flag

              Openness — open source, data portability, and self-hosting storiesOpenness

              Open source, data portability, and self-hosting stories

              1. ai-native userDo everything through the API that I can do in the UI

                weight 2 · round to Portkey
                Portkeypartialprobed5/10

                Portkey's core AI gateway (chat/completions, fallbacks, caching, retries, load balancing) is clearly exposed via a REST API with a stable base URL, and the open-source gateway can be run locally — showing strong API-first design for request routing. However there is no evidence of API access to the administrative/UI-only features such as budget & rate-limit configuration, log viewing/sharing, feedback tagging, or virtual-key management, and probes show no public OpenAPI spec, so full UI-API parity isn't demonstrated. missing for 10: API endpoints for budget/rate-limit admin, log retrieval/sharing via API, feedback API, and a public OpenAPI spec confirming complete parity.

                • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey’s features into your existing setup.”
                • [claimed-docs] “The base URL for all REST API requests is `https://api.portkey.ai/v1`”
                • [claimed-docs] “Ideal for: if you’re currently utilizing OpenAI’s Python or Node.js SDKs. By changing the base URL and adding Portkey-specific headers, you …”
                • [claimed-docs] “We've open sourced our battle-tested AI gateway to the community. You can run it locally with a single command:”
                • [claimed-docs] “Configure budget and rate limits on API keys to effectively manage AI spending and usage across your organization”
                • [claimed-docs] “The Logs section presents a chronological list of all the requests processed through Portkey.”
                • [probe] “PROBE openapi: all candidate paths 404 (https://portkey.ai/openapi.json, https://portkey.ai/swagger.json, https://portkey.ai/api/openapi.jso…”
                proof ↗⚑ flag
                Requestypartialprobed4/10

                Requesty's core inference path (chat completions, model routing) is fully API-driven via an OpenAI-compatible endpoint, and features like fallback/load-balancing policies, BYOK, and guardrails are described as usable at request time. However, there's no evidence of a management/admin API for configuring these policies, keys, or viewing analytics programmatically, and the OpenAPI spec probe returned 404s across all candidate paths, suggesting dashboard-only configuration for policy setup and analytics viewing. missing for 10: a documented admin/management API for configuring fallback policies, load balancing, guardrails, BYOK keys, and pulling analytics data programmatically; a published OpenAPI spec confirming full API parity with the dashboard.

                • [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
                • [claimed-docs] “Load Balancing Policies distribute your requests across multiple models based on weights you define. Perfect for A/B testing, gradual rollou…”
                • [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
                • [claimed-docs] “Guardrails scan AI request content for sensitive information before it reaches a model provider.”
                • [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
                • [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
                proof ↗⚑ flag

              2. ai-native userExport all of my data in open formats and leave

                weight 3 · round drawn
                Portkeynone0/10

                Portkey's docs cover logging, gateway configuration, and self-hosting the open-source gateway, but there is no mention of exporting stored logs/configs/data in open formats or facilitating a full data export for migration away from the platform. Shareable log URLs (portkey-docs-12) are not a bulk export/portability feature.

                • [claimed-docs] “The Logs section presents a chronological list of all the requests processed through Portkey.”
                • [claimed-docs] “Each log on Portkey has a unique URL. You can copy the link from the address bar and directly share it with anyone in your org.”
                • [claimed-docs] “We've open sourced our battle-tested AI gateway to the community. You can run it locally with a single command:”
                proof ↗⚑ flag
                Requestynone0/10

                The evidence pack covers routing, caching, guardrails, analytics dashboard, and pricing, but nothing describes exporting usage data, logs, or configuration in open formats or a data-portability/account-deletion path. This is a fair question for a gateway that stores analytics/usage data, so absence of evidence yields 'none' rather than 'na'.

                • [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
                proof ↗⚑ flag

              3. ai-native userRead the product's source under an open license

                weight 2 · round to Portkey
                Portkeypartialclaimed5/10

                Portkey explicitly states it open-sourced its AI gateway component ('We've open sourced our battle-tested AI gateway to the community... run it locally with a single command'), which supports reading some source code. However, this only covers the gateway, not the full product (observability, admin console, model catalog, etc.), and no explicit license name or repository link is provided in the evidence. Missing for 10: explicit open-source license identification, confirmation that the broader Portkey platform (not just the gateway) is open source, and a linked public repository.

                • [claimed-docs] “We've open sourced our battle-tested AI gateway to the community. You can run it locally with a single command:”
                • [claimed-docs] “npx @portkey-ai/gateway”
                proof ↗⚑ flag
                Requestynone0/10

                No evidence of an open-source license or public source repository for Requesty; it appears to be a closed commercial SaaS gateway with only documentation and API access exposed. Missing for 10: any mention of open-source licensing, public code repository, or license file.

                  ⚑ flag

                • ai-native userSelf-host the core product

                  weight 3 · round to Portkey
                  Portkeypartialclaimed6/10

                  Docs confirm the AI Gateway — described as the 'battle-tested' core routing component — is open-sourced and can be run locally via a single npx command, which is genuine self-hosting evidence. However, other core parts of the product (observability/logs UI, admin budget/rate-limit controls, model catalog governance) are described only as hosted SaaS features with no mention of self-hosting. Missing for 10: evidence that the full platform (observability, admin, model catalog) can be self-hosted, not just the gateway component, and any independent confirmation of self-hosting in practice.

                  • [claimed-docs] “npx @portkey-ai/gateway”
                  • [claimed-docs] “We've open sourced our battle-tested AI gateway to the community. You can run it locally with a single command:”
                  • [claimed-docs] “A single pane to view and manage every AI provider and model in your organization. It provides centralized governance, discovery, and usage …”
                  • [claimed-docs] “Configure budget and rate limits on API keys to effectively manage AI spending and usage across your organization”
                  proof ↗⚑ flag
                  Requestynone0/10

                  Requesty is presented as a hosted cloud gateway/router service (EU routing, hosted dashboard, per-usage pricing) with no evidence of a self-hosted deployment option, open-source repo, or on-prem package. No documentation mentions self-hosting the core routing product.

                    ⚑ flag

                  Privacy posture — data-handling and privacy storiesPrivacy posture

                  Data-handling and privacy stories

                  1. ai-native userChoose where my data is stored (region/residency)

                    weight 2 · round to Requesty
                    Portkeynone0/10

                    No evidence pack items mention data residency, regional storage options, or geographic hosting choices; Portkey's docs focus on gateway routing, caching, retries, budgets, and observability rather than data residency controls.

                      ⚑ flag
                      Requestypartialclaimed6/10

                      Requesty offers an explicit EU-routing option (Frankfurt, AWS eu-central-1) keeping processing and storage within the EU, giving users some data-residency choice. However, evidence only shows one alternative region (EU vs default), not a broader set of selectable regions/residency options. Missing for 10: documentation of additional region choices (e.g., US-only, APAC), enterprise data-residency controls, and independent verification of enforcement.

                      • [claimed-docs] “Route your AI traffic through Requesty's EU infrastructure in Frankfurt, Germany (AWS eu-central-1). All processing and storage by Requesty …”
                      proof ↗⚑ flag

                    • ai-native userPrevent my data from being used to train AI models

                      weight 3 · round drawn
                      Portkeynone0/10

                      Evidence pack covers gateway routing, caching, retries, logging, budgeting, etc., but contains no mention of a data-training opt-out, zero-retention policy, or any privacy control preventing use of data for AI model training.

                        ⚑ flag
                        Requestynone0/10

                        The evidence pack covers routing, caching, guardrails, EU data residency, and BYOK, but contains no statement about a no-training policy or data opt-out for model training, so this claim is unevidenced.

                          ⚑ flag

                        • ai-native userControl data retention and deletion

                          weight 2 · round drawn
                          Portkeynone0/10

                          The evidence pack covers gateway routing, caching, retries, budgets, and logging, but contains no mention of data retention policies, log/data deletion controls, or configurable retention windows.

                            ⚑ flag
                            Requestynone0/10

                            The evidence pack shows EU data-residency routing and guardrails for sensitive content scanning, but nothing about data retention periods, deletion controls, or user-initiated data purge/export mechanisms. Missing for 10: documented retention policy, deletion/erasure API or dashboard control, retention configuration options.

                            • [claimed-docs] “Route your AI traffic through Requesty's EU infrastructure in Frankfurt, Germany (AWS eu-central-1). All processing and storage by Requesty …”
                            • [claimed-docs] “Guardrails scan AI request content for sensitive information before it reaches a model provider.”
                            proof ↗⚑ flag

                          • ai-native userOpt out of telemetry and usage tracking

                            weight 2 · round drawn
                            Portkeynone0/10

                            Portkey is essentially a telemetry/observability platform (logs, monitoring of all LLM requests) with no evidence of any opt-out mechanism for its own tracking or usage telemetry; the evidence pack only documents features for logging, caching, retries, and governance, never a privacy/telemetry opt-out control.

                              ⚑ flag
                              Requestynone0/10

                              The evidence pack shows analytics/usage dashboards and EU data routing but contains no mention of a telemetry/usage-tracking opt-out setting or privacy control for disabling data collection. As a hosted API gateway that logs requests, this is a fair axis to expect documentation on, but none is present.

                              • [claimed-docs] “Requesty's analytics dashboard gives you complete visibility into your AI usage across all models and providers. Track costs, requests, toke…”
                              • [claimed-docs] “Route your AI traffic through Requesty's EU infrastructure in Frankfurt, Germany (AWS eu-central-1). All processing and storage by Requesty …”
                              proof ↗⚑ flag

                            Routing resilience — stories about routing resilience in this arenaRouting resilience

                            Stories about routing resilience in this arena

                            Fallbacks

                            1. platform engineerConfigure automatic fallback to another model or provider when one fails

                              weight 3 · round to Portkey
                              Portkeyfullclaimed9/10

                              Portkey's docs explicitly describe configuring a prioritized list of providers/models with automatic fallback when the primary fails, customizable trigger status codes, plus complementary retries and load balancing for resilience. missing for 10: independent/hands-on corroboration beyond vendor docs.

                              • [claimed-docs] “Specify a prioritized list of providers/models. If the primary LLM fails, Portkey automatically falls back to the next in line.”
                              • [claimed-docs] “By default, fallback triggers on any **non-2xx** status code. Customize with `on_status_codes`”
                              • [claimed-docs] “Automatically retry failed LLM requests with exponential backoff.”
                              • [claimed-docs] “Configure per-strategy circuit protection and failure handling”
                              proof ↗⚑ flag
                              Requestyfullclaimed8/10

                              Requesty's Fallback Policies feature explicitly documents automatic retry to a different model/provider when the primary fails (timeout, rate limit, error), directly matching the story. Missing for 10: independent/hands-on corroboration beyond vendor docs and detail on configuration granularity (e.g., how fallback chains are set up in the dashboard/API).

                              • [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
                              • [claimed-docs] “Your request goes to the primary model first. If it fails (timeout, rate limit, error, etc.), the router immediately tries the next model in…”
                              proof ↗⚑ flag

                            Load balancing

                            1. platform engineerLoad-balance traffic across providers, deployments, or keys by weight, latency, or cost

                              weight 2 · round to Portkey
                              Portkeyfullclaimed8/10

                              Portkey's docs explicitly document load balancing to distribute traffic across multiple LLMs/providers by weight, plus gradual migration (percentage-based rollout) and fallback on failure/latency-driven retries, all configurable via Configs. This directly matches weight-based and failure/latency-based routing across providers/deployments/keys, backed by first-party docs on load-balancing, fallbacks, and virtual keys. Missing for 10: explicit cost-based routing strategy documentation and independent/hands-on verification beyond vendor docs.

                              • [claimed-docs] “Distribute traffic across multiple LLMs to prevent any single provider from becoming a bottleneck.”
                              • [claimed-docs] “**Gradual Migration** | Test new models with small percentage before full rollout”
                              • [claimed-docs] “**Gradual Migration**|Test new models with small percentage before full rollout”
                              • [claimed-docs] “Specify a prioritized list of providers/models. If the primary LLM fails, Portkey automatically falls back to the next in line.”
                              • [claimed-docs] “By default, fallback triggers on any **non-2xx** status code. Customize with `on_status_codes`”
                              • [claimed-docs] “The core concept remains the same - one Portkey API key gives you access to multiple providers and models.”
                              • [claimed-docs] “Configure per-strategy circuit protection and failure handling”
                              proof ↗⚑ flag
                              Requestypartialclaimed6/10

                              Requesty documents weight-based Load Balancing Policies that distribute requests across multiple models/providers, plus session affinity via trace_id/user_id, and separate Fallback Policies for failure-driven rerouting. However, there is no evidence of latency-based or cost-based load balancing—only weight is explicitly supported. missing for 10: latency-based routing/balancing, cost-based routing/balancing, explicit per-key (not just per-model/provider) balancing.

                              • [claimed-docs] “Load Balancing Policies distribute your requests across multiple models based on weights you define. Perfect for A/B testing, gradual rollou…”
                              • [claimed-docs] “Requests with the same trace_id or user_id always go to the same model.”
                              • [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
                              • [claimed-docs] “Your request goes to the primary model first. If it fails (timeout, rate limit, error, etc.), the router immediately tries the next model in…”
                              proof ↗⚑ flag

                            Policy routing

                            1. ai-native userMy agent can switch models mid-task by policy — cost, capability, or availability — through gateway routing rules

                              weight 3 · round drawn
                              Portkeyfullclaimed8/10

                              Portkey's gateway supports policy-based model switching via conditional fallbacks (status-code triggers), load balancing/weighted routing, gradual migration and canary rollout, plus budget/rate-limit enforcement that can trigger automatic switching for cost/availability reasons - all configurable via routing configs applied at request time. This directly matches mid-task, policy-driven model switching for cost, capability, or availability. Missing for 10: independent/hands-on corroboration of dynamic mid-task capability-based switching (vs. failure-triggered fallback), and explicit example of capability-based routing rules (e.g., routing by task type).

                              • [claimed-docs] “Specify a prioritized list of providers/models. If the primary LLM fails, Portkey automatically falls back to the next in line.”
                              • [claimed-docs] “By default, fallback triggers on any **non-2xx** status code. Customize with `on_status_codes`”
                              • [claimed-docs] “Distribute traffic across multiple LLMs to prevent any single provider from becoming a bottleneck.”
                              • [claimed-docs] “**Gradual Migration** | Test new models with small percentage before full rollout”
                              • [claimed-docs] “Canary test new models in production”
                              • [claimed-docs] “Configure budget and rate limits on API keys to effectively manage AI spending and usage across your organization”
                              • [claimed-docs] “Budget limits allow you to set maximum LLM spending or token usage thresholds on your API keys, automatically preventing further usage when …”
                              • [claimed-docs] “Set hourly, daily, or per minute rate limits on requests or tokens sent”
                              • [claimed-docs] “Configure per-strategy circuit protection and failure handling”
                              proof ↗⚑ flag
                              Requestyfullclaimed8/10

                              Requesty's gateway supports fallback policies (retry with different models on failure/rate limit/error), load-balancing policies (distribute across models by weight, sticky routing by trace/user), and access to 300+/600+ models via a single API, directly enabling policy-based mid-task model switching for cost, capability, or availability reasons. missing for 10: no independent/hands-on corroboration of dynamic policy switching in a live agent task, and no explicit example combining cost+capability+availability rules in one policy config.

                              • [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
                              • [claimed-docs] “Your request goes to the primary model first. If it fails (timeout, rate limit, error, etc.), the router immediately tries the next model in…”
                              • [claimed-docs] “Load Balancing Policies distribute your requests across multiple models based on weights you define. Perfect for A/B testing, gradual rollou…”
                              • [claimed-docs] “Requests with the same trace_id or user_id always go to the same model.”
                              • [claimed-docs] “Using the Requesty integration, you can: Use 300+ models while coding, giving you flexibility to choose the best model for each task.”
                              • [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
                              proof ↗⚑ flag

                            Rate limits

                            1. platform engineerSmooth provider rate limits by spreading traffic across keys and queuing or throttling requests

                              weight 2 · round to Portkey
                              Portkeyfullclaimed8/10

                              Portkey documents load balancing across multiple provider keys/models to avoid bottlenecks, automatic retries with exponential backoff or provider retry-after headers, and configurable per-key/org rate limits (hourly/daily/per-minute) alongside budget limits — directly addressing spreading traffic and throttling/queuing around rate limits. Multiple virtual keys per provider further support distributing load to smooth rate limits. Missing for 10: explicit first-party or independent evidence of a request queue (vs. retry/backoff) and hands-on/independent validation of these features working under real rate-limit pressure.

                              • [claimed-docs] “Distribute traffic across multiple LLMs to prevent any single provider from becoming a bottleneck.”
                              • [claimed-docs] “Automatically retry failed LLM requests with exponential backoff.”
                              • [claimed-docs] “Enable `use_retry_after_headers` to use the provider’s `retry-after-ms`, `x-ms-retry-after-ms`, or `retry-after` headers instead of exponent…”
                              • [claimed-docs] “Enable `use_retry_after_headers` to use the provider's `retry-after-ms`, `x-ms-retry-after-ms`, or `retry-after` headers instead of exponent…”
                              • [claimed-docs] “Set hourly, daily, or per minute rate limits on requests or tokens sent”
                              • [claimed-docs] “Configure budget and rate limits on API keys to effectively manage AI spending and usage across your organization”
                              • [claimed-docs] “The core concept remains the same - one Portkey API key gives you access to multiple providers and models.”
                              • [claimed-docs] “Fine-grained control: budgets, rate limits, and model allow-lists at both org and workspace level.”
                              proof ↗⚑ flag
                              Requestypartialclaimed5/10

                              Requesty's Fallback Policies explicitly retry on rate-limit errors by switching models, and Load Balancing Policies distribute requests across multiple models/providers by weight, which can smooth rate-limit pressure; BYOK lets users supply multiple provider keys. However, there is no documented queuing/throttling mechanism or explicit per-key round-robin/rate-limit-aware routing across multiple keys for the same provider. Missing for 10: explicit request queuing/throttling controls, documented multi-key rotation within a single provider, and rate-limit-specific load-balancing logic (vs. general failure retries).

                              • [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
                              • [claimed-docs] “Your request goes to the primary model first. If it fails (timeout, rate limit, error, etc.), the router immediately tries the next model in…”
                              • [claimed-docs] “Load Balancing Policies distribute your requests across multiple models based on weights you define. Perfect for A/B testing, gradual rollou…”
                              • [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
                              proof ↗⚑ flag

                            Retries

                            1. platform engineerSet automatic retry policies for transient provider errors

                              weight 2 · round to Portkey
                              Portkeyfullclaimed8/10

                              Portkey's docs explicitly describe automatic retries with exponential backoff and support for provider retry-after headers, directly matching the story of configuring retry policies for transient errors. missing for 10: independent/hands-on corroboration beyond vendor docs, and configuration details on per-error-code or max-retry-count customization.

                              • [claimed-docs] “Automatically retry failed LLM requests with exponential backoff.”
                              • [claimed-docs] “Enable `use_retry_after_headers` to use the provider’s `retry-after-ms`, `x-ms-retry-after-ms`, or `retry-after` headers instead of exponent…”
                              • [claimed-docs] “Enable `use_retry_after_headers` to use the provider's `retry-after-ms`, `x-ms-retry-after-ms`, or `retry-after` headers instead of exponent…”
                              proof ↗⚑ flag
                              Requestypartialclaimed6/10

                              Requesty's Fallback Policies explicitly retry requests on a different model when the primary fails due to timeout, rate limit, or error, which directly addresses transient provider errors. However, this is model-fallback rather than a configurable retry policy (e.g., retry counts, backoff intervals, retry-same-provider-first) explicitly for transient errors. missing for 10: documentation of configurable retry counts/backoff on the same provider before failover, independent/hands-on confirmation of retry behavior, and explicit mention of 'transient error' handling distinct from full model fallback.

                              • [claimed-docs] “Fallback Policies automatically retry your requests with different models if one fails, ensuring your application stays reliable even when i…”
                              • [claimed-docs] “Your request goes to the primary model first. If it fails (timeout, rate limit, error, etc.), the router immediately tries the next model in…”
                              proof ↗⚑ flag

                            Streaming tools — stories about streaming tools in this arenaStreaming tools

                            Stories about streaming tools in this arena

                            Streaming

                            1. developerStream token-by-token responses through the gateway from any provider

                              weight 3 · round to Requesty
                              Portkeynone0/10

                              The evidence describes Portkey's gateway, fallbacks, retries, load balancing, caching, and OpenAI-compatible base URL integration, but none of the provided docs mention streaming or token-by-token response support. Streaming is a fair and expected capability for an LLM gateway product, so its absence in the evidence pack means this axis applies but is unproven.

                              • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey’s features into your existing setup.”
                              • [claimed-docs] “The base URL for all REST API requests is `https://api.portkey.ai/v1`”
                              • [claimed-docs] “Ideal for: if you’re currently utilizing OpenAI’s Python or Node.js SDKs. By changing the base URL and adding Portkey-specific headers, you …”
                              • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey's features into your existing setup.”
                              proof ↗⚑ flag
                              Requestypartialclaimed4/10

                              Requesty claims full OpenAI-SDK compatibility with no code changes (drop-in base_url swap), which implies standard SDK streaming (stream=True) would work across any of its 300+ models, but no evidence pack item explicitly confirms streaming/token-by-token behavior or documents a streaming example. missing for 10: explicit streaming documentation/example, confirmation across multiple providers, and any independent/hands-on verification of streaming behavior.

                              • [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
                              • [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
                              • [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
                              proof ↗⚑ flag

                            Tool calling

                            1. developerRequest structured JSON-schema outputs across providers

                              weight 1 · round to Requesty
                              Portkeynone0/10

                              The evidence pack covers gateway features like fallbacks, retries, load balancing, caching, virtual keys, and logging, but contains no mention of structured JSON-schema output support, response_format normalization, or schema validation across providers. Since Portkey acts as a universal AI gateway, this capability would be plausible, but no documentation cites it.

                                ⚑ flag
                                Requestyfullclaimed8/10

                                Requesty explicitly documents structured outputs, stating it makes 'every supported model speak structured JSON — from simple json_object mode to strict, schema-enforced json_schema mode,' directly addressing cross-provider JSON-schema support via its unified OpenAI-compatible API. Missing for 10: independent/hands-on verification across multiple providers and no explicit list of which of the 300+ models fully honor strict schema enforcement.

                                • [claimed-docs] “Requesty makes every supported model speak structured JSON — from simple json_object mode to strict, schema-enforced json_schema mode.”
                                • [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
                                • [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
                                proof ↗⚑ flag

                              • developerMake tool and function calls across different providers with a consistent schema

                                weight 3 · round to Requesty
                                Portkeypartialclaimed5/10

                                Portkey's gateway offers a unified OpenAI-SDK-compatible API (base URL + headers) across 250+ models, which implies a consistent request format including function/tool call fields, and it supports connecting external tools via remote MCP servers. However, there is no explicit documentation describing how tool/function-calling schemas are normalized or translated across different providers' native formats. Missing for 10: explicit docs on function/tool-call schema normalization, examples of tool-calling requests across multiple providers, and independent verification that tool calls work consistently across providers.

                                • [claimed-docs] “It serves as a unified interface for interacting with over 250 AI models, offering advanced tools for control, visibility, and security in y…”
                                • [claimed-docs] “Ideal for: if you’re currently utilizing OpenAI’s Python or Node.js SDKs. By changing the base URL and adding Portkey-specific headers, you …”
                                • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey’s features into your existing setup.”
                                • [claimed-docs] “Connect to Remote MCP severs, allowing you to connect external tools and data sources.”
                                proof ↗⚑ flag
                                Requestypartialclaimed6/10

                                Requesty's OpenAI-compatible unified API (docs-1, docs-2, docs-16) implies that developers can use the same OpenAI SDK request format—including tool/function-call schema—across 300+/600+ models, and structured-outputs docs (docs-14) show JSON/schema-enforced output support across providers. However, there is no explicit documentation or example showing tool/function-call payloads being translated or normalized for non-OpenAI-native providers, nor any hands-on confirmation that function calling works uniformly across all providers. Missing for 10: explicit function/tool-calling schema documentation, cross-provider tool-call examples, and independent verification of consistent behavior across providers.

                                • [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
                                • [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
                                • [claimed-docs] “Requesty makes every supported model speak structured JSON — from simple json_object mode to strict, schema-enforced json_schema mode.”
                                • [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
                                proof ↗⚑ flag

                              Unified api — stories about unified api in this arenaUnified api

                              Stories about unified api in this arena

                              Catalog

                              1. developerBrowse or query a catalog of available models with pricing and context-window metadata

                                weight 2 · round to Portkey
                                Portkeypartialclaimed5/10

                                Portkey documents a 'Model Catalog' providing a single pane to view/manage all providers and models with discovery and governance controls, and claims access to 250+ models, but no evidence shows the catalog surfaces pricing or context-window metadata for models. missing for 10: explicit documentation of per-model pricing info, explicit documentation of context-window size metadata, and any UI/query example showing these fields.

                                • [claimed-docs] “A single pane to view and manage every AI provider and model in your organization. It provides centralized governance, discovery, and usage …”
                                • [claimed-docs] “It serves as a unified interface for interacting with over 250 AI models, offering advanced tools for control, visibility, and security in y…”
                                • [claimed-docs] “Add a provider, then use `@provider-slug/model-name` in your code.”
                                • [claimed-docs] “Fine-grained control: budgets, rate limits, and model allow-lists at both org and workspace level.”
                                proof ↗⚑ flag
                                Requestynone0/10

                                Evidence confirms Requesty routes across 300–600+ models via a unified API, but nothing in the pack documents a browsable/queryable model catalog exposing pricing or context-window metadata (no /models endpoint, no models page, and the OpenAPI probe returned 404s). missing for 10: a models catalog page or API endpoint, per-model pricing data, per-model context-window metadata.

                                • [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
                                • [claimed-docs] “Using the Requesty integration, you can: Use 300+ models while coding, giving you flexibility to choose the best model for each task.”
                                • [probe] “PROBE openapi: all candidate paths 404 (https://docs.requesty.ai/openapi.json, https://docs.requesty.ai/swagger.json, https://docs.requesty.…”
                                proof ↗⚑ flag

                              Compatibility

                              1. developerPoint existing OpenAI-compatible code at the gateway by changing only the base URL and key

                                weight 3 · round to Portkey
                                Portkeyfullclaimed9/10

                                Docs explicitly state that developers using OpenAI's Python/Node SDKs can integrate Portkey by only changing the base URL and adding Portkey-specific headers, with the base URL documented as https://api.portkey.ai/v1. This is a first-party documented, purpose-built migration path. Missing for 10: independent/hands-on third-party confirmation beyond vendor docs.

                                • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey’s features into your existing setup.”
                                • [claimed-docs] “The base URL for all REST API requests is `https://api.portkey.ai/v1`”
                                • [claimed-docs] “Ideal for: if you’re currently utilizing OpenAI’s Python or Node.js SDKs. By changing the base URL and adding Portkey-specific headers, you …”
                                • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey's features into your existing setup.”
                                proof ↗⚑ flag
                                Requestyfullprobed8/10

                                Docs explicitly show swapping only base_url (to router.requesty.ai/v1) and API key while keeping OpenAI SDK unchanged, directly matching the story. Missing for 10: independent/hands-on third-party confirmation beyond vendor docs and a formal OpenAPI spec (probe found 404s).

                                • [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
                                • [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
                                • [probe] “PROBE llms.txt: HTTP 200 at https://docs.requesty.ai/llms.txt # Requesty > Requesty is a unified LLM gateway and OpenAI-compatible API for …”
                                proof ↗⚑ flag

                              One endpoint

                              1. developerCall many model providers through one consistent API

                                weight 3 · round to Portkey
                                Portkeyfullclaimed9/10

                                Portkey documents a unified API/gateway (single base URL, single API key) that supports 250+ providers/models via consistent SDK/REST calls, with virtual keys and model catalog abstracting provider differences. Missing for 10: independent third-party benchmark or hands-on confirmation of the claimed 250+ provider coverage beyond vendor docs.

                                • [claimed-docs] “The core concept remains the same - one Portkey API key gives you access to multiple providers and models.”
                                • [claimed-docs] “By changing the base URL and adding Portkey-specific headers, you can quickly integrate Portkey’s features into your existing setup.”
                                • [claimed-docs] “The base URL for all REST API requests is `https://api.portkey.ai/v1`”
                                • [claimed-docs] “It serves as a unified interface for interacting with over 250 AI models, offering advanced tools for control, visibility, and security in y…”
                                • [claimed-docs] “Add a provider, then use `@provider-slug/model-name` in your code.”
                                • [claimed-docs] “Ideal for: if you’re currently utilizing OpenAI’s Python or Node.js SDKs. By changing the base URL and adding Portkey-specific headers, you …”
                                proof ↗⚑ flag
                                Requestyfullprobed8/10

                                Requesty is explicitly documented as an OpenAI-compatible unified API/gateway supporting 300+ (or 600+) models via a single base_url swap, with routing, fallback, load balancing, and BYOK across providers, all first-party documented and corroborated by an llms.txt probe describing it as a unified LLM gateway. Missing for 10: independent/hands-on third-party verification beyond docs, and no public OpenAPI spec found (404s on probe).

                                • [claimed-docs] “If you're already using the OpenAI SDK, point it at Requesty and you're done. No SDK changes, no new client to learn.”
                                • [claimed-docs] “base_url="https://router.requesty.ai/v1", # was: https://api.openai.com/v1”
                                • [claimed-docs] “Bring Your Own Keys (BYOK) allows you to use your personal API keys from various providers with Requesty.”
                                • [claimed-docs] “Access 600+ models through one API with intelligent routing, real-time analytics and centralized governance.”
                                • [probe] “PROBE llms.txt: HTTP 200 at https://docs.requesty.ai/llms.txt # Requesty > Requesty is a unified LLM gateway and OpenAI-compatible API for …”
                                proof ↗⚑ flag

                              Not comparable on these axes

                              1. ai-native userSet up automations that run autonomously in the background

                                weight 2 · not comparable
                                Portkeyn/a

                                Portkey is an AI gateway/observability layer for routing, caching, and governing LLM requests, not a workflow/automation platform for running autonomous background tasks; the evidence covers gateway features (fallbacks, retries, caching, load balancing, logs, budgets) with no scheduler or autonomous-agent execution capability. This story targets a different product category and does not fit Portkey's axis.

                                  ⚑ flag
                                  Requestyn/a

                                  Requesty is an LLM gateway/router product for API traffic management (routing, fallback, load balancing, caching), not an automation or agent-orchestration platform; there is no concept of user-defined background-running autonomous automations in this product category.

                                    ⚑ flag

                                  • ai-native userDelegate tasks to a built-in AI assistant inside the product

                                    weight 3 · not comparable
                                    Portkeyn/a

                                    Portkey is an AI gateway/observability platform for routing and managing LLM traffic, not a product with a built-in chat/assistant UI that a user delegates tasks to; this axis is a category error for its product type.

                                      ⚑ flag
                                      Requestyn/a

                                      Requesty is an LLM routing/gateway product (unified API, fallback, load balancing, caching, analytics) rather than an end-user product with a built-in AI assistant persona to delegate tasks to; this axis is a category error for its type.

                                        ⚑ flag

                                      • ai-native userOperate the product with natural-language commands

                                        weight 2 · not comparable
                                        Portkeynone0/10

                                        Portkey's evidence describes an API/SDK-based AI gateway, dashboard configs, logs, and MCP server connectivity for tools/data sources, but nothing shows an interface where a user issues natural-language commands to operate Portkey itself (e.g., a chat-based admin/control plane). The axis is plausible for a platform like this, but no evidence supports it.

                                          ⚑ flag
                                          Requestyn/a

                                          Requesty is an LLM routing/gateway API product configured via SDKs, config files, and a dashboard, not an interactive assistant meant to be operated via natural-language commands; this axis is a category mismatch for an infrastructure/API product.

                                            ⚑ flag

                                          • ai-native userTest against a sandbox environment without touching production data

                                            weight 1 · not comparable
                                            Portkeynone0/10

                                            Portkey's evidence covers gateway routing, fallbacks, caching, logging, and gradual/canary rollout of models in production, but there is no mention of a distinct sandbox/staging environment or test mode that isolates a user from production data. The axis is fair for a gateway/dev-tool product, but no evidence supports it.

                                              ⚑ flag
                                              Requestyn/a

                                              Requesty is an LLM routing/gateway product for production API traffic, not a sandboxed testing/data environment; the sandbox-vs-production-data story is a category error for this kind of product.

                                                ⚑ flag

                                              • ai-native userSchedule recurring jobs or workflows

                                                weight 2 · not comparable
                                                Portkeyn/a

                                                Portkey is an AI gateway/observability platform for routing, caching, and monitoring LLM requests, not a workflow/job scheduling or orchestration product; nothing in the evidence pack relates to scheduling recurring jobs or workflows, making this a category mismatch rather than a missing feature.

                                                  ⚑ flag
                                                  Requestyn/a

                                                  Requesty is an LLM routing/gateway API, not a workflow orchestration or job-scheduling product; scheduling recurring jobs is outside its category's scope.

                                                    ⚑ flag

                                                  • ai-native userVersion, review, and roll back my automations

                                                    weight 1 · not comparable
                                                    Portkeynone0/10

                                                    Portkey's evidence covers gateway configs, logs, retries, caching, and budgets, but nothing describes versioning, review workflows, or rollback of automations/configs — the closest hint is 'Config ID' filtering in logs, which is not version control. Missing for 10: any documentation of config/version history, diff/review process, or rollback mechanism for automations.

                                                    • [claimed-docs] “Filter logs by `Config ID` to see all requests using that config”
                                                    • [claimed-docs] “The Logs section presents a chronological list of all the requests processed through Portkey.”
                                                    • [claimed-docs] “Each log on Portkey has a unique URL. You can copy the link from the address bar and directly share it with anyone in your org.”
                                                    proof ↗⚑ flag
                                                    Requestyn/a

                                                    Requesty is an LLM gateway/router product, not an automation-building tool with workflows to version, review, or roll back; this story is a category error for its product type.

                                                      ⚑ flag