Together AI vs DeepInfra

Agent access

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

   weight 2 · round to Together AI
   Together AI✓fullprobed9/10

   Together AI publishes a working llms.txt (HTTP 200) with a documentation index, per-page .md docs, and even a live MCP server for docs lookup, all independently confirmed via probes plus first-party docs on agent-skills. missing for 10: no independent third-party report of an agent actually consuming llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.together.ai/llms.txt # Together AI docs > Documentation for the Together AI platform for inference…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.together.ai/intro.md > ## Documentation Index > Fetch the complete documentation index at: https://d…”
   • [probe] “PROBE mcp-endpoint (2026-09-04): POST initialize to https://docs.together.ai/mcp answered HTTP 200 with a JSON-RPC/MCP response (event: mess…”
   • [claimed-docs] “Make your AI coding agent Together-AI-aware with ready-made skills for code generation and an MCP server for live docs lookup.”
   • [claimed-docs] “Docs MCP server: Gives your agent live access to this documentation site so it can look up current information without leaving your editor.”

   proof ↗⚑ flag

   DeepInfra—none0/10

   Direct probes show llms.txt, docs.md, and openapi.json all return 404 on deepinfra.com, and no evidence pack item claims an agent-oriented docs format exists; the only machine-readable endpoint found is the models list, not documentation.

   • [probe] “PROBE llms.txt: HTTP 404 at https://deepinfra.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://deepinfra.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://deepinfra.com/openapi.json, https://deepinfra.com/swagger.json, https://deepinfra.com/api/op…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Together AI✓fullprobed7/10

   Together AI is an API/SDK-first inference platform with OpenAI-compatible REST endpoints, official server-side SDKs (TypeScript/Python), batch inference, streaming via SSE, and structured/function-calling outputs — all natively usable in headless CI/automation pipelines without any UI dependency. Live probes confirm the API and status endpoints are reachable programmatically. missing for 10: no explicit CI/CD example or GitHub Actions template in evidence, no documented CLI exit-code/scripting conventions, and no independent case study of a CI pipeline using Together AI headlessly.

   • [claimed-docs] “you can point it at models hosted on Together with two changes: the API key and base URL”
   • [claimed-docs] “Call 100+ open-source models with per-token pricing and no provisioning latency.”
   • [claimed-docs] “Run asynchronous batch workloads at up to 50% lower cost.”
   • [github] “We provide support for streaming responses using Server Sent Events (SSE).”
   • [github] “This library provides convenient access to the Together REST API from server-side TypeScript or JavaScript.”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.together.xyz/v1/models without a key returned HTTP 401 (Missing API key) — the OpenAI-st…”
   • [claimed-docs] “Call chat, image, audio, embedding, and more through one API.”

   proof ↗⚑ flag

   DeepInfra✓fullprobed7/10

   DeepInfra is a REST/OpenAI-compatible API (base_url + api_key model, keyless model enumeration) that is inherently scriptable and stateless, making it straightforward to call from CI/automation pipelines without any UI dependency. missing for 10: no explicit CI/CD examples (GitHub Actions, cron jobs), no official CLI, and no independent hands-on report of someone running it headlessly in a pipeline.

   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: 1. Set `base_url` to `https://api.deepinfra.com/v1/openai` 2. Set `api_…”
   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: Set base_url to https://api.deepinfra.com/v1/openai”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.deepinfra.com/v1/openai/models with NO API key returned HTTP 200 with a machine-readable…”
   • [claimed-docs] “You only pay per token — no idle GPU time, no minimums, no seat fees.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Together AI—none0/10

   The evidence only shows Together AI publishing its own MCP server (docs lookup) for coding agents to consume — i.e., Together acting as an MCP *server*, not as a client that lets users plug external MCP servers into it. There's no documentation or probe showing Together's platform/API can connect to and use tools from user-supplied MCP servers, despite having function/tool-calling APIs. missing for 10: any evidence of MCP-client support (configuring/connecting external MCP servers within Together's product), integration of MCP tool results into its agentic function-calling flow.

   • [claimed-docs] “Make your AI coding agent Together-AI-aware with ready-made skills for code generation and an MCP server for live docs lookup.”
   • [claimed-docs] “12 domain-specific skills that load on demand and teach your agent how to write correct Together AI code (right model IDs, SDK patterns, bes…”
   • [claimed-docs] “Gives your agent live access to this documentation site so it can look up current information without leaving your editor.”
   • [claimed-docs] “Docs MCP server: Gives your agent live access to this documentation site so it can look up current information without leaving your editor.”
   • [probe] “official MCP server documented at https://docs.together.ai/docs/agent-skills”
   • [probe] “PROBE mcp-endpoint (2026-09-04): POST initialize to https://docs.together.ai/mcp answered HTTP 200 with a JSON-RPC/MCP response (event: mess…”
   • [claimed-docs] “To build agent loops, chain tool calls inside one response (multi-step), and conversations that thread tools across many turns (multi-turn).”
   • [claimed-docs] “Multi-step function calling chains sequential function calls within one conversation turn.”

   proof ↗⚑ flag

   DeepInfra—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

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

   weight 3 · round to Together AI
   Together AI✓fullprobed8/10

   Together AI documents an official Docs MCP server that gives agents live access to documentation, and a live probe confirms the MCP endpoint at docs.together.ai/mcp responds correctly to an initialize call with proper protocol capabilities. This is corroborated by both first-party docs and independent hands-on verification. Missing for 10: broader coverage beyond docs lookup (e.g., an MCP server exposing inference/model-management actions rather than just documentation retrieval), and no community discussion confirming real-world agent integration experiences.

   • [claimed-docs] “Make your AI coding agent Together-AI-aware with ready-made skills for code generation and an MCP server for live docs lookup.”
   • [claimed-docs] “12 domain-specific skills that load on demand and teach your agent how to write correct Together AI code (right model IDs, SDK patterns, bes…”
   • [claimed-docs] “Gives your agent live access to this documentation site so it can look up current information without leaving your editor.”
   • [claimed-docs] “Docs MCP server: Gives your agent live access to this documentation site so it can look up current information without leaving your editor.”
   • [probe] “official MCP server documented at https://docs.together.ai/docs/agent-skills”
   • [probe] “PROBE mcp-endpoint (2026-09-04): POST initialize to https://docs.together.ai/mcp answered HTTP 200 with a JSON-RPC/MCP response (event: mess…”

   proof ↗⚑ flag

   DeepInfra—none0/10

   DeepInfra is an inference API/platform (not an agent), so an official MCP server is a fair axis to expect, but no evidence in the pack mentions MCP support at all—only OpenAI-compatible REST API docs.

   ⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Together AI
   Together AI~partialclaimed5/10

   Docs mention an official CLI (the 'tg' command, e.g. 'tg beta endpoints deploy...') and explicitly state fine-tuning jobs can be launched 'through the API/SDK, or with the CLI', confirming a real CLI exists for agentic/dev workflows. However, evidence lacks a dedicated CLI reference page, install instructions, full command coverage, or independent hands-on corroboration. Missing for 10: dedicated CLI documentation/installation guide, comprehensive command reference, independent user verification of CLI usage.

   • [claimed-docs] “tg beta endpoints deploy google/gemma-4-E4B-it --endpoint my-endpoint”
   • [claimed-docs] “You can launch a fine-tuning job from the console, through the API/SDK, or with the CLI”

   proof ↗⚑ flag

   DeepInfra—none0/10

   No evidence of an official DeepInfra CLI tool; docs focus on REST/OpenAI-SDK compatibility, and probes for docs/openapi/llms.txt turned up nothing about a CLI. DeepInfra is an inference API/cloud platform, so an official CLI is a plausible and fair capability to ask about, but none is evidenced.

   • [claimed-docs] “Point your existing OpenAI SDK to `https://api.deepinfra.com/v1/openai` and your code works without changes. No migration required.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://deepinfra.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://deepinfra.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://deepinfra.com/openapi.json, https://deepinfra.com/swagger.json, https://deepinfra.com/api/op…”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round to Together AI
   Together AI✓fullprobed9/10

   Together AI exposes an OpenAI-compatible REST API with official SDKs (TypeScript/JS), documented endpoints for chat, batch, fine-tuning, dedicated deployment, and a live, publicly reachable models endpoint confirmed by probe; docs are extensive and public. Missing for 10: a discoverable formal OpenAPI/swagger spec (probe found all candidate paths 404).

   • [claimed-docs] “you can point it at models hosted on Together with two changes: the API key and base URL”
   • [claimed-docs] “Call 100+ open-source models with per-token pricing and no provisioning latency.”
   • [github] “This library provides convenient access to the Together REST API from server-side TypeScript or JavaScript.”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.together.xyz/v1/models without a key returned HTTP 401 (Missing API key) — the OpenAI-st…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.together.ai/openapi.json, https://docs.together.ai/swagger.json, https://docs.together.…”

   proof ↗⚑ flag

   DeepInfra✓fullprobed8/10

   DeepInfra publishes extensive documentation for a fully OpenAI-compatible REST API (chat completions, embeddings, vision, image/video, speech, service tiers, reasoning_effort, fail_fast, etc.), confirmed live via a keyless probe that enumerated 189 models through the documented endpoint. Missing for 10: no discoverable OpenAPI/swagger spec or llms.txt for machine-readable agent consumption (all returned 404), so an AI agent must rely on human-oriented docs rather than a formal machine spec.

   • [claimed-docs] “Point your existing OpenAI SDK to `https://api.deepinfra.com/v1/openai` and your code works without changes. No migration required.”
   • [claimed-docs] “OpenAI-compatible chat completions API — just change the base URL and model name.”
   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: 1. Set `base_url` to `https://api.deepinfra.com/v1/openai` 2. Set `api_…”
   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: Set base_url to https://api.deepinfra.com/v1/openai”
   • [claimed-docs] “Set service_tier to "priority" to request priority inference on supported models. Priority requests get faster time-to-first-token and highe…”
   • [claimed-docs] “Set service_tier to "flex" to run Chat Completions requests at a lower cost in exchange for slower response times and occasional resource un…”
   • [claimed-docs] “Set the optional fail_fast parameter to true to get an immediate HTTP 429 instead of waiting.”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.deepinfra.com/v1/openai/models with NO API key returned HTTP 200 with a machine-readable…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://deepinfra.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://deepinfra.com/openapi.json, https://deepinfra.com/swagger.json, https://deepinfra.com/api/op…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Together AI—none0/10

   No evidence of scoped or least-privilege API key issuance (e.g., per-project keys, role/permission scoping, or restricted-scope tokens for agents); docs only mention a single API key used for authentication, with no mention of scoping controls.

   • [claimed-docs] “you can point it at models hosted on Together with two changes: the API key and base URL”

   proof ↗⚑ flag

   DeepInfra—none0/10

   No evidence of scoped or least-privilege API key/credential management (e.g., per-agent tokens, permission scoping, role-based keys) — only a single generic API token model is implied via base_url/api_key usage. Missing for 10: any docs on creating multiple scoped keys, permission/role restrictions, credential expiration, or per-agent token issuance.

   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: 1. Set `base_url` to `https://api.deepinfra.com/v1/openai` 2. Set `api_…”
   • [claimed-docs] “Drop-in OpenAI replacement. Point your existing OpenAI SDK to https://api.deepinfra.com/v1/openai and your code works without changes.”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Together AI✓fullclaimed8/10

   Together AI provides an official TypeScript/JavaScript SDK (github repo) and OpenAI-compatible API/SDK usage, with docs covering chat, structured outputs, function calling, streaming, fine-tuning, and dedicated deployment all launchable via API/SDK. This directly supports AI-native, agentic development against official SDKs, including agent loop patterns and tool calling. Missing for 10: independent hands-on developer reviews specifically praising SDK quality/completeness, and no official Python SDK repo cited in evidence pack.

   • [github] “We provide support for streaming responses using Server Sent Events (SSE).”
   • [github] “This library provides convenient access to the Together REST API from server-side TypeScript or JavaScript.”
   • [claimed-docs] “you can point it at models hosted on Together with two changes: the API key and base URL”
   • [claimed-docs] “Function calling (also called tool calling) lets LLMs respond with structured function names and arguments that you can execute in your appl…”
   • [claimed-docs] “To build agent loops, chain tool calls inside one response (multi-step), and conversations that thread tools across many turns (multi-turn).”
   • [claimed-docs] “You can launch a fine-tuning job from the console, through the API/SDK, or with the CLI”
   • [claimed-docs] “Supported models can return JSON that conforms to any schema you supply, so you can read the output directly in code without retries or frag…”

   proof ↗⚑ flag

   DeepInfra✓fullprobed8/10

   DeepInfra explicitly documents OpenAI SDK compatibility as a drop-in replacement (just change base_url, api_key, model) with no code migration required, and a live probe confirms the OpenAI-compatible endpoint is functional and enumerable. This directly satisfies building against an official/well-known SDK ecosystem rather than a bespoke library. missing for 10: no dedicated first-party DeepInfra-branded SDK packages mentioned (relies on OpenAI SDK compatibility), and no independent third-party developer corroboration beyond docs and endpoint probes.

   • [claimed-docs] “Point your existing OpenAI SDK to `https://api.deepinfra.com/v1/openai` and your code works without changes. No migration required.”
   • [claimed-docs] “Point your existing OpenAI SDK to https://api.deepinfra.com/v1/openai and your code works without changes. No migration required.”
   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: 1. Set `base_url` to `https://api.deepinfra.com/v1/openai` 2. Set `api_…”
   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: Set base_url to https://api.deepinfra.com/v1/openai”
   • [claimed-docs] “Drop-in OpenAI replacement. Point your existing OpenAI SDK to https://api.deepinfra.com/v1/openai and your code works without changes.”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.deepinfra.com/v1/openai/models with NO API key returned HTTP 200 with a machine-readable…”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Together AI—none0/10

   No evidence of webhook subscription support anywhere in the docs, SDKs, or probes; Together AI offers SSE streaming and a docs MCP server, but nothing about webhook event subscriptions for async notifications (e.g., fine-tune job completion, batch job status).

   ⚑ flag

   DeepInfra—none0/10

   No evidence of any webhook subscription or event-notification mechanism anywhere in the docs; DeepInfra is a request/response inference API with no mention of async event callbacks.

   ⚑ flag

Agentic features

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

   weight 2 · round drawn
   Together AI—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   DeepInfra—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

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

   weight 3 · round drawn
   Together AI—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   DeepInfra—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

3. ai-native userOperate the product with natural-language commands

   weight 2 · round drawn
   Together AI—none0/10

   Together AI is an inference/training API platform operated via REST API, SDKs, CLI, and console — the evidence shows structured commands (API calls, CLI syntax like 'tg beta endpoints deploy...') rather than any natural-language command interface for operating the platform itself. The agent-skills/MCP docs only help external coding agents write correct Together AI code, not let a user operate Together AI's own product surface via natural language.

   ⚑ flag

   DeepInfra—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Api quality

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

   weight 2 · round drawn
   Together AI—none0/10

   The evidence pack shows extensive prose documentation (guides, overview pages) but no reference to an interactive API reference or runnable/try-it-now code examples; a direct probe for OpenAPI/Swagger specs at standard paths returned 404 for all candidates, indicating no interactive spec-driven reference was found. No community or hands-on evidence confirms a runnable API console exists.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.together.ai/openapi.json, https://docs.together.ai/swagger.json, https://docs.together.…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.together.ai/llms.txt # Together AI docs > Documentation for the Together AI platform for inference…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.together.ai/intro.md > ## Documentation Index > Fetch the complete documentation index at: https://d…”

   proof ↗⚑ flag

   DeepInfra—none0/10

   The docs pack shows static code snippets (e.g., OpenAI SDK base_url examples) but no evidence of an interactive, runnable API console or playground; probes for openapi.json/swagger.json all returned 404, and no llms.txt/docs.md machine-readable spec exists, indicating no interactive reference is exposed.

   • [probe] “PROBE llms.txt: HTTP 404 at https://deepinfra.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://deepinfra.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://deepinfra.com/openapi.json, https://deepinfra.com/swagger.json, https://deepinfra.com/api/op…”
   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: 1. Set `base_url` to `https://api.deepinfra.com/v1/openai` 2. Set `api_…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Together AI—none0/10

   Active probing for standard OpenAPI/swagger spec locations (openapi.json, swagger.json, etc.) all returned 404, and no docs page in the pack references a downloadable OpenAPI/machine-readable spec for the Together API.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.together.ai/openapi.json, https://docs.together.ai/swagger.json, https://docs.together.…”

   proof ↗⚑ flag

   DeepInfra—none0/10

   Direct probes for llms.txt, docs.md, and common OpenAPI/swagger spec paths all returned 404, indicating no machine-readable API spec is published; the docs only describe OpenAI SDK compatibility, not a downloadable OpenAPI/JSON schema.

   • [probe] “PROBE llms.txt: HTTP 404 at https://deepinfra.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://deepinfra.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://deepinfra.com/openapi.json, https://deepinfra.com/swagger.json, https://deepinfra.com/api/op…”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Together AI—none0/10

   No evidence of a dedicated sandbox/staging environment; the only related mention is a test account with trial credit on the same production API, not an isolated sandbox for testing without touching production data.

   • [community] “the price is pretty low... 4B MODEL, PRICE 1K TOKENS: $0.0001. register with an email, test account has $25 credit, python API as well, good…”

   proof ↗⚑ flag

   DeepInfra—none0/10

   The evidence pack describes DeepInfra as a pay-per-token inference API with zero data retention, private dedicated deployments, and GPU clusters, but there is no mention of a distinct sandbox/test environment, test API keys, or any mechanism to separate test traffic from production data — instead it just uses live API keys against production endpoints. missing for 10: sandbox/test environment or mode, staging API keys, documented separation between test and production data flows.

   • [claimed-docs] “Need to run your own fine-tuned weights, or require data isolation? Deploy a dedicated instance on A100/H100/H200/B200/B300 with autoscaling…”
   • [claimed-docs] “With our zero retention policy your inputs, your outputs, and your user data stay private. DeepInfra is SOC 2 and ISO 27001 certified.”
   • [claimed-docs] “You only pay per token — no idle GPU time, no minimums, no seat fees.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Together AI—none0/10

   The evidence shows a documented, OpenAI-compatible REST API (with a /v1/ endpoint) but contains no mention of a versioning scheme or a documented deprecation policy for API changes. Absence of evidence for this applicable capability means it cannot be credited as delivered.

   ⚑ flag

   DeepInfra—none0/10

   The evidence pack shows OpenAI-compatible endpoints and a model catalog but contains no documentation of API versioning scheme, changelog, or deprecation/sunset policy for models or endpoints; probes even show missing openapi/spec files (404s), reinforcing the absence of such formal API-lifecycle documentation.

   • [probe] “PROBE docs-md: HTTP 404 at https://deepinfra.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://deepinfra.com/openapi.json, https://deepinfra.com/swagger.json, https://deepinfra.com/api/op…”
   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: 1. Set `base_url` to `https://api.deepinfra.com/v1/openai` 2. Set `api_…”

   proof ↗⚑ flag

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

   weight 2 · round to Together AI
   Together AI✓fullclaimed7/10

   Together AI offers an asynchronous Batch API explicitly designed for bulk workloads across many items at once, at up to 50% lower cost than synchronous calls, alongside dedicated endpoints and fine-tuning pipelines that can process large datasets end-to-end. missing for 10: no documented batch size/throughput limits, no independent/hands-on report validating batch job behavior at scale, and no detail on input format flexibility for large item counts.

   • [claimed-docs] “Run asynchronous batch workloads at up to 50% lower cost.”
   • [claimed-docs] “Together AI handles the full lifecycle: data upload, training, hosting, and inference on a dedicated endpoint.”
   • [claimed-docs] “Fine-tuning tailors a pretrained model to a smaller, targeted dataset so it performs better on a specific task or domain. Together AI handle…”

   proof ↗⚑ flag

   DeepInfra—none0/10

   The docs mention a 'flex' pricing tier suited to asynchronous, non-production workloads like data enrichment and model evaluations, but there is no documented batch API, bulk upload endpoint, or mechanism to submit and process many items in a single call — only single-request chat/completions semantics are described.

   • [claimed-docs] “It’s ideal for non-production or lower-priority tasks such as model evaluations, data enrichment, and asynchronous workloads.”
   • [claimed-docs] “Set service_tier to "flex" to run Chat Completions requests at a lower cost in exchange for slower response times and occasional resource un…”

   proof ↗⚑ flag

Batch

1. ml-engineerSubmit asynchronous batch inference jobs at a documented discount versus real-time pricing

   weight 2 · round to Together AI
   Together AI✓fullclaimed8/10

   Together AI has documented batch inference at up to 50% lower cost than real-time serverless pricing, directly matching the story's requirement for asynchronous jobs at a documented discount [together-ai-docs-3]. missing for 10: independent/hands-on corroboration of actual batch job submission and discount realization beyond the docs page, and more detail on submission workflow/API specifics.

   • [claimed-docs] “Run asynchronous batch workloads at up to 50% lower cost.”

   proof ↗⚑ flag

   DeepInfra~partialclaimed4/10

   DeepInfra documents a 'flex' service_tier that gives a 20% discount versus standard pricing and is explicitly recommended for 'asynchronous workloads' and lower-priority tasks, which partially matches the story's intent of discounted async processing. However, this is a request-level QoS flag on the standard synchronous chat API, not a true batch-job system (no file upload, job submission ID, or polling/webhook completion pattern like OpenAI's Batch API). Missing for 10: a documented batch-job submission endpoint (upload/queue a set of prompts, get a job ID, poll or receive callback), explicit SLA/turnaround time for batch jobs, and independent confirmation of the discount and workflow in practice.

   • [claimed-docs] “It’s ideal for non-production or lower-priority tasks such as model evaluations, data enrichment, and asynchronous workloads.”
   • [claimed-docs] “Flex inference is billed at a 20% discount off the model's standard per-token price.”
   • [claimed-docs] “Set service_tier to "flex" to run Chat Completions requests at a lower cost in exchange for slower response times and occasional resource un…”

   proof ↗⚑ flag

Dedicated

1. ml-engineerDeploy a model on dedicated GPU capacity with autoscaling so my traffic is isolated from the shared serverless pool

   weight 2 · round to Together AI
   Together AI✓fullclaimed8/10

   Docs explicitly describe Dedicated Model Inference (DMI) for serving models on reserved/isolated hardware distinct from the shared serverless pool, with no hard rate limits, and a dedicated scaling doc showing configurable autoscaling via replica limits, plus deployment of fine-tuned or custom models via CLI. This directly matches the story's requirements of dedicated GPU capacity, autoscaling, and isolation from shared serverless traffic. Missing for 10: independent/hands-on verification of autoscaling behavior in production and concrete GPU-type/SLA details beyond docs.

   • [claimed-docs] “Dedicated model inference (DMI) lets you serve a model on reserved hardware, providing several advantages over serverless models”
   • [claimed-docs] “Configure your deployment to scale automatically by setting limits on how many replicas it can run.”
   • [claimed-docs] “Fine-tuned models: Deploy a model you fine-tuned from a supported base model.”
   • [claimed-docs] “tg beta endpoints deploy google/gemma-4-E4B-it --endpoint my-endpoint”
   • [claimed-docs] “Dedicated model inference (DMI) lets you serve a model on reserved hardware... Better performance... No hard rate limits”

   proof ↗⚑ flag

   DeepInfra✓fullclaimed7/10

   DeepInfra docs explicitly offer dedicated instance deployment on A100/H100/H200/B200/B300 GPUs with autoscaling and a private endpoint for data isolation, directly matching the story's request for isolated, dedicated capacity separate from the shared serverless pool. missing for 10: independent/hands-on confirmation of autoscaling behavior under load, SLA/isolation guarantees, and pricing/latency benchmarks for dedicated vs shared tiers.

   • [claimed-docs] “Run your own fine-tuned LLM on A100 / H100 / H200 / B200 / B300 with autoscaling.”
   • [claimed-docs] “Need to run your own fine-tuned weights, or require data isolation? Deploy a dedicated instance on A100/H100/H200/B200/B300 with autoscaling…”
   • [claimed-docs] “Deploy Private Models Run your own fine-tuned LLM on A100 / H100 / H200 / B200 / B300 with autoscaling.”

   proof ↗⚑ flag

Fine tune

1. ml-engineerFine-tune a supported base model on my own data and serve the result on the same platform

   weight 2 · round to Together AI
   Together AI✓fullclaimed9/10

   Docs clearly describe fine-tuning (LoRA or full) on supported base models via console/API/CLI, with Together AI handling the full lifecycle including data upload, training, hosting, and inference on a dedicated endpoint, and dedicated endpoints explicitly support deploying fine-tuned models. This is a first-party documented end-to-end workflow with concrete CLI examples. Missing for 10: independent/hands-on confirmation from a third party that a fine-tune-then-serve workflow works as described.

   • [claimed-docs] “Fine-tune models on your own data and deploy them for inference.”
   • [claimed-docs] “LoRA: Trains a small set of adapter weights on top of the frozen base model... Full fine-tuning: Updates every weight in the base model.”
   • [claimed-docs] “You can launch a fine-tuning job from the console, through the API/SDK, or with the CLI”
   • [claimed-docs] “Fine-tuned models: Deploy a model you fine-tuned from a supported base model.”
   • [claimed-docs] “Together AI handles the full lifecycle: data upload, training, hosting, and inference on a dedicated endpoint.”
   • [claimed-docs] “Fine-tuning tailors a pretrained model to a smaller, targeted dataset so it performs better on a specific task or domain. Together AI handle…”

   proof ↗⚑ flag

   DeepInfra~partialclaimed4/10

   DeepInfra documents deploying your own fine-tuned weights for serving (docs-8/9/18) and separately offers GPU clusters with SSH for training (docs-10), so the pieces to fine-tune-then-serve exist, but there is no evidence of an integrated managed fine-tuning job/dataset-upload API on a supported base model — customers must train themselves on rented GPUs and then manually deploy the resulting weights as a private endpoint. Missing for 10: a first-party fine-tuning job service (upload dataset, select base model, launch job) that outputs directly into the serving catalog, and any hands-on/community confirmation of this end-to-end flow.

   • [claimed-docs] “Run your own fine-tuned LLM on A100 / H100 / H200 / B200 / B300 with autoscaling.”
   • [claimed-docs] “Need to run your own fine-tuned weights, or require data isolation? Deploy a dedicated instance on A100/H100/H200/B200/B300 with autoscaling…”
   • [claimed-docs] “GPU Clusters for training and full control. Rent a B200 or B300 cluster with SSH access and run whatever you want.”
   • [claimed-docs] “Deploy Private Models Run your own fine-tuned LLM on A100 / H100 / H200 / B200 / B300 with autoscaling.”

   proof ↗⚑ flag

2. ml-engineerUpload and serve my own custom model weights or LoRA adapters

   weight 2 · round to Together AI
   Together AI~partialclaimed7/10

   Together AI's docs clearly support fine-tuning (LoRA or full) and deploying the resulting fine-tuned models to dedicated inference endpoints, covering the LoRA-adapter serving use case end-to-end (data upload, training, hosting, inference). However, there's no evidence of uploading externally-trained/custom weights not produced via Together's own fine-tuning pipeline (e.g., bringing your own checkpoint from another framework). missing for 10: evidence of uploading externally-trained custom weights/checkpoints (not produced by Together's fine-tuning), and independent/hands-on confirmation of this workflow.

   • [claimed-docs] “LoRA: Trains a small set of adapter weights on top of the frozen base model... Full fine-tuning: Updates every weight in the base model.”
   • [claimed-docs] “Fine-tuned models: Deploy a model you fine-tuned from a supported base model.”
   • [claimed-docs] “Together AI handles the full lifecycle: data upload, training, hosting, and inference on a dedicated endpoint.”
   • [claimed-docs] “Fine-tuning tailors a pretrained model to a smaller, targeted dataset so it performs better on a specific task or domain. Together AI handle…”
   • [claimed-docs] “You can launch a fine-tuning job from the console, through the API/SDK, or with the CLI”

   proof ↗⚑ flag

   DeepInfra~partialclaimed6/10

   DeepInfra documents deploying custom fine-tuned LLM weights on dedicated GPU instances (A100/H100/H200/B200/B300) with autoscaling and private endpoints, directly addressing the 'serve my own custom model weights' part of the story. However, there is no explicit mention of LoRA adapter upload/serving specifically, nor details on the upload workflow, supported formats, or independent/hands-on confirmation that this works as claimed. Missing for 10: LoRA adapter support specifics, upload/serving workflow documentation, independent verification of custom weight deployment.

   • [claimed-docs] “Run your own fine-tuned LLM on A100 / H100 / H200 / B200 / B300 with autoscaling.”
   • [claimed-docs] “Need to run your own fine-tuned weights, or require data isolation? Deploy a dedicated instance on A100/H100/H200/B200/B300 with autoscaling…”
   • [claimed-docs] “Deploy Private Models Run your own fine-tuned LLM on A100 / H100 / H200 / B200 / B300 with autoscaling.”

   proof ↗⚑ flag

Catalog

1. ml-engineerGet newly released open-weight models on the platform quickly after their public release

   weight 2 · round drawn
   Together AI—none0/10

   The evidence pack shows Together AI hosts 100+ open-source models and supports fine-tuning/dedicated deployment, but there is no evidence—first-party or independent—about the speed or process of adding newly released open-weight models to the catalog. missing for 10: any documentation or community report on time-to-availability for new model releases, changelog/release-notes evidence, or comparison of catalog freshness versus competitors.

   ⚑ flag

   DeepInfra—none0/10

   The evidence pack shows a broad model catalog (189 models) and general inference features, but nothing documents DeepInfra's speed in adding newly released open-weight models after public release — no changelog, launch-day availability claims, or timing data are present.

   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.deepinfra.com/v1/openai/models with NO API key returned HTTP 200 with a machine-readable…”

   proof ↗⚑ flag

2. developerRely on a documented deprecation policy with advance notice before a hosted model is removed

   weight 1 · round drawn
   Together AI—none0/10

   No evidence in the pack mentions a deprecation policy, sunset schedule, or advance-notice commitment for retiring hosted models; docs cover serverless/dedicated inference, fine-tuning, and agent tooling but nothing about model lifecycle/deprecation notices.

   ⚑ flag

   DeepInfra—none0/10

   No evidence pack item mentions a deprecation policy, sunset notice period, or advance notice process for removing hosted models; the docs cover API usage, pricing, and infrastructure but nothing about model lifecycle/removal policy.

   ⚑ flag

3. ai-native userHave an agent enumerate the live model catalog programmatically via a documented GET /v1/models-style endpoint

   weight 2 · round drawn
   Together AI✓fullprobed8/10

   Together AI exposes an OpenAI-compatible /v1/models endpoint confirmed live via probe (returns 401 without key, meaning it exists and speaks JSON, per together-ai-probe-rt-1), and docs confirm OpenAI-compatibility for base URL/API key swaps (together-ai-docs-1) enabling programmatic catalog enumeration. missing for 10: a dedicated docs page explicitly documenting the /v1/models endpoint schema/response format, and independent hands-on confirmation of a successful authenticated call listing the full catalog.

   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.together.xyz/v1/models without a key returned HTTP 401 (Missing API key) — the OpenAI-st…”
   • [claimed-docs] “you can point it at models hosted on Together with two changes: the API key and base URL”

   proof ↗⚑ flag

   DeepInfra✓fullprobed8/10

   A live probe confirms GET https://api.deepinfra.com/v1/openai/models returns HTTP 200 with a machine-readable list of 189 models, and DeepInfra's docs establish that its API is a documented OpenAI-compatible drop-in (same base_url, same client libraries), which conventionally includes the /v1/models listing endpoint. Missing for 10: a dedicated docs page explicitly describing the /v1/models endpoint schema/parameters rather than relying on general OpenAI-compatibility claims.

   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.deepinfra.com/v1/openai/models with NO API key returned HTTP 200 with a machine-readable…”
   • [claimed-docs] “Point your existing OpenAI SDK to https://api.deepinfra.com/v1/openai and your code works without changes. No migration required.”
   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: 1. Set `base_url` to `https://api.deepinfra.com/v1/openai` 2. Set `api_…”
   • [claimed-docs] “OpenAI-compatible chat completions API — just change the base URL and model name.”

   proof ↗⚑ flag

4. developerChoose among a broad catalog of current open-weight model families (Llama, Qwen, DeepSeek, GPT-OSS and peers) on shared serverless endpoints

   weight 3 · round to Together AI
   Together AI✓fullprobed7/10

   Docs confirm serverless endpoints serving '100+ open-source models' with per-token pricing, no provisioning latency, and OpenAI-compatible API for easy model switching, and community evidence corroborates real-world use of Llama-family models on the platform. However, the evidence pack never explicitly enumerates Qwen, DeepSeek, or GPT-OSS by name, so full breadth across all cited model families isn't directly confirmed. Missing for 10: explicit documentation naming Qwen/DeepSeek/GPT-OSS as catalog entries, and independent verification of catalog breadth beyond the generic '100+ models' claim.

   • [claimed-docs] “Call 100+ open-source models with per-token pricing and no provisioning latency.”
   • [claimed-docs] “you can point it at models hosted on Together with two changes: the API key and base URL”
   • [claimed-docs] “you can prototype on serverless and move to reserved hardware later without changing your application code”
   • [community] “Colleague and I were discussing need for a service like this. Their pricing is much cheaper than self-hosting Llama-2-70B on AWS ($20.36/hr)…”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.together.xyz/v1/models without a key returned HTTP 401 (Missing API key) — the OpenAI-st…”

   proof ↗⚑ flag

   DeepInfra~partialprobed7/10

   DeepInfra's docs confirm an OpenAI-compatible shared serverless endpoint where you 'set model to a model from our catalog,' and a live probe confirms 189 models are enumerable via the API without cold-start dedicated deployment. However, the evidence pack never explicitly names or confirms coverage of Llama, Qwen, DeepSeek, or GPT-OSS specifically as catalog entries. Missing for 10: explicit documentation or listing naming these specific model families as available, and independent commentary on catalog breadth/freshness beyond the raw count.

   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: 1. Set `base_url` to `https://api.deepinfra.com/v1/openai` 2. Set `api_…”
   • [claimed-docs] “DeepInfra is an AI inference cloud that makes it simple to run the latest machine learning models at scale — LLMs, vision, embeddings, image…”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.deepinfra.com/v1/openai/models with NO API key returned HTTP 200 with a machine-readable…”

   proof ↗⚑ flag

Modalities

1. developerGenerate embeddings (and rerank results) for retrieval pipelines without a second vendor

   weight 1 · round to DeepInfra
   Together AI~partialclaimed5/10

   Docs confirm a unified API that includes embeddings alongside chat/image/audio (together-ai-docs-21), supporting retrieval pipelines without a separate embeddings vendor. However, no evidence in the pack documents a dedicated rerank endpoint or reranking models, so the reranking half of the story is unsupported. Missing for 10: dedicated rerank API/model documentation, embeddings model list/dimensions, and independent confirmation of embeddings quality/usage in RAG pipelines.

   • [claimed-docs] “Call chat, image, audio, embedding, and more through one API.”

   proof ↗⚑ flag

   DeepInfra✓fullclaimed8/10

   DeepInfra explicitly offers embeddings and reranking models via an OpenAI-compatible API alongside LLMs, letting developers build retrieval pipelines on one vendor. Missing for 10: independent hands-on validation of embedding/rerank endpoints, benchmark quality comparisons, and detailed API-parameter docs for these specific endpoints.

   • [claimed-docs] “Embeddings & Reranking State-of-the-art embedding and reranker models for search and RAG.”
   • [claimed-docs] “DeepInfra is an AI inference cloud that makes it simple to run the latest machine learning models at scale — LLMs, vision, embeddings, image…”
   • [claimed-docs] “Point your existing OpenAI SDK to `https://api.deepinfra.com/v1/openai` and your code works without changes. No migration required.”

   proof ↗⚑ flag

2. developerCall vision, audio, or image-generation models beyond text chat on the same platform

   weight 1 · round drawn
   Together AI✓fullclaimed8/10

   Together AI's docs explicitly state you can 'Call chat, image, audio, embedding, and more through one API' on the serverless platform, indicating multimodal model support beyond text chat on the same platform [together-ai-docs-21]. This is corroborated by the broader serverless/dedicated inference docs describing a unified API/base URL approach [together-ai-docs-1, together-ai-docs-2]. Missing for 10: no independent hands-on report or example code specifically calling vision/audio/image-generation endpoints, and no detailed model list confirming breadth of non-text modalities.

   • [claimed-docs] “Call chat, image, audio, embedding, and more through one API.”
   • [claimed-docs] “Call 100+ open-source models with per-token pricing and no provisioning latency.”
   • [claimed-docs] “you can point it at models hosted on Together with two changes: the API key and base URL”

   proof ↗⚑ flag

   DeepInfra✓fullclaimed8/10

   Docs explicitly list Vision & OCR, Speech (Whisper/TTS), and Image & Video generation (FLUX, Stable Diffusion, text-to-video) as first-class model categories alongside chat, all accessible via the same OpenAI-compatible API/platform. Missing for 10: independent hands-on confirmation of calling these non-text endpoints and more detail on request/response formats for each modality.

   • [claimed-docs] “DeepInfra is an AI inference cloud that makes it simple to run the latest machine learning models at scale — LLMs, vision, embeddings, image…”
   • [claimed-docs] “FLUX, Stable Diffusion, text-to-video, and more.”
   • [claimed-docs] “Embeddings & Reranking State-of-the-art embedding and reranker models for search and RAG.”
   • [claimed-docs] “Image & Video Generation FLUX, Stable Diffusion, text-to-video, and more.”
   • [claimed-docs] “Speech recognition (Whisper) and text-to-speech models.”
   • [claimed-docs] “Vision & OCR Multimodal models for visual understanding and document text extraction.”

   proof ↗⚑ flag

Compat

1. ai-native userPlug the provider into coding agents and agent frameworks through documented, first-party integration guides

   weight 2 · round to Together AI
   Together AI✓fullprobed9/10

   Together AI documents first-party agent-skills and an MCP server specifically for coding agent integration (docs-agent-skills, docs-12/19/20/24/29/30), confirmed live via probe (probe-4, probe-rt-3), plus OpenAI-compatible base URL swap for framework compatibility (docs-1) and function/tool-calling docs for agentic workflows (docs-8/9). Missing for 10: independent hands-on reports specifically validating the agent-skills/MCP integration with popular frameworks like LangChain or Claude Code.

   • [claimed-docs] “you can point it at models hosted on Together with two changes: the API key and base URL”
   • [claimed-docs] “Make your AI coding agent Together-AI-aware with ready-made skills for code generation and an MCP server for live docs lookup.”
   • [claimed-docs] “12 domain-specific skills that load on demand and teach your agent how to write correct Together AI code (right model IDs, SDK patterns, bes…”
   • [claimed-docs] “Gives your agent live access to this documentation site so it can look up current information without leaving your editor.”
   • [claimed-docs] “Docs MCP server: Gives your agent live access to this documentation site so it can look up current information without leaving your editor.”
   • [claimed-docs] “Function calling (also called tool calling) lets LLMs respond with structured function names and arguments that you can execute in your appl…”
   • [claimed-docs] “To build agent loops, chain tool calls inside one response (multi-step), and conversations that thread tools across many turns (multi-turn).”
   • [probe] “official MCP server documented at https://docs.together.ai/docs/agent-skills”
   • [probe] “PROBE mcp-endpoint (2026-09-04): POST initialize to https://docs.together.ai/mcp answered HTTP 200 with a JSON-RPC/MCP response (event: mess…”

   proof ↗⚑ flag

   DeepInfra~partialprobed5/10

   DeepInfra documents a drop-in OpenAI-compatible endpoint (base_url swap, same SDK, model catalog) which is the mechanism most coding agents/agent frameworks rely on to add a custom provider, and a live probe confirms the OpenAI-style /models endpoint works keylessly. However, the evidence pack contains no first-party guide naming or walking through integration with any specific coding agent or agent framework (e.g., LangChain, LlamaIndex, Cursor, Continue) — only generic 'point your OpenAI SDK here' instructions. missing for 10: named integration guides for specific coding agents/agent frameworks, third-party/community confirmation of successful agent hookups.

   • [claimed-docs] “Point your existing OpenAI SDK to `https://api.deepinfra.com/v1/openai` and your code works without changes. No migration required.”
   • [claimed-docs] “OpenAI-compatible chat completions API — just change the base URL and model name.”
   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: 1. Set `base_url` to `https://api.deepinfra.com/v1/openai` 2. Set `api_…”
   • [claimed-docs] “Drop-in OpenAI replacement. Point your existing OpenAI SDK to https://api.deepinfra.com/v1/openai and your code works without changes.”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.deepinfra.com/v1/openai/models with NO API key returned HTTP 200 with a machine-readable…”

   proof ↗⚑ flag

2. ai-native userHave an agent switch to or away from this provider mid-workflow because it speaks the standard chat-completions API without provider-specific code changes

   weight 3 · round to DeepInfra
   Together AI✓fullprobed8/10

   Docs explicitly state OpenAI-compatibility requires only changing API key and base URL, meaning agents/tools written against the standard chat-completions API can point at Together with no provider-specific code changes; the live /v1/models endpoint confirms OpenAI-style REST shape. This directly supports switching to/away from Together mid-workflow with minimal friction. Missing for 10: independent third-party confirmation of drop-in swap behavior (e.g., a framework's changelog showing zero-code-change provider swap) and explicit mention of streaming/tool-call parity with OpenAI's spec beyond docs.

   • [claimed-docs] “you can point it at models hosted on Together with two changes: the API key and base URL”
   • [claimed-docs] “you can prototype on serverless and move to reserved hardware later without changing your application code”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.together.xyz/v1/models without a key returned HTTP 401 (Missing API key) — the OpenAI-st…”

   proof ↗⚑ flag

   DeepInfra✓fullprobed9/10

   DeepInfra explicitly documents a drop-in OpenAI-compatible endpoint requiring only base_url/api_key/model changes, and a live probe confirms the OpenAI-compatible models endpoint is reachable and functional, supporting agents switching providers without provider-specific code. Missing for 10: independent third-party (non-vendor) confirmation of seamless mid-workflow agent switching in practice.

   • [claimed-docs] “Point your existing OpenAI SDK to `https://api.deepinfra.com/v1/openai` and your code works without changes. No migration required.”
   • [claimed-docs] “Point your existing OpenAI SDK to https://api.deepinfra.com/v1/openai and your code works without changes. No migration required.”
   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: 1. Set `base_url` to `https://api.deepinfra.com/v1/openai` 2. Set `api_…”
   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: Set base_url to https://api.deepinfra.com/v1/openai”
   • [claimed-docs] “Drop-in OpenAI replacement. Point your existing OpenAI SDK to https://api.deepinfra.com/v1/openai and your code works without changes.”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.deepinfra.com/v1/openai/models with NO API key returned HTTP 200 with a machine-readable…”

   proof ↗⚑ flag

3. developerPoint an existing OpenAI SDK client at the provider by changing only the base URL and API key

   weight 3 · round to DeepInfra
   Together AI✓fullprobed8/10

   Docs explicitly state you can point an existing client at Together by changing only the API key and base URL, and the API is OpenAI-compatible with a live /v1/models endpoint confirmed via probe. missing for 10: independent developer testimonial specifically confirming drop-in OpenAI SDK compatibility (community evidence covers pricing/UX but not this specific mechanic), and no explicit code snippet shown in evidence.

   • [claimed-docs] “you can point it at models hosted on Together with two changes: the API key and base URL”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.together.xyz/v1/models without a key returned HTTP 401 (Missing API key) — the OpenAI-st…”
   • [claimed-docs] “you can prototype on serverless and move to reserved hardware later without changing your application code”

   proof ↗⚑ flag

   DeepInfra✓fullprobed9/10

   Documentation explicitly and repeatedly states developers only need to change base_url and api_key to point an existing OpenAI SDK at DeepInfra, with a live probe confirming the OpenAI-compatible endpoint is functional and reachable. Missing for 10: independent third-party hands-on confirmation of a full SDK migration beyond docs and a keyless probe.

   • [claimed-docs] “Point your existing OpenAI SDK to `https://api.deepinfra.com/v1/openai` and your code works without changes. No migration required.”
   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: 1. Set `base_url` to `https://api.deepinfra.com/v1/openai` 2. Set `api_…”
   • [claimed-docs] “Drop-in OpenAI replacement. Point your existing OpenAI SDK to https://api.deepinfra.com/v1/openai and your code works without changes.”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.deepinfra.com/v1/openai/models with NO API key returned HTTP 200 with a machine-readable…”

   proof ↗⚑ flag

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

   weight 2 · round to Together AI
   Together AI~partialprobed7/10

   Docs show broad API/CLI/SDK coverage mirroring UI actions—fine-tuning can be launched 'from the console, through the API/SDK, or with the CLI', dedicated endpoints can be deployed via CLI (tg beta endpoints deploy), and inference, batch, and cluster provisioning are all API-accessible—suggesting strong UI/API parity for core workflows. However, there's no explicit documentation enumerating full parity (e.g., billing, account/org management, usage dashboards) or confirming every UI-only feature has an API equivalent, and no OpenAPI spec was found (probe shows all openapi.json paths 404), making completeness hard to verify. Missing for 10: an explicit parity statement or API coverage for account/billing/admin functions, and a published OpenAPI spec confirming full API surface.

   • [claimed-docs] “You can launch a fine-tuning job from the console, through the API/SDK, or with the CLI”
   • [claimed-docs] “tg beta endpoints deploy google/gemma-4-E4B-it --endpoint my-endpoint”
   • [claimed-docs] “Together AI handles the full lifecycle: data upload, training, hosting, and inference on a dedicated endpoint.”
   • [claimed-docs] “Spin up H100 and B200 clusters with attached storage for training or large batch jobs.”
   • [claimed-docs] “Run asynchronous batch workloads at up to 50% lower cost.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.together.ai/openapi.json, https://docs.together.ai/swagger.json, https://docs.together.…”

   proof ↗⚑ flag

   DeepInfra~partialprobed6/10

   DeepInfra's docs show broad API coverage matching most UI-facing capabilities: chat/completions, embeddings, vision/OCR, speech, image/video generation, private model deployment, and GPU clusters are all exposed via API endpoints, and the models endpoint is even queryable keylessly. However, there's no explicit statement of full UI/API parity, no OpenAPI/swagger spec was found (probes returned 404s), and no evidence covers account/billing/dashboard-management actions being API-accessible. missing for 10: explicit parity documentation, a discoverable OpenAPI schema, and evidence that account/billing/UI-console actions are also API-controllable.

   • [claimed-docs] “OpenAI-compatible chat completions API — just change the base URL and model name.”
   • [claimed-docs] “Run your own fine-tuned LLM on A100 / H100 / H200 / B200 / B300 with autoscaling.”
   • [claimed-docs] “Need to run your own fine-tuned weights, or require data isolation? Deploy a dedicated instance on A100/H100/H200/B200/B300 with autoscaling…”
   • [claimed-docs] “GPU Clusters for training and full control. Rent a B200 or B300 cluster with SSH access and run whatever you want.”
   • [claimed-docs] “Embeddings & Reranking State-of-the-art embedding and reranker models for search and RAG.”
   • [claimed-docs] “Image & Video Generation FLUX, Stable Diffusion, text-to-video, and more.”
   • [claimed-docs] “Speech recognition (Whisper) and text-to-speech models.”
   • [claimed-docs] “Vision & OCR Multimodal models for visual understanding and document text extraction.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://deepinfra.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://deepinfra.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://deepinfra.com/openapi.json, https://deepinfra.com/swagger.json, https://deepinfra.com/api/op…”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.deepinfra.com/v1/openai/models with NO API key returned HTTP 200 with a machine-readable…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Together AI—none0/10

   The evidence pack covers inference, fine-tuning, dedicated endpoints, and agent tooling, but contains no mention of a data export feature, downloadable account data, or a documented way to retrieve fine-tuning datasets/model weights in open formats and leave the platform. This is a fair question for a hosted AI platform that stores prompts, fine-tuning data, and trained models, so absence of evidence means 'none' rather than 'na'.

   ⚑ flag

   DeepInfra—none0/10

   DeepInfra's evidence pack focuses entirely on its OpenAI-compatible inference API, model catalog, and infrastructure offerings; there is no mention of any user data export feature, open-format data portability, or account data download capability. Given the zero-retention policy, DeepInfra does not appear to store persistent user data, but no evidence at all addresses export tooling for whatever account/usage data does exist.

   • [claimed-docs] “With our zero retention policy your inputs, your outputs, and your user data stay private. DeepInfra is SOC 2 and ISO 27001 certified.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Together AI—none0/10

   The evidence pack covers Together AI's hosted inference, fine-tuning, and dedicated endpoint features, and its client SDKs (e.g., together-typescript) are open on GitHub, but there is no evidence that Together AI's core platform/product source is released under an open license—only that it serves open-source models to customers.

   ⚑ flag

   DeepInfra—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Limits

1. developerRead documented rate limits and how they scale across usage tiers before I hit them in production

   weight 2 · round to Together AI
   Together AI~partialclaimed6/10

   Together AI documents a rate-limit model explicitly (docs-14): dynamic per-organization, per-model limits based on live model capacity and recent successful usage, and notes dedicated endpoints have no hard rate limits (docs-31). This gives developers some visibility into how limits work before hitting them, but there's no documented tiered structure (e.g., spend-based tiers with specific numeric thresholds) showing how limits scale as usage/spend grows over time. Missing for 10: explicit usage-tier table or thresholds, numeric rate-limit values per tier, guidance on how to request/track tier upgrades.

   • [claimed-docs] “Together uses dynamic rate limits instead of fixed thresholds. Each organization has a dynamic rate per model that adjusts based on: The mod…”
   • [claimed-docs] “Dedicated model inference (DMI) lets you serve a model on reserved hardware... Better performance... No hard rate limits”

   proof ↗⚑ flag

   DeepInfra—none0/10

   Evidence shows DeepInfra documents a fail_fast parameter to get immediate 429s and priority/flex service tiers for speed vs cost tradeoffs, but there is no documentation of actual rate limit numbers, quotas, or how limits scale across usage/spend tiers. Missing for 10: explicit rate-limit tables, per-tier request/token quotas, and any usage-tier scaling documentation.

   • [claimed-docs] “Set the optional `fail_fast` parameter to `true` to get an immediate HTTP 429 instead of waiting.”
   • [claimed-docs] “Set service_tier to "priority" to request priority inference on supported models. Priority requests get faster time-to-first-token and highe…”
   • [claimed-docs] “Set service_tier to "flex" to run Chat Completions requests at a lower cost in exchange for slower response times and occasional resource un…”
   • [claimed-docs] “Set the optional fail_fast parameter to true to get an immediate HTTP 429 instead of waiting.”

   proof ↗⚑ flag

Pricing

1. founderSet spending caps or budget alerts so a runaway workload cannot generate an unbounded bill

   weight 1 · round drawn
   Together AI—none0/10

   No evidence of spending caps, budget alerts, or usage-based cutoffs; docs mention rate limits (dynamic, based on capacity/usage) and pricing structures but nothing about setting a spend ceiling or receiving alerts to prevent runaway bills.

   ⚑ flag

   DeepInfra—none0/10

   The evidence pack contains no mention of spending caps, budget alerts, usage limits, or billing controls anywhere in DeepInfra's docs or pages; only pay-per-token pricing and service-tier options (priority/flex) are described. This is a fair question for a usage-based API platform, so absence of evidence means 'none' rather than 'na'.

   • [claimed-docs] “You only pay per token — no idle GPU time, no minimums, no seat fees.”
   • [claimed-docs] “Low pay-as-you-go pricing - no long-term contracts, no hidden fees, no surprises.”
   • [claimed-docs] “Low pay-as-you-go pricing - no long-term contracts, no hidden fees, no surprises. Startup? Enterprise? We can scale.”

   proof ↗⚑ flag

2. founderSee public per-token prices for every hosted model without talking to sales

   weight 3 · round to Together AI
   Together AI~partialprobed6/10

   Docs advertise "per-token pricing" for 100+ serverless models and community evidence confirms self-serve signup with visible per-token cost (e.g. "$0.0001/1K tokens", $25 trial credit) with no sales contact required. However, no evidence pack item directly shows a public pricing page enumerating rates for every hosted model, and the live models API requires an API key to enumerate the catalog. Missing for 10: a documented public pricing page/table covering all models, independent confirmation that all model prices (not just examples) are visible pre-signup.

   • [claimed-docs] “Call 100+ open-source models with per-token pricing and no provisioning latency.”
   • [community] “the price is pretty low... 4B MODEL, PRICE 1K TOKENS: $0.0001. register with an email, test account has $25 credit, python API as well, good…”
   • [community] “I've explored most of the inference as a service platforms, theirs is particularly nice. (Clear/simple UI, good pricing, good speed.)”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.together.xyz/v1/models without a key returned HTTP 401 (Missing API key) — the OpenAI-st…”

   proof ↗⚑ flag

   DeepInfra~partialprobed5/10

   Docs repeatedly state pay-as-you-go, per-token pricing with no contracts or sales required (docs-12, docs-16, docs-24, docs-31), strongly implying self-serve access to prices, and the model catalog is enumerable via a keyless API (deepinfra-probe-rt-1). However, no evidence pack item shows an actual public price list or per-model $/token table a founder could browse. missing for 10: explicit citation of a pricing page or API field listing per-token prices for each hosted model, independent confirmation that prices are visible without account/sales contact.

   • [claimed-docs] “You only pay per token — no idle GPU time, no minimums, no seat fees.”
   • [claimed-docs] “Flex inference is billed at a 20% discount off the model's standard per-token price.”
   • [claimed-docs] “Low pay-as-you-go pricing - no long-term contracts, no hidden fees, no surprises.”
   • [claimed-docs] “Low pay-as-you-go pricing - no long-term contracts, no hidden fees, no surprises. Startup? Enterprise? We can scale.”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.deepinfra.com/v1/openai/models with NO API key returned HTTP 200 with a machine-readable…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Together AI—none0/10

   No evidence in the pack mentions data residency, regional storage options, or geographic control over where data/models are hosted; only privacy policy criticism unrelated to residency is present. Missing for 10: any documentation of region selection, data residency guarantees, or geo-specific hosting options.

   ⚑ flag

   DeepInfra—none0/10

   No evidence of region selection or data residency controls; only zero-retention/SOC2/ISO27001 privacy claims are mentioned, with no mention of choosing storage region or geographic data residency options.

   ⚑ flag

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

   weight 3 · round to DeepInfra
   Together AI—none0/10

   No first-party documentation describes an opt-out, data-retention control, or 'no training on your data' policy; the only relevant evidence is a community report describing Together AI's privacy policy as broad/vague, allowing data use 'for other purposes,' which points toward the opposite of a training-opt-out guarantee.

   • [community] “Together AI's privacy policy collects broad personal data including prompts, IP addresses, and contact info, with vague language allowing us…”
   • [community] “Colleague and I were discussing need for a service like this. Their pricing is much cheaper than self-hosting Llama-2-70B on AWS ($20.36/hr)…”

   proof ↗⚑ flag

   DeepInfra✓fullclaimed8/10

   DeepInfra explicitly states a zero data retention policy covering inputs, outputs, and user data, backed by SOC 2 and ISO 27001 certifications, directly addressing the no-training-data-use concern. Missing for 10: independent/third-party audit confirmation or explicit contractual opt-out language beyond the marketing statement.

   • [claimed-docs] “With our zero retention policy your inputs, your outputs, and your user data stay private. DeepInfra is SOC 2 and ISO 27001 certified.”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to DeepInfra
   Together AI—none0/10

   No evidence pack item documents user-facing data retention or deletion controls (e.g., API/dashboard settings to delete stored prompts or data). The only relevant community evidence (together-ai-comm-1) actually raises concerns that Together AI's privacy policy allows broad data collection with vague retention/usage language, which is the opposite of demonstrating retention/deletion controls.

   • [community] “Together AI's privacy policy collects broad personal data including prompts, IP addresses, and contact info, with vague language allowing us…”

   proof ↗⚑ flag

   DeepInfra~partialclaimed5/10

   DeepInfra states a 'zero retention policy' for inputs/outputs/user data and cites SOC 2 and ISO 27001 certification, implying strong default privacy posture, but there is no documented user-facing mechanism to configure retention periods, request deletion of stored data, or verify enforcement of the zero-retention claim. missing for 10: explicit data-deletion/retention-control API or settings, independent audit/verification of the zero-retention claim, and documentation of what data (if any) is logged/retained by default.

   • [claimed-docs] “With our zero retention policy your inputs, your outputs, and your user data stay private. DeepInfra is SOC 2 and ISO 27001 certified.”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Together AI—none0/10

   No documentation or feature reference describes a telemetry/usage-tracking opt-out mechanism; the only related evidence is a community critique noting Together AI's privacy policy broadly collects prompts, IPs, and contact info with vague 'other purposes' language and no opt-out mentioned, reinforcing the absence of this capability.

   • [community] “Together AI's privacy policy collects broad personal data including prompts, IP addresses, and contact info, with vague language allowing us…”
   • [community] “Colleague and I were discussing need for a service like this. Their pricing is much cheaper than self-hosting Llama-2-70B on AWS ($20.36/hr)…”

   proof ↗⚑ flag

   DeepInfra—none0/10

   The evidence pack describes a zero-retention data policy and SOC2/ISO27001 certification, but this addresses data retention rather than a specific telemetry/usage-tracking opt-out control; no docs mention any setting, header, or account option to disable telemetry or usage analytics.

   ⚑ flag

Reliability

1. founderGet a stated availability SLA on paid or enterprise tiers

   weight 1 · round drawn
   Together AI—none0/10

   Evidence shows a public status page and various product docs, but nothing states an actual uptime/availability SLA percentage or enterprise contractual guarantee. Absence of evidence for this applicable capability yields none.

   • [probe] “PROBE status-page (2026-09-04): https://status.together.ai returns HTTP 200 and renders a public service-status page (page body includes "op…”

   proof ↗⚑ flag

   DeepInfra—none0/10

   The evidence pack includes pricing, features, and a public status page, but nowhere states an uptime/availability SLA percentage or enterprise contractual guarantee — no mention of SLA terms for paid or enterprise tiers.

   • [probe] “PROBE status-page (2026-09-04): https://status.deepinfra.com returns HTTP 200 and renders a public service-status page (page body includes "…”
   • [claimed-docs] “Low pay-as-you-go pricing - no long-term contracts, no hidden fees, no surprises. Startup? Enterprise? We can scale.”
   • [claimed-docs] “Low pay-as-you-go pricing - no long-term contracts, no hidden fees, no surprises.”

   proof ↗⚑ flag

2. founderCheck a public status page with incident history before betting production traffic on the platform

   weight 2 · round to Together AI
   Together AI✓fullprobed8/10

   A live public status page at status.together.ai returns HTTP 200 and shows service status ('operational'), confirming a real status dashboard exists that a founder could check before committing production traffic. Missing for 10: no evidence of detailed incident history/postmortems or uptime SLA history visible in the pack, so depth of incident history can't be fully confirmed.

   • [probe] “PROBE status-page (2026-09-04): https://status.together.ai returns HTTP 200 and renders a public service-status page (page body includes "op…”

   proof ↗⚑ flag

   DeepInfra~partialprobed6/10

   A probe confirms DeepInfra runs a public status page (status.deepinfra.com) that returns HTTP 200 and displays operational status, which a founder could check before committing production traffic. However, the evidence does not show an incident-history log, uptime SLA, or past-incident detail on that page, so the story is only partially confirmed. Missing for 10: evidence of incident history/timeline, uptime percentage stats, or independent commentary on past outages.

   • [probe] “PROBE status-page (2026-09-04): https://status.deepinfra.com returns HTTP 200 and renders a public service-status page (page body includes "…”

   proof ↗⚑ flag

Benchmarks

1. ml-engineerSee published tokens-per-second or latency numbers, benchmarks, or load-testing guides backing the provider's speed claims

   weight 2 · round drawn
   Together AI—none0/10

   The evidence pack contains only vague qualitative claims ('no provisioning latency', 'Better performance' for dedicated endpoints) and subjective community remarks ('good speed') but no published tokens-per-second figures, latency benchmarks, or load-testing methodology/guides that would let an ml-engineer verify speed claims.

   • [claimed-docs] “Call 100+ open-source models with per-token pricing and no provisioning latency.”
   • [claimed-docs] “Dedicated model inference (DMI) lets you serve a model on reserved hardware... Better performance... No hard rate limits”
   • [community] “I've explored most of the inference as a service platforms, theirs is particularly nice. (Clear/simple UI, good pricing, good speed.)”

   proof ↗⚑ flag

   DeepInfra—none0/10

   The evidence describes qualitative service tiers (priority/flex) that claim to affect speed, and one anecdotal HN comment about cold-start latency, but there are no published tokens-per-second figures, latency benchmarks, or load-testing guides substantiating DeepInfra's speed claims.

   • [claimed-docs] “Priority requests get faster time-to-first-token and higher throughput during peak demand.”
   • [claimed-docs] “Set service_tier to "priority" to request priority inference on supported models. Priority requests get faster time-to-first-token and highe…”
   • [claimed-docs] “Set service_tier to "flex" to run Chat Completions requests at a lower cost in exchange for slower response times and occasional resource un…”
   • [community] “Because this is popular model and many people use it, you will not experience the cold-start latency most likely. But in general it is <10s.”

   proof ↗⚑ flag

Serving

1. developerServe latency-sensitive workloads with fast time-to-first-token and high-throughput generation

   weight 3 · round to DeepInfra
   Together AI!disputedcontradicted5/10

   Together AI's docs claim strong speed characteristics — 'no provisioning latency' for serverless, DMI offering 'better performance' and 'no hard rate limits', dynamic rate limits based on live capacity, streaming SSE support, and automatic prompt caching to speed repeated prefills — all directly supporting fast TTFT and high throughput [together-ai-docs-2][together-ai-docs-31][together-ai-docs-14][together-ai-gh-1][together-ai-docs-13]. However, an independent hands-on comparison explicitly disputes this, stating Together AI was 'at the bottom of the pile' for large-scale deployment speed/pricing versus competitors like Cerebras, DeepInfra, and Hyperbolic [together-ai-comm-5], while another community post gives a positive but vaguer 'good speed' impression [together-ai-comm-4] — a genuine mixed/contradicted signal rather than mere skepticism. Missing for 10: independent benchmarks (TTFT/tokens-per-second numbers) confirming or refuting the vendor's latency claims, and resolution of the conflicting community reports.

   • [claimed-docs] “Call 100+ open-source models with per-token pricing and no provisioning latency.”
   • [claimed-docs] “Dedicated model inference (DMI) lets you serve a model on reserved hardware... Better performance... No hard rate limits”
   • [claimed-docs] “Together uses dynamic rate limits instead of fixed thresholds. Each organization has a dynamic rate per model that adjusts based on: The mod…”
   • [claimed-docs] “Automatic: There is no header, parameter, or account toggle to enable it. Send the same prompt prefix again and any portion that's still war…”
   • [github] “We provide support for streaming responses using Server Sent Events (SSE).”
   • [community] “I've explored most of the inference as a service platforms, theirs is particularly nice. (Clear/simple UI, good pricing, good speed.)”
   • [community] “'Together AI has quickly grown into the leading hosting platform for AI' - Lol. Definitely not. I went through pricing and large scale deplo…”

   proof ↗⚑ flag

   DeepInfra✓fullcommunity8/10

   DeepInfra provides explicit priority service tier for faster time-to-first-token and higher throughput during peak demand (docs-4, docs-26), plus fail_fast for latency-sensitive workflows and a flex tier tradeoff, showing deliberate latency/throughput controls. Community evidence corroborates generally low cold-start latency (<10s) for popular models. Missing for 10: independent benchmark data on actual TTFT/throughput numbers and hands-on comparison to competitors.

   • [claimed-docs] “Priority requests get faster time-to-first-token and higher throughput during peak demand.”
   • [claimed-docs] “Set service_tier to "priority" to request priority inference on supported models. Priority requests get faster time-to-first-token and highe…”
   • [claimed-docs] “Set service_tier to "flex" to run Chat Completions requests at a lower cost in exchange for slower response times and occasional resource un…”
   • [claimed-docs] “Set the optional `fail_fast` parameter to `true` to get an immediate HTTP 429 instead of waiting.”
   • [community] “Because this is popular model and many people use it, you will not experience the cold-start latency most likely. But in general it is <10s.”

   proof ↗⚑ flag

2. ml-engineerBenefit from prompt/prefix caching that reduces latency or cost on repeated context

   weight 1 · round to Together AI
   Together AI✓fullclaimed8/10

   Together AI documents automatic prompt/prefix caching for serverless chat models, explicitly stating cached input tokens are billed at a steep discount with no toggle needed, directly reducing cost on repeated context. missing for 10: independent/hands-on benchmark confirming latency reduction, and clarity on which models/latency gains apply beyond the cost-discount framing.

   • [claimed-docs] “Automatic: There is no header, parameter, or account toggle to enable it. Send the same prompt prefix again and any portion that's still war…”
   • [claimed-docs] “Send the same prompt prefix again and any portion that's still warm in the shared cache is billed at the cached rate.”
   • [claimed-docs] “Select serverless chat models bill cached input tokens at a steep discount... Automatic: There is no header, parameter, or account toggle to…”

   proof ↗⚑ flag

   DeepInfra—none0/10

   The evidence pack contains no mention of prompt caching, prefix caching, or any context-reuse feature that reduces latency/cost on repeated prompts; it only covers OpenAI-compatible API basics, priority/flex service tiers, and dedicated deployments, none of which address caching of repeated context.

   ⚑ flag

3. developerStream completions token by token over SSE for responsive user experiences

   weight 3 · round to Together AI
   Together AI✓fullclaimed8/10

   Together AI's SDKs explicitly document SSE-based streaming support ('We provide support for streaming responses using Server Sent Events (SSE)'), and the API is OpenAI-compatible, implying standard streaming chat completion endpoints. Missing for 10: no independent hands-on latency benchmark or explicit token-by-token example snippet in the evidence pack.

   • [github] “We provide support for streaming responses using Server Sent Events (SSE).”
   • [github] “This library provides convenient access to the Together REST API from server-side TypeScript or JavaScript.”
   • [claimed-docs] “you can point it at models hosted on Together with two changes: the API key and base URL”

   proof ↗⚑ flag

   DeepInfra~partialclaimed4/10

   DeepInfra positions itself as a drop-in OpenAI-compatible API (same SDK, same code), which implies standard OpenAI SDK features like `stream=True` token-by-token SSE would work unchanged, but no evidence pack item explicitly documents or demonstrates streaming responses, SSE format, or token-by-token behavior. Missing for 10: explicit streaming/SSE documentation or examples, benchmarks on streaming latency, and independent confirmation that stream=True works as expected.

   • [claimed-docs] “Point your existing OpenAI SDK to `https://api.deepinfra.com/v1/openai` and your code works without changes. No migration required.”
   • [claimed-docs] “The only changes you need to make from your existing OpenAI code: 1. Set `base_url` to `https://api.deepinfra.com/v1/openai` 2. Set `api_…”
   • [claimed-docs] “Drop-in OpenAI replacement. Point your existing OpenAI SDK to https://api.deepinfra.com/v1/openai and your code works without changes.”

   proof ↗⚑ flag

Structured

1. developerEnforce structured outputs against a JSON schema (or grammar) so model responses parse reliably

   weight 3 · round to Together AI
   Together AI✓fullclaimed8/10

   Together AI's docs explicitly describe structured outputs where supported models return JSON conforming to a supplied schema, avoiding retries/fragile parsing, alongside function/tool calling and multi-step agentic tool call chaining. This directly matches the story's request for JSON-schema-enforced structured outputs; missing for 10: no independent/hands-on validation of schema-conformance reliability or grammar-based constraints beyond JSON schema.

   • [claimed-docs] “Supported models can return JSON that conforms to any schema you supply, so you can read the output directly in code without retries or frag…”
   • [claimed-docs] “Function calling (also called tool calling) lets LLMs respond with structured function names and arguments that you can execute in your appl…”
   • [claimed-docs] “To build agent loops, chain tool calls inside one response (multi-step), and conversations that thread tools across many turns (multi-turn).”
   • [claimed-docs] “Multi-step function calling chains sequential function calls within one conversation turn.”

   proof ↗⚑ flag

   DeepInfra—none0/10

   The evidence pack details DeepInfra's OpenAI-compatible API, pricing tiers, and model catalog, but contains no mention of JSON schema enforcement, structured output modes, or grammar-constrained decoding. Missing for 10: any documentation of `response_format`/json_schema support, grammar-based constrained generation, or examples showing reliable JSON parsing guarantees.

   ⚑ flag

Tools

1. ai-native userRely on faithful function/tool calling — including parallel and multi-step tool use — so agent loops run on open models without breaking

   weight 3 · round to Together AI
   Together AI~partialclaimed6/10

   Together AI documents native function/tool calling with explicit support for multi-step (chained) and multi-turn agentic tool use, positioned as the foundation for agent loops (together-ai-docs-8,9,15,16). However, there is no independent/hands-on evidence confirming reliability of parallel tool calls or that it avoids breakage across open models in practice — only first-party docs. missing for 10: independent benchmarks or community reports on parallel tool-call accuracy, explicit parallel tool-calling documentation, and hands-on verification that agent loops don't break on open models.

   • [claimed-docs] “Function calling (also called tool calling) lets LLMs respond with structured function names and arguments that you can execute in your appl…”
   • [claimed-docs] “To build agent loops, chain tool calls inside one response (multi-step), and conversations that thread tools across many turns (multi-turn).”
   • [claimed-docs] “Function calling (also called *tool calling*) lets LLMs respond with structured function names and arguments that you can execute in your ap…”
   • [claimed-docs] “Multi-step function calling chains sequential function calls within one conversation turn.”

   proof ↗⚑ flag

   DeepInfra—none0/10

   The evidence pack only shows generic OpenAI-compatible API claims (base URL swap, chat completions) and unrelated features (priority tiers, GPU deployment, image/video models) but never mentions function/tool calling, parallel tool calls, or multi-step agentic tool use, nor any benchmark/community report on tool-calling fidelity. Missing for 10: explicit documentation of a `tools`/`function_call` parameter, evidence of parallel tool call support, and any hands-on or benchmark confirmation that tool calling works reliably in agent loops.

   ⚑ flag