Together AI vs Fireworks AI

Agent access

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

   weight 2 · round drawn
   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

   Fireworks AI✓fullprobed9/10

   Direct probe evidence confirms llms.txt is live at https://docs.fireworks.ai/llms.txt (HTTP 200) with a documentation index, and per-page .md endpoints (e.g. introduction.md) explicitly point agents back to the llms.txt index, making the docs agent-consumable by design. Missing for 10: no independent third-party report of an agent successfully using this to complete a task end-to-end.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.fireworks.ai/llms.txt # Fireworks AI Docs - [Build with Fireworks AI](https://docs.fireworks.ai/ge…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.fireworks.ai/getting-started/introduction.md > ## Documentation Index > Fetch the complete documenta…”

   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

   Fireworks AI✓fullprobed7/10

   Fireworks is API-first (OpenAI-compatible REST endpoint) and ships a CLI (firectl) for scripted deployment/fine-tuning plus async batch-inference for high-volume automated jobs, all of which are naturally usable headlessly in CI pipelines. A live probe confirms the API endpoint is reachable and speaks JSON, requiring just an API key for auth (standard for CI use). Missing for 10: explicit CI/CD pipeline examples (e.g., GitHub Actions integration) and documented non-interactive auth/service-account flows for automated environments.

   • [claimed-docs] “You point your client at `api.fireworks.ai`, send tokens, and pay only for what you use — no GPUs to size, no autoscaler to tune, no cold st…”
   • [claimed-docs] “Process large volumes of requests asynchronously at 50% off Serverless per-token prices.”
   • [claimed-docs] “Process large volumes of requests asynchronously at **50% off** Serverless per-token prices.”
   • [claimed-docs] “Deploy your LoRA trained model with a single command: firectl deployment create "accounts//models/"”
   • [claimed-docs] “Upload from local files or directly from S3 buckets or Azure Blob Storage”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.fireworks.ai/inference/v1/models without a key returned HTTP 401 ({"error":{"message":"Y…”

   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

   Fireworks 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

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

   Fireworks AI—none0/10

   Fireworks AI is an inference/hosting platform with API compatibility, tool-calling, and fine-tuning features, but no evidence anywhere in the pack of an official MCP server for connecting agents. Absence of evidence for this applicable capability means 'none'.

   ⚑ 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

   Fireworks AI~partialclaimed4/10

   Evidence shows an official CLI (`firectl`) used for deployment commands like creating LoRA deployments, confirming Fireworks ships a CLI. However, the evidence pack lacks any dedicated documentation, install guide, or broader command reference showing its scope for AI-native/agentic workflows beyond one example command. missing for 10: install/setup docs, full command reference, independent hands-on usage confirming agentic/automation use cases.

   • [claimed-docs] “Deploy your LoRA trained model with a single command: firectl deployment create "accounts//models/"”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Fireworks AI✓fullprobed9/10

   Fireworks exposes an OpenAI-compatible REST API (chat completions, tool calling, structured outputs, embeddings, batch inference) documented extensively, with a live public endpoint confirmed by probe (api.fireworks.ai returning proper JSON auth errors) and a public status page. missing for 10: no publicly hosted OpenAPI/swagger spec was found (404s on standard paths), slightly reducing machine-readability of the API contract.

   • [claimed-docs] “Drop-in replacement for inference and training — same API, same SFT data format”
   • [claimed-docs] “Tool calling (also known as function calling) enables models to intelligently select and use external tools based on user input.”
   • [claimed-docs] “Force model output to conform to a JSON schema”
   • [claimed-docs] “Fireworks provides fast, cost-effective access to leading open-source text models through OpenAI-compatible APIs.”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.fireworks.ai/inference/v1/models without a key returned HTTP 401 ({"error":{"message":"Y…”
   • [probe] “PROBE status-page (2026-09-04): https://status.fireworks.ai returns HTTP 200 and renders a public service-status page (page body includes "o…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.fireworks.ai/openapi.json, https://docs.fireworks.ai/swagger.json, https://docs.firewor…”

   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

   Fireworks AI—none0/10

   No evidence in the pack of scoped/least-privilege API key management (e.g., role-based keys, permission scoping, per-agent credential issuance) — only general auth requirements are mentioned (401 without a key). Missing for 10: docs on creating scoped/restricted API keys, role-based access control, per-agent credential issuance, and any permission-granularity settings.

   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.fireworks.ai/inference/v1/models without a key returned HTTP 401 ({"error":{"message":"Y…”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to Together AI
   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

   Fireworks AI~partialclaimed5/10

   Fireworks documents an OpenAI-compatible API and CLI (firectl) that let developers reuse existing OpenAI SDKs and tooling, but no evidence in the pack names a dedicated first-party Fireworks Python/JS SDK, its GitHub repo, or client library documentation. missing for 10: explicit official Fireworks SDK docs/repo, language coverage (Python/JS/Go), and independent developer confirmation of SDK usage.

   • [claimed-docs] “Drop-in replacement for inference and training — same API, same SFT data format”
   • [claimed-docs] “Migrate from OpenAI: Drop-in replacement for inference and training — same API, same SFT data format”
   • [claimed-docs] “You point your client at `api.fireworks.ai`, send tokens, and pay only for what you use — no GPUs to size, no autoscaler to tune, no cold st…”
   • [claimed-docs] “Fireworks provides fast, cost-effective access to leading open-source text models through OpenAI-compatible APIs.”

   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

   Fireworks AI—none0/10

   No evidence anywhere in the pack of a webhook subscription mechanism or event notification system for Fireworks AI; the docs focus on inference, fine-tuning, and deployment APIs with no mention of webhooks or event-driven 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

   Fireworks 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

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

   weight 3 · round to Fireworks AI
   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

   Fireworks AI~partialclaimed3/10

   Fireworks' dashboard offers a guided flow where a user 'describes the task, reviews the plan and cost, approves the run' for fine-tuning — a narrow assistant-like feature — but there's no evidence of a general-purpose in-product AI assistant that can be delegated broader tasks across the platform. Missing for 10: evidence of a persistent conversational/agentic assistant embedded in the console, scope beyond fine-tuning setup, and independent corroboration of its capabilities.

   • [claimed-docs] “Get a guided path. Describe the task, review the plan and cost, approve the run, and get a trained model.”

   proof ↗⚑ flag

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

   weight 2 · round to Fireworks AI
   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

   Fireworks AI~partialclaimed3/10

   The only evidence of natural-language operation is a single marketing line about a 'guided path' where you 'describe the task' to kick off fine-tuning — the rest of the product (inference API, deployments, benchmarking, CLI) is operated via code/API/CLI, not NL commands. Missing for 10: documentation of an NL-driven interface for core inference/deployment tasks, any chat-based control plane, or independent corroboration that the 'describe the task' feature works as an agentic NL interface.

   • [claimed-docs] “Get a guided path. Describe the task, review the plan and cost, approve the run, and get a trained model.”

   proof ↗⚑ 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

   Fireworks AI—none0/10

   The evidence pack shows extensive text docs and a reference to an api-reference path, but no evidence of an interactive, runnable-example API reference (e.g., embedded code sandbox, live API console); in fact the OpenAPI/swagger probe returned 404 on all candidate paths, indicating no discoverable interactive spec. Missing for 10: an interactive API explorer, runnable code snippets, or a live OpenAPI/Swagger UI.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.fireworks.ai/openapi.json, https://docs.fireworks.ai/swagger.json, https://docs.firewor…”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.fireworks.ai/inference/v1/models without a key returned HTTP 401 ({"error":{"message":"Y…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.fireworks.ai/llms.txt # Fireworks AI Docs - [Build with Fireworks AI](https://docs.fireworks.ai/ge…”

   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

   Fireworks AI—none0/10

   Direct probes for OpenAPI/swagger spec files at all standard paths returned 404, and no docs page or evidence pack entry links to a downloadable machine-readable API spec; the API is described as 'OpenAI-compatible' but no explicit OpenAPI/Swagger artifact is provided.

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

   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

   Fireworks AI—none0/10

   No evidence of a sandbox/test environment, staging API keys, or any mechanism to test without touching production data/billing; documentation focuses on production inference, fine-tuning, and deployment features only.

   ⚑ 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

   Fireworks AI—none0/10

   No evidence of a versioned API scheme or documented deprecation policy; docs mention OpenAI-compatible API and drop-in replacement but nothing about version numbers, changelogs, or sunset/deprecation timelines. The OpenAPI spec probe even 404'd on all candidate paths, suggesting limited API-versioning documentation. Missing for 10: explicit API versioning scheme, published deprecation/sunset policy, changelog of breaking changes.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.fireworks.ai/openapi.json, https://docs.fireworks.ai/swagger.json, https://docs.firewor…”
   • [claimed-docs] “You point your client at `api.fireworks.ai`, send tokens, and pay only for what you use — no GPUs to size, no autoscaler to tune, no cold st…”
   • [claimed-docs] “Fireworks provides fast, cost-effective access to leading open-source text models through OpenAI-compatible APIs.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Fireworks AI✓fullclaimed7/10

   Fireworks explicitly supports batch inference for processing large volumes of requests asynchronously at discounted rates, which directly enables bulk operations across many items (e.g., bulk generation, classification, embeddings). This is documented as a first-party feature with clear pricing/mechanics, though evidence lacks hands-on validation of batch job semantics (job status, size limits, error handling) or independent corroboration. missing for 10: hands-on/independent verification of batch job workflow, documented size/rate limits, and error-handling behavior for large batch jobs.

   • [claimed-docs] “Process large volumes of requests asynchronously at 50% off Serverless per-token prices.”
   • [claimed-docs] “Process large volumes of requests asynchronously at **50% off** Serverless per-token prices.”

   proof ↗⚑ flag

Batch

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

   weight 2 · round drawn
   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

   Fireworks AI✓fullclaimed8/10

   Fireworks documents a dedicated Batch Inference API that processes requests asynchronously at a documented 50% discount off serverless per-token pricing, directly matching the story. Missing for 10: independent/hands-on confirmation of actual batch job submission and discount realization, and no SLA/turnaround details beyond the discount claim.

   • [claimed-docs] “Process large volumes of requests asynchronously at 50% off Serverless per-token prices.”
   • [claimed-docs] “Process large volumes of requests asynchronously at **50% off** Serverless per-token prices.”

   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 drawn
   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

   Fireworks AI✓fullclaimed8/10

   Fireworks explicitly documents on-demand deployments giving dedicated GPUs isolated from shared serverless traffic, with autoscaling configuration including scale-to-zero and minimum replica settings. Missing for 10: independent hands-on validation of autoscaling behavior under load and explicit SLA/isolation guarantees beyond docs claims (one community comment concerns fine-tuning cost, not dedicated-capacity autoscaling).

   • [claimed-docs] “On-demand deployments give you dedicated GPUs for your models, providing several advantages over serverless: **Better performance**...**No h…”
   • [claimed-docs] “On-demand deployments give you dedicated GPUs for your models, providing several advantages over serverless”
   • [claimed-docs] “Better performance – Lower latency, higher throughput, and predictable performance unaffected by other users”
   • [claimed-docs] “Scale to zero when idle to minimize costs”
   • [claimed-docs] “Set to 0 for scale-to-zero”

   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

   Fireworks AI✓fullclaimed8/10

   Fireworks documents a complete fine-tune-and-serve loop on one platform: SFT/RFT training up to 1T+ params, same API/data format as inference, and LoRA deployment via live-merge or multi-LoRA with a single firectl command, producing a model that serves identically to a natively trained one. Missing for 10: independent/hands-on confirmation of end-to-end fine-tune→serve quality and reliability beyond vendor docs (the only community evidence found addresses cost, not functionality).

   • [claimed-docs] “Boost model quality with supervised and reinforcement fine-tuning of models up to 1T+ parameters.”
   • [claimed-docs] “Boost model quality with supervised and reinforcement fine-tuning of models up to 1T+ parameters. Start training in minutes, deploy immediat…”
   • [claimed-docs] “Live merge is the simplest way to deploy a trained model. Fireworks automatically merges the LoRA weights into the base model at deployment …”
   • [claimed-docs] “Deploy your LoRA trained model with a single command: firectl deployment create "accounts//models/"”
   • [claimed-docs] “Multi-LoRA: Base model is deployed with addon support; LoRA adapters are loaded dynamically at request time”
   • [claimed-docs] “Fireworks supports two deployment methods for LoRA trained models: live merge and multi-LoRA.”
   • [claimed-docs] “Live merge is the simplest way to deploy a trained model. Fireworks automatically merges the LoRA weights into the base model at deployment …”
   • [claimed-docs] “Drop-in replacement for inference and training — same API, same SFT data format”

   proof ↗⚑ flag

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

   weight 2 · round to Fireworks 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

   Fireworks AI✓fullclaimed9/10

   Fireworks docs explicitly cover uploading custom models from Hugging Face/S3/Azure Blob, plus deploying LoRA adapters via live-merge or multi-LoRA with a single firectl command. This directly matches the ml-engineer story of uploading and serving custom weights/adapters. Missing for 10: independent hands-on verification of the upload/serve workflow beyond vendor docs.

   • [claimed-docs] “Upload your own models from Hugging Face or elsewhere to deploy trained or custom-trained models optimized for your use case.”
   • [claimed-docs] “Live merge is the simplest way to deploy a trained model. Fireworks automatically merges the LoRA weights into the base model at deployment …”
   • [claimed-docs] “Deploy your LoRA trained model with a single command: firectl deployment create "accounts//models/"”
   • [claimed-docs] “Multi-LoRA: Base model is deployed with addon support; LoRA adapters are loaded dynamically at request time”
   • [claimed-docs] “Fireworks supports two deployment methods for LoRA trained models: live merge and multi-LoRA.”
   • [claimed-docs] “Upload from local files or directly from S3 buckets or Azure Blob Storage”
   • [claimed-docs] “Live merge is the simplest way to deploy a trained model. Fireworks automatically merges the LoRA weights into the base model at deployment …”

   proof ↗⚑ flag

Catalog

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

   weight 2 · round to Fireworks AI
   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

   Fireworks AI~partialclaimed5/10

   Marketing copy claims 'instant access to the most popular OSS models' and 'run the latest open models with a single line of code' plus '100+ supported models', implying rapid onboarding of new open-weight releases, but there is no concrete evidence (e.g., specific model, release-to-availability timeline, changelog) demonstrating actual speed of adding new models after public release. missing for 10: concrete turnaround-time examples/announcements for specific new open-weight model releases, independent confirmation of day-0/near-day-0 availability, and any changelog or blog evidence of catalog update cadence.

   • [claimed-docs] “Get instant access to the most popular OSS models, optimized for cost, speed, and quality.”
   • [claimed-docs] “Run the latest open models with a single line of code”
   • [claimed-docs] “100+ Supported Models - Text, vision, audio, image, and embeddings”

   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

   Fireworks AI—none0/10

   No evidence in the pack references a deprecation policy, model retirement notice period, or sunset process for hosted models; docs cover inference, fine-tuning, deployment, and pricing but nothing about model lifecycle/retirement communication.

   ⚑ flag

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

   weight 2 · round to Together AI
   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

   Fireworks AI✓fullprobed7/10

   A live probe confirms `GET https://api.fireworks.ai/inference/v1/models` is a real, JSON-speaking, OpenAI-style endpoint (401 without a key, meaning it works with one), consistent with Fireworks' documented OpenAI-compatible API surface. Missing for 10: an explicit first-party docs page specifically describing the /v1/models listing endpoint and its response schema, and an authenticated hands-on confirmation showing the actual model list output.

   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.fireworks.ai/inference/v1/models without a key returned HTTP 401 ({"error":{"message":"Y…”
   • [claimed-docs] “Fireworks provides fast, cost-effective access to leading open-source text models through OpenAI-compatible APIs.”
   • [claimed-docs] “You point your client at `api.fireworks.ai`, send tokens, and pay only for what you use — no GPUs to size, no autoscaler to tune, no cold st…”

   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 Fireworks 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

   Fireworks AI✓fullprobed8/10

   Docs confirm serverless access to 100+ open-source models across modalities via OpenAI-compatible APIs, with 'instant access to the most popular OSS models' and single-line-of-code deployment; the catalog explicitly spans text/vision/audio/image/embeddings. Specific families like Llama/Qwen/DeepSeek/GPT-OSS aren't individually enumerated in this evidence pack, and the model catalog itself wasn't independently enumerable (API requires a key). Missing for 10: explicit per-family model list confirmation, independent enumeration of catalog contents.

   • [claimed-docs] “Get instant access to the most popular OSS models, optimized for cost, speed, and quality.”
   • [claimed-docs] “Run the latest open models with a single line of code”
   • [claimed-docs] “100+ Supported Models - Text, vision, audio, image, and embeddings”
   • [claimed-docs] “Fireworks provides fast, cost-effective access to leading open-source text models through OpenAI-compatible APIs.”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.fireworks.ai/inference/v1/models without a key returned HTTP 401 ({"error":{"message":"Y…”

   proof ↗⚑ flag

Modalities

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

   weight 1 · round to Fireworks AI
   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

   Fireworks AI✓fullclaimed7/10

   Fireworks docs explicitly state support for 'embeddings & reranking in search & context retrieval' and list embeddings among its 100+ supported model types, all via the same OpenAI-compatible API used for other inference, letting a developer avoid a second vendor for retrieval pipelines. Missing for 10: no dedicated embeddings/rerank API reference or usage example, no independent/hands-on confirmation of rerank model quality or throughput.

   • [claimed-docs] “Use embeddings & reranking in search & context retrieval”
   • [claimed-docs] “100+ Supported Models - Text, vision, audio, image, and embeddings”
   • [claimed-docs] “Fireworks provides fast, cost-effective access to leading open-source text models through OpenAI-compatible APIs.”

   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

   Fireworks AI✓fullclaimed8/10

   Docs explicitly list 100+ supported models across text, vision, audio, image, and embeddings, with vision models specifically noted for analyzing images/documents, all on the same OpenAI-compatible API. Missing for 10: no independent/hands-on corroboration of image-generation or audio model usage, and no concrete API examples for non-text modalities beyond the feature list.

   • [claimed-docs] “100+ Supported Models - Text, vision, audio, image, and embeddings”
   • [claimed-docs] “Vision Models - Analyze images and documents”
   • [claimed-docs] “Use embeddings & reranking in search & context retrieval”
   • [claimed-docs] “Fireworks provides fast, cost-effective access to leading open-source text models through OpenAI-compatible APIs.”

   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

   Fireworks AI~partialclaimed4/10

   Fireworks documents an OpenAI-compatible API, tool/function calling, and structured outputs, which implicitly supports plugging into agent frameworks that use the OpenAI SDK, but there is no first-party guide explicitly targeting coding agents or agent frameworks (e.g., LangChain, AutoGen, Cursor, Continue) in the evidence. missing for 10: dedicated integration guides for named coding agents/agent frameworks, tutorials showing agent setup with Fireworks endpoints, and community corroboration of such integrations.

   • [claimed-docs] “Tool calling (also known as function calling) enables models to intelligently select and use external tools based on user input.”
   • [claimed-docs] “A drop-in replacement for closed-model APIs. Route to the best open or closed model for every task, and cut your AI coding spend 50 to 75%.”
   • [claimed-docs] “Migrate from OpenAI: Drop-in replacement for inference and training — same API, same SFT data format”
   • [claimed-docs] “Fireworks provides fast, cost-effective access to leading open-source text models through OpenAI-compatible APIs.”

   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 drawn
   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

   Fireworks AI✓fullprobed8/10

   Fireworks explicitly documents itself as a drop-in replacement using the OpenAI-compatible chat-completions API (docs-1,11,15,27,36), and a live probe confirms the OpenAI-style /v1/models endpoint is functioning at api.fireworks.ai (probe-rt-1), supporting seamless mid-workflow provider swaps without code changes. Missing for 10: independent hands-on agent-switching test (e.g. LangChain/agent framework confirming no code changes needed) and a public OpenAPI spec (probe-3 shows 404s for openapi.json).

   • [claimed-docs] “Drop-in replacement for inference and training — same API, same SFT data format”
   • [claimed-docs] “A drop-in replacement for closed-model APIs. Route to the best open or closed model for every task, and cut your AI coding spend 50 to 75%.”
   • [claimed-docs] “Migrate from OpenAI: Drop-in replacement for inference and training — same API, same SFT data format”
   • [claimed-docs] “Migrate from OpenAI — Drop-in replacement for inference and training — same API, same SFT data format”
   • [claimed-docs] “Fireworks provides fast, cost-effective access to leading open-source text models through OpenAI-compatible APIs.”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.fireworks.ai/inference/v1/models without a key returned HTTP 401 ({"error":{"message":"Y…”

   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 Fireworks AI
   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

   Fireworks AI✓fullprobed9/10

   Docs explicitly state Fireworks is a drop-in replacement for OpenAI (same API), points client at api.fireworks.ai with OpenAI-compatible endpoints, and a live probe confirms the OpenAI-style /v1/models endpoint is reachable and speaks JSON. Missing for 10: no explicit hands-on developer account showing a real OpenAI SDK code snippet with only base_url/api_key changed being run successfully.

   • [claimed-docs] “Drop-in replacement for inference and training — same API, same SFT data format”
   • [claimed-docs] “Migrate from OpenAI: Drop-in replacement for inference and training — same API, same SFT data format”
   • [claimed-docs] “You point your client at `api.fireworks.ai`, send tokens, and pay only for what you use — no GPUs to size, no autoscaler to tune, no cold st…”
   • [claimed-docs] “Fireworks provides fast, cost-effective access to leading open-source text models through OpenAI-compatible APIs.”
   • [probe] “PROBE models-endpoint (2026-09-04): GET https://api.fireworks.ai/inference/v1/models without a key returned HTTP 401 ({"error":{"message":"Y…”

   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

   Fireworks AI~partialclaimed6/10

   Fireworks documents API/CLI (firectl) access to essentially every major capability — inference, fine-tuning, LoRA deployment, model upload, autoscaling, batch inference, benchmarking — implying an API-first architecture where the UI is largely a thin layer over these APIs. However, there is no explicit statement or audit confirming full UI/API feature parity, and no evidence addressing whether any UI-only conveniences (e.g., dashboard analytics, billing, team management) lack API equivalents. Missing for 10: an explicit parity statement or audit, evidence covering account/billing/UI-only features, and independent confirmation that no UI feature is API-inaccessible.

   • [claimed-docs] “Upload your own models from Hugging Face or elsewhere to deploy trained or custom-trained models optimized for your use case.”
   • [claimed-docs] “Deploy your LoRA trained model with a single command: firectl deployment create "accounts//models/"”
   • [claimed-docs] “Live merge is the simplest way to deploy a trained model. Fireworks automatically merges the LoRA weights into the base model at deployment …”
   • [claimed-docs] “Boost model quality with supervised and reinforcement fine-tuning of models up to 1T+ parameters.”
   • [claimed-docs] “Scale to zero when idle to minimize costs”
   • [claimed-docs] “Process large volumes of requests asynchronously at 50% off Serverless per-token prices.”
   • [claimed-docs] “Fireworks Benchmark Tool: Use our open-source benchmarking tool to measure and optimize your deployment's performance”
   • [claimed-docs] “You point your client at `api.fireworks.ai`, send tokens, and pay only for what you use — no GPUs to size, no autoscaler to tune, no cold st…”

   proof ↗⚑ flag

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

   weight 3 · round to Fireworks AI
   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

   Fireworks AI~partialclaimed4/10

   Fireworks documents open, OpenAI-compatible APIs and identical SFT data formats, plus the ability to upload custom/fine-tuned models from Hugging Face, S3, or Azure Blob Storage, which implies some data/model portability rather than lock-in. However there is no explicit documentation of a data export tool, account data download, or guidance for migrating fine-tuning datasets or deployed models back out of the platform. Missing for 10: explicit data-export/download feature docs, confirmation that user-uploaded training data or fine-tuned models can be freely exported (not just uploaded), and any account/data-deletion or portability policy.

   • [claimed-docs] “Drop-in replacement for inference and training — same API, same SFT data format”
   • [claimed-docs] “Upload your own models from Hugging Face or elsewhere to deploy trained or custom-trained models optimized for your use case.”
   • [claimed-docs] “Upload from local files or directly from S3 buckets or Azure Blob Storage”
   • [claimed-docs] “Migrate from OpenAI — Drop-in replacement for inference and training — same API, same SFT data format”

   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

   Fireworks AI—none0/10

   Fireworks AI is a proprietary inference/hosting platform; there is no evidence of an open-license source-code release for the core product (only an 'open-source benchmarking tool' side utility is mentioned, not the platform itself). No repository, license file, or source availability is documented.

   • [claimed-docs] “Use our open-source benchmarking tool to measure and optimize your deployment's performance”
   • [claimed-docs] “Fireworks Benchmark Tool: Use our open-source benchmarking tool to measure and optimize your deployment's performance”

   proof ↗⚑ 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

   Fireworks AI—none0/10

   The evidence pack shows references to service tiers (priority, fast) and notes on-demand deployments have 'no hard rate limits', but there is no documented table or page specifying actual rate-limit numbers (RPM/TPM) or how they scale across usage tiers for serverless usage. Developers have no concrete documented limits to plan against before hitting them in production.

   • [claimed-docs] “On-demand deployments give you dedicated GPUs for your models, providing several advantages over serverless: **Better performance**...**No h…”
   • [claimed-docs] “Priority — higher reliability during peak periods. Opt in by setting `service_tier: "priority"` on chat completions.”
   • [claimed-docs] “Priority — higher reliability during peak periods. Opt in by setting service_tier: "priority" on chat completions.”

   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

   Fireworks AI—none0/10

   No evidence in the pack of any spending cap, budget alert, or usage limit configuration feature; only cost-related mentions are pricing structures (serverless, batch discounts) not budget controls. A community report even highlights an unexpectedly high bill with no indication of caps to prevent it, reinforcing the absence of this capability.

   • [community] “Fireworks AI is one of the most overpriced model hosting companies. Tried fine-tuning with 10k records SFT on gpt-oss-20b, ran for 8 mins, b…”

   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

   Fireworks AI~partialcommunity5/10

   Docs describe a self-serve, pay-per-token model ('point your client at api.fireworks.ai... pay only for what you use', batch inference at '50% off Serverless per-token prices') implying pricing is accessible without sales contact, and a community user cites a specific billed dollar amount for usage, suggesting transparent metering. However, no evidence pack item directly cites or shows Fireworks' public pricing page listing per-model per-token rates. Missing for 10: a direct citation to the pricing page enumerating per-token rates for each hosted model, and confirmation that all 100+ models have listed public prices rather than requiring contact for some tiers.

   • [claimed-docs] “You point your client at `api.fireworks.ai`, send tokens, and pay only for what you use — no GPUs to size, no autoscaler to tune, no cold st…”
   • [claimed-docs] “Process large volumes of requests asynchronously at 50% off Serverless per-token prices.”
   • [claimed-docs] “Process large volumes of requests asynchronously at **50% off** Serverless per-token prices.”
   • [community] “Fireworks AI is one of the most overpriced model hosting companies. Tried fine-tuning with 10k records SFT on gpt-oss-20b, ran for 8 mins, b…”

   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

   Fireworks AI—none0/10

   No evidence in the pack mentions data residency, regional storage options, or geographic controls for where data is stored/processed on Fireworks AI; the docs cover inference, fine-tuning, deployment, and pricing but not region selection.

   ⚑ flag

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

   weight 3 · round drawn
   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

   Fireworks AI—none0/10

   No evidence pack item addresses a data-training opt-out, privacy policy, or data-retention/no-train guarantee for inputs sent to Fireworks AI's inference or fine-tuning APIs; all citations concern performance, deployment, and pricing features. missing for 10: explicit privacy policy or terms stating user data is not used for model training, an opt-out/opt-in control, and any independent confirmation of this practice.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   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

   Fireworks AI—none0/10

   No evidence in the pack discusses data retention policies, deletion controls, or privacy/compliance mechanisms for user data or fine-tuning datasets; the docs cover inference, fine-tuning, deployment, and pricing but never data retention/deletion. missing for 10: documented data retention policy, user-facing deletion/erasure controls, data handling/compliance certifications (SOC2/GDPR), retention configuration options.

   ⚑ 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

   Fireworks AI—none0/10

   No evidence pack items address telemetry, usage tracking, opt-out controls, or privacy settings for Fireworks AI; the docs cover inference, fine-tuning, and deployment features but never mention telemetry/data-collection opt-out. missing for 10: any documentation of telemetry collection, a privacy/opt-out setting, or usage-tracking disclosure.

   ⚑ 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

   Fireworks AI—none0/10

   No evidence of a stated uptime/availability SLA (e.g., 99.9% commitment) for paid or enterprise tiers — only a public status page and an optional 'priority' service tier for better reliability during peak periods, which is not a contractual SLA.

   • [claimed-docs] “Priority — higher reliability during peak periods. Opt in by setting service_tier: "priority" on chat completions.”
   • [claimed-docs] “Priority — higher reliability during peak periods. Opt in by setting `service_tier: "priority"` on chat completions.”
   • [probe] “PROBE status-page (2026-09-04): https://status.fireworks.ai returns HTTP 200 and renders a public service-status page (page body includes "o…”

   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

   Fireworks AI~partialprobed6/10

   A public status page at status.fireworks.ai is confirmed live and shows current operational status, satisfying the core ask of checking uptime before committing production traffic. However, the evidence pack does not confirm the page includes a historical incident log or past-outage records. missing for 10: explicit confirmation of incident history/timeline on the status page, independent user reports referencing past outages logged there.

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

   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 to Fireworks AI
   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

   Fireworks AI~partialclaimed4/10

   Fireworks documents an open-source benchmarking tool that customers can use to measure their own deployment's throughput/latency, and it markets 'Fast' variants and on-demand deployments with claims of 'lower latency, higher throughput' — but the evidence pack contains no actual published tokens-per-second numbers, latency benchmarks, or third-party load-testing results substantiating these speed claims. Missing for 10: concrete published TPS/latency figures, independent benchmark comparisons, or a load-testing guide with real numbers rather than just a tool pointer.

   • [claimed-docs] “Use our open-source benchmarking tool to measure and optimize your deployment's performance”
   • [claimed-docs] “Fireworks Benchmark Tool: Use our open-source benchmarking tool to measure and optimize your deployment's performance”
   • [claimed-docs] “Fast — high-speed deployments for latency-sensitive workloads. Selected by switching the model ID to a Fast variant”
   • [claimed-docs] “Better performance – Lower latency, higher throughput, and predictable performance unaffected by other users”
   • [claimed-docs] “On-demand deployments give you dedicated GPUs for your models, providing several advantages over serverless: **Better performance**...**No h…”

   proof ↗⚑ flag

Serving

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

   weight 3 · round to Fireworks AI
   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

   Fireworks AI✓fullclaimed8/10

   Fireworks explicitly documents Fast variants for latency-sensitive workloads, dedicated on-demand GPUs for predictable low-latency/high-throughput, sticky session-affinity routing to boost cache hit rate, a priority service tier, and an open-source benchmarking tool to measure/optimize deployment performance. missing for 10: independent third-party latency/throughput benchmarks corroborating the claims, and no direct rebuttal of speed claims in community evidence (only pricing complaints, which are off-topic).

   • [claimed-docs] “Fast — high-speed deployments for latency-sensitive workloads. Selected by switching the model ID to a Fast variant”
   • [claimed-docs] “Better performance – Lower latency, higher throughput, and predictable performance unaffected by other users”
   • [claimed-docs] “On-demand deployments give you dedicated GPUs for your models, providing several advantages over serverless: **Better performance**...**No h…”
   • [claimed-docs] “Optional sticky-routing key. Pin repeated requests to the same replica to maximize prompt-cache hit rate.”
   • [claimed-docs] “x-session-affinity: Optional sticky-routing key. Pin repeated requests to the same replica to maximize prompt-cache hit rate.”
   • [claimed-docs] “Priority — higher reliability during peak periods. Opt in by setting service_tier: "priority" on chat completions.”
   • [claimed-docs] “Use our open-source benchmarking tool to measure and optimize your deployment's performance”
   • [claimed-docs] “You point your client at `api.fireworks.ai`, send tokens, and pay only for what you use — no GPUs to size, no autoscaler to tune, no cold st…”

   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

   Fireworks AI~partialclaimed6/10

   Fireworks documents an explicit prompt-caching mechanism: an optional x-session-affinity sticky-routing key that pins repeated requests to the same replica specifically to 'maximize prompt-cache hit rate,' directly addressing latency/cost benefits for repeated context on serverless deployments. However, details are thin — no documentation of cache TTL/eviction policy, no quantified latency/cost savings numbers, and no independent benchmarks or hands-on confirmation of cache hit rates. missing for 10: quantified latency/cost savings from cache hits, cache eviction/TTL policy details, independent or hands-on corroboration of the caching behavior.

   • [claimed-docs] “Optional sticky-routing key. Pin repeated requests to the same replica to maximize prompt-cache hit rate.”
   • [claimed-docs] “x-session-affinity: Optional sticky-routing key. Pin repeated requests to the same replica to maximize prompt-cache hit rate.”

   proof ↗⚑ 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

   Fireworks AI—none0/10

   The evidence pack repeatedly describes Fireworks as an OpenAI-compatible inference API but never explicitly documents SSE/token-streaming behavior (e.g., a `stream: true` parameter or chunked response format) for chat/completions endpoints; docs-17 and docs-36 only allude to 'sending tokens' and API compatibility without confirming streaming responses. Missing for 10: explicit streaming API docs, SSE example/code snippet, or hands-on confirmation of token-by-token delivery.

   • [claimed-docs] “You point your client at `api.fireworks.ai`, send tokens, and pay only for what you use — no GPUs to size, no autoscaler to tune, no cold st…”
   • [claimed-docs] “Fireworks provides fast, cost-effective access to leading open-source text models through OpenAI-compatible APIs.”

   proof ↗⚑ flag

Structured

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

   weight 3 · round drawn
   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

   Fireworks AI✓fullclaimed8/10

   Fireworks docs explicitly describe a Structured Outputs feature to 'force model output to conform to a JSON schema' and ensure responses 'conform to your specified format, making them easy to parse,' directly matching the story. Missing for 10: independent/hands-on corroboration of reliability across models and no mention of grammar-based constraints beyond JSON schema.

   • [claimed-docs] “Structured outputs ensure model responses conform to your specified format, making them easy to parse and integrate into your application.”
   • [claimed-docs] “Force model output to conform to a JSON schema”

   proof ↗⚑ 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

   Fireworks AI~partialclaimed5/10

   Fireworks documents tool/function calling as a supported feature (docs-2) and structured JSON-schema outputs (docs-19), which underpin agent tool-use loops, but there is no documentation or evidence specifically addressing parallel tool calls, multi-step tool-use reliability, or fidelity benchmarks against OpenAI-style tool calling on open models. missing for 10: explicit parallel/multi-step tool-calling documentation, reliability/fidelity benchmarks, independent hands-on validation of agent-loop tool use.

   • [claimed-docs] “Tool calling (also known as function calling) enables models to intelligently select and use external tools based on user input.”
   • [claimed-docs] “Force model output to conform to a JSON schema”

   proof ↗⚑ flag