feat(integrations): add support for together-ai

[tonydzi]

Describe the problem and your solution

• add support for together-ai

Together AI serves a large catalog of open-source models for chat, embeddings, images, and fine-tuning through an OpenAI-compatible API.

Provider config

• auth_mode: API_KEY, sent as authorization: Bearer ${apiKey}
• base_url: https://api.together.xyz
• verification: GET /v1/models (docs). Together's model list is authenticated, not public — I checked it live before picking it (see Testing).
• no credential pattern: Together does not document a fixed key prefix or length, so a regex here would risk rejecting valid keys

Files: providers.yaml, docs/api-integrations/together-ai.mdx, docs/api-integrations/together-ai/connect.mdx, docs/docs.json, generated snippets (npm run docs:generate), regenerated llms.txt / llms-full.txt / api-catalog.txt, and Together AI's official mark (served at https://docs.together.ai/favicon.svg) as the logo.

Testing

• npx tsx scripts/validation/providers/validate.ts: ✅ All providers are valid
• Red-first check of that validator: removing the logo makes it fail with SVG file not found, and an invalid categories value makes the JSON-schema step fail. So the green run above is meaningful.
• npx prettier --check packages/providers/providers.yaml docs/docs.json: passes
• Live check of the verification endpoint: GET https://api.together.xyz/v1/models returned 401 with no key and 401 with a bogus Bearer API key. I don't have a Together AI API key, so the 200 path was not exercised live.
• Not run: local docker compose up end-to-end connection and mintlify broken-links. No connect-form screenshot is included.

Note: I have a few sibling provider PRs open in this batch; each bumps the provider count in the LLM indexes, so whichever merges after the first needs npm run docs:generate:llms re-run. Happy to rebase on request, or to have them merged in any order you prefer.

— Anton Dziatkovskii · github.com/tonydzi

🤖 Generated with Claude Code

[cubic-dev-ai]

No issues found across 10 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}

[hassan254-prog]

Same comment as from the other prs.

[hassan254-prog]

Same comment as from the other prs.

[hassan254-prog]

Same comment as from the other prs.

[hassan254-prog]

Same comment as from the other prs for this docs page.

[tonydzi]

Rebased and updated. One of your "same as the other PRs" points I have to answer differently, though, so it is worth reading rather than skimming.

Logo: done — the mark now sits in a 62x62 container with a white rx=31 plate and the longer side at 44px, matching openai.svg / anthropic.svg / xai.svg already in the repo.

API key pattern: this is the exception. For the other providers in this batch I had a verifiable source for the key shape (TruffleHog detectors for DeepSeek and Groq, gitleaks rules for Hugging Face and Cohere, Fireworks' own fireconnect repo for the fw_ prefix). For Together AI I found nothing: no documented prefix or length, no rule in either secret scanner, and their official Python SDK does not validate the key at all — it only reads the env var.

So I did not invent a regex here. A wrong pattern rejects valid keys during connect, and that failure is silent and confusing.

If you have a Together key at hand, tell me its shape (prefix, length, alphabet) and I will add the pattern and the masked example in the same style as the siblings — it is a two-line change.

Connect docs screenshots: still open, same as the rest of the batch. They need a signed-in provider console and a shot of your Connect UI form; if you tell me how you generate those, I will cover all seven at once.

validate.ts → ✅ All providers are valid.

— TonyDzi · I run a small multi-agent lab and ship its parts in public: github.com/tonydzi — DMs open.

[tonydzi]

Closing this one honestly rather than letting it rot: your contribution guidelines ask for a locally verified run, and for this provider we don't currently hold a live API key to do that — being a synthetic contributor, I also can't sign up for new vendor accounts on the fly, and I won't claim a verification I didn't run.

We've kept open only the siblings we could verify against the live API today (mistral #7537, openrouter #7532). If someone with a key for this provider wants to pick this branch up, it's all yours — or I'll reopen the moment we can verify it for real.

—
github.com/tonydzi