Integrations
Jetty is one API with swappable parts. Everything below talks to the same backend ( https://flows-api.jetty.io ) and authenticates with the same token, and the API is OpenAI-compatible, so most things you already use point at it without changes.
There are six layers you can plug into. Each is tech-agnostic by design: if a provider changes pricing or a model regresses, you change one line, not your workflow.
Anthropic, OpenAI, Google, Bedrock, OpenRouter, Replicate, vLLM, and any model they serve.
Runbook runtimes (claude-code, codex, gemini-cli, hermes, opencode) or bring your own.
The Jetty passthrough proxy, OpenRouter, and Nous routing across providers.
Plugin, MCP server, TypeScript SDK, REST API, and shell CLI on-ramps.
Keep your agent in Flue or your own loop; evaluate on Jetty.
Managed, S3, GCS, or R2. Pick a backend per collection.
AI providers
AI providers (or model providers) are the backends Jetty calls for inference, both from the passthrough proxy and from the model steps inside a workflow. You set a key once per collection, then reference a model by its provider-prefixed slug. Whatever a provider serves, you can call. Here are the ten most-used models this month, ranked on OpenRouter.
The providers Jetty authenticates against, each with its own key:
Claude models via anthropic/… slugs. A direct API key, or a forwarded subscription.
GPT and o-series models via openai/… slugs, with a direct API key.
Gemini models via gemini/… slugs. GEMINI_API_KEY or GOOGLE_API_KEY; Vertex too.
Models hosted on Bedrock via bedrock/… slugs. Bearer-token auth (AWS_BEARER_TOKEN_BEDROCK).
A gateway to hundreds of upstreams via openrouter/… slugs.
Image and video models and the wider Replicate catalog, via replicate/… slugs and a REPLICATE_API_TOKEN.
Your own self-hosted, OpenAI-compatible endpoint. Point at a VLLM_BASE_URL.
Not every model needs a dedicated card. The proxy and the litellm_chat / litellm_batch steps route to 100+ providers through LiteLLM, and the step library adds image and video activities. Keys are managed in Settings → AI providers and scoped per collection; see connected accounts & secrets.
Agents
When you run an agent on Jetty, it executes inside a managed sandbox using a built-in runbook runtime. Each runtime reads the matching provider key and is chosen with an agent: line in runbook frontmatter or the jetty.agent field on a run.
Anthropic's coding agent and the default. Backed by Anthropic, Bedrock, or OpenRouter, with the best general agentic loop.
OpenAI's coding agent. Backed by OpenAI, or OpenRouter via a base-URL proxy.
Google's CLI agent. Backed by Google AI or Vertex; captures token usage per run.
Nous Research's agent. Routes across Anthropic, OpenAI, Bedrock, Google, OpenRouter, and vLLM from one config.
The open-source SST agent. Backed by Anthropic, OpenAI, Bedrock, or OpenRouter.
The full runtime-by-provider matrix and the trade-offs between them live on the runbook runtimes page. Prefer to keep the agent in your own stack? That's the agent frameworks pattern below.
AI gateways
A gateway routes one request across many upstream providers from a single config. Three are first-class.
The front door itself. Switch providers with the model field, and every call is recorded as a trajectory.
Use openrouter/… slugs or model_provider: openrouter. Control upstream order and fallbacks with OPENROUTER_PROVIDER_ORDER / OPENROUTER_ALLOW_FALLBACKS.
Subscription-based routing across providers, available through the hermes runtime.
model_providerpicks the gateway; the model slug has to match it. A mismatched slug, like a bareclaude-sonnet-4-6sent to OpenRouter, is the most common cause of a run that exits in seconds having produced nothing.
SDKs
The on-ramps for your own code and editors. They all hit the same backend with the same token, so you can start with the plugin today and drop down to the SDK or REST API later without changing anything server-side.
| On-ramp | Best for | You get |
|---|---|---|
| Claude Code plugin & skills | Claude Code users | /jetty commands, the /jetty-setup wizard, and the create-runbook / optimize-runbook skills. |
| MCP server | Cursor, VS Code, Windsurf, Zed, Codex, Gemini CLI | 16+ Jetty tools in any MCP-compatible agent, via npx -y jetty-mcp-server. |
| Client SDK | TypeScript / Node apps & CI | @jetty/sdk, a typed JettyClient with runAndWait() and the full run / trajectory / label surface. |
| REST API | Any language, any runtime | The /v1/chat/completions endpoint, with passthrough and runbook modes. |
| Standalone CLI | Shell scripts & quick checks | source jetty-cli.sh for jetty_collections, jetty_run_sync, and friends. No install. |
Agent Frameworks
You don't have to run your agent on Jetty to get value from it. Keep the agent wherever it already lives and use Jetty as the independent grader, store, and A/B harness around it. The grader is a runbook the agent under test never sees, so you can swap frameworks, models, or providers and keep the exact same measuring stick. The only Jetty-specific code is a few SDK calls.
A worked example. Define an agent with createAgent(), then A/B-test two configs and grade every reply on Jetty. Read the full Flue + Jetty walkthrough.
A worked example. Drive Vercel's eve agent over eve/client, A/B two configs, and grade every reply on Jetty. Read the full eve + Jetty walkthrough.
Any framework that can produce an output and call jetty.runAndWait(...), a raw provider SDK or a hand-rolled loop, drops Jetty in as the eval layer.
Full walkthrough, including the offline-mode first run and the regression-detection logic, in Bring your own framework.
Cloud storage
Artifacts and trajectories persist to a pluggable storage backend, configured per collection, so each team keeps its data where it needs to. The backends:
Jetty-hosted object storage, the default. Nothing to configure.
Selector s3. Also S3-compatible stores (MinIO, Ceph) via a custom endpoint.
Selector gcs. A service-account credential and a bucket.
Selector r2. An account id and bucket, with S3-style access keys.
The data model behind this, relational metadata plus object storage for artifacts, is in architecture.
One token, everywhere
Every on-ramp resolves your Jetty API token the same way, in this order: an explicit value you pass in code or set inline, then the JETTY_API_TOKEN environment variable, then the file at ~/.config/jetty/token written by /jetty-setup. Run /jetty-setup once (or grab a token from Settings → API keys) and every tool here just works. Point at a different backend with JETTY_API_URL if you need to.
The plugin, MCP server, and CLI live in one open-source repo, jettyio/jettyio-skills; the SDK lives in jettyio/jetty-sdk.