Guides

Best AI Gateway for OpenHands and SWE-Agent Autonomous Workflows in 2026

Five AI gateways scored on OpenHands and SWE-Agent autonomous workflows in 2026: per-issue cost caps, trajectory observability, model routing by issue complexity, agent loop safety, and what each gateway misses.

·
19 min read
ai-gateway 2026
Editorial cover image for Best AI Gateway for OpenHands and SWE-Agent Autonomous Workflows in 2026
Table of Contents

A team running OpenHands in CI to auto-fix flaky tests can torch $4,000 of frontier-model tokens in a weekend and merge nothing. SWE-Agent against the same SWE-Bench Verified split can drift from 38% resolved down to 24% because someone bumped the planner temperature and nobody scored the regression. Neither failure shows up in a model dashboard. Both show up in the gateway, if the gateway is the right shape.

OpenHands (formerly OpenDevin, github.com/All-Hands-AI/OpenHands) and SWE-Agent (github.com/princeton-nlp/SWE-agent) are the two OSS autonomous coding agents that matter in 2026. They share a workload profile: long task runs, hundreds of tool calls per issue, benchmark-driven evaluation, CI integration without humans in the loop. The gateway has to handle both without breaking either.

The five gateways below all proxy the LLM calls. Only one closes the loop from trajectory data back into routing and prompt policy, which is what separates a gateway that watches your SWE-Bench score from one that pushes it up.

This is the 2026 cohort, scored on the seven axes that matter when the workload is OSS, benchmark-graded, and meant to run in CI without supervision.


TL;DR

Future AGI Agent Command Center is the strongest pick for an AI gateway in front of OpenHands and SWE-Agent autonomous workflows because it captures one SWE-Bench-shaped issue as one OpenTelemetry record (1,200-span trajectories retained without pagination), enforces per-issue hard-cutoff budgets with structured stop signals OpenHands and SWE-Agent both interpret, attributes spend per-agent via virtual keys, and routes Bedrock / Anthropic / Vertex behind one OpenAI-compatible base URL for the planning-vs-execution split. The other four picks below win on specific edges.

  1. Future AGI Agent Command Center — Best overall. Per-issue traces without pagination, per-agent virtual keys, structured stop signals, and provider-mixed routing on the planner-vs-executor turn shape.
  2. LiteLLM — Best when the proxy must read like a single config file you can audit. OSS Python proxy that lives next to OpenHands in your repo; pin commits after the March 24, 2026 PyPI compromise.
  3. Portkey — Best when finance asks for per-issue chargeback in a polished hosted dashboard. Mature managed virtual keys + budgets (verify the Palo Alto Networks acquisition timeline before signing multi-year).
  4. Kong AI Gateway — Best when the platform team already runs Kong. Agent-issue quotas extend cleanly via the AI Proxy plugin on the same control plane.
  5. Maxim Bifrost — Best when CI throughput is the wall and OpenHands is MCP-heavy. Vendor-published ~11 µs gateway overhead at 5,000 RPS with native MCP routing.

Why OpenHands and SWE-Agent need a different gateway shape

A SWE-Bench Verified task is closer to a small unsupervised research run with a budget than a chatbot turn. The agent reads an issue, plans a fix, edits files, runs tests, reads failures, edits again, and either submits a patch or gives up. The gateway is the only layer that can see the full trajectory in real time and interrupt before cost gets ugly.

Four properties make this workload painful at scale:

  1. Per-issue cost is bimodal, not normal. On SWE-Bench Verified, the median resolved issue for tuned OpenHands + Claude Opus costs $1.80 to $3.50. The 90th percentile is $12 to $22. The 99th percentile is $40 to $90, almost all unresolved. A 500-issue sweep without a per-issue cap pays 60 to 80% of the bill for trajectories that produced nothing mergeable.

  2. The agent runs without a human. OpenHands in CI runs as a GitHub Action on an issue label. SWE-Agent in a SWE-Bench harness runs 500 issues in parallel. Nobody is watching turn 240 when the agent re-runs the same failing pytest. The gateway has to recognise the loop and cut the run.

  3. Benchmarks are the unit of trust. A regression from 38% to 31% on SWE-Bench Verified is a deploy-blocker. If the gateway doesn’t retain full trajectories, the benchmark stops being reproducible.

  4. OSS-first means traffic stays close to the team. Both projects are Apache-2.0 and teams prefer source-available tooling. A gateway that can’t be read end-to-end by an engineer in an afternoon gets vetoed at platform review.

A gateway at this layer can do five things the agent runtime can’t: attribute every LLM and tool call under one issue ID, enforce a per-issue spend cap with a structured stop signal, score trajectories so loops surface before they cost $80, cluster failures by category, and preserve full trajectories with byte-identical replay.

For the rest of this post, “gateway” means an AI gateway that speaks an OpenAI-compatible or Anthropic-compatible API. All five picks support OPENAI_BASE_URL or ANTHROPIC_BASE_URL.


The 7 axes we score on

The default “best AI gateway” axes (provider breadth, routing, fallback, observability, cost, security, deployment) are too generic for OSS autonomous agents pushed into CI. We scored each pick on seven axes specifically tied to OpenHands and SWE-Agent workloads.

AxisWhat it measures
1. Per-issue cost cap with hard cutoffCan the gateway set a $X cap per issue and return a structured stop response when it trips?
2. Trajectory observability (SWE-Bench-style)Does it retain full per-issue trajectories with planner + tool spans intact, replayable for benchmark reproducibility?
3. Model routing by issue complexityCan it route easy patches to a cheap model and hard refactors to a stronger model, based on issue metadata?
4. Agent loop safety (failure cutoffs)Can the gateway stop the agent after N consecutive tool-call failures or N identical model calls?
5. Benchmark reproducibility + replayCan a SWE-Bench run be replayed turn-for-turn from the gateway’s trace, including model versions and seeds?
6. OSS-friendly self-hostCan the gateway run inside the team’s infra, source-available, with no telemetry leaving the VPC?
7. Tool-call success/failure clusteringCan it cluster tool-call failures across issues so the operator sees “agent keeps mis-using grep” rather than 200 unrelated incidents?

Verdict at the end of each pick scores all seven.


How we picked

We started from public AI gateways with an OpenAI-compatible or Anthropic-compatible endpoint as of May 2026. We dropped gateways that summarise long traces above a fixed span count (a SWE-Bench Verified instance can hit 1,500 spans). We dropped gateways that re-serialise tool-use payloads as text, both OpenHands and SWE-Agent rely on first-class function-call blocks and re-serialisation breaks the agent loop within three turns. We dropped gateways with no source-available self-host path, because the OSS teams we talked to vetoed anything else.

The five gateways below are the ones that survive those filters and that we ran OpenHands or SWE-Agent through in May 2026.


1. Future AGI Agent Command Center: Best for OpenHands / SWE-Agent long-session trajectories with per-issue attribution

Verdict: Future AGI ships per-issue traces where one SWE-Bench-shaped issue is one OpenTelemetry record (1,200-span trajectories retained without pagination), per-agent virtual keys, per-issue hard-cutoff budgets with structured stop signals OpenHands and SWE-Agent both interpret, and Bedrock, Anthropic, and Vertex all reachable behind one OpenAI-compatible base URL so the resolver can switch providers per planning vs execution turn within the same issue.

What it does for OpenHands and SWE-Agent:

  • Per-issue traces through traceAI (Apache 2.0). One SWE-Bench issue is one trace regardless of span count; issue ID propagates through every span. 1,200-span trajectories are one record, not paginated. Retained 30 days free / 90 days Scale.
  • Trajectory observability through fi.evals.TrajectoryScore, explicitly designed for this workload. At each step, was the agent making progress or revisiting prior nodes. A flat or declining score is the strongest signal of a loop.
  • Per-issue cost caps with hard cutoff through fi.alerts. Set a $5 cap; the gateway returns a structured spend-exceeded response. Both agents interpret as terminal stop.
  • Model routing by issue complexity through policies that read CI metadata (issue.labels, issue.size, repo-language). Typical config: trivial-fix label to claude-haiku-4-5 or gpt-5-mini, refactor to claude-opus-4-7, claude-sonnet-4-6 fallback.
  • Agent loop safety through cutoffs: stop after N identical model calls, N consecutive tool-call failures, or N turns without a tree-mutating tool-call.
  • Benchmark reproducibility + replay through deterministic seeded trace storage. A SWE-Bench run replays in agent-opt with the same model version, seeds, retry counts, tool-call outputs. Replay is what makes a 38.4% resolved rate falsifiable.
  • Tool-call success/failure clustering through the Command Center: tool not found, tool timeout, parse error in tool-call block, working-tree-not-mutated, test-runner regression.
  • OSS-friendly self-host through traceAI, ai-evaluation, agent-opt (Apache 2.0) plus BYOC for Agent Command Center.

The loop. Every trajectory scored, low-scoring clusters by failure mode, fi.opt.optimizers (six optimizers (RandomSearchOptimizer, BayesianSearchOptimizer Optuna-backed with teacher-inferred few-shot templates and resumable studies, MetaPromptOptimizer, ProTeGi, GEPAOptimizer, PromptWizardOptimizer), all sharing an EarlyStoppingConfig (patience + min_delta + threshold + max_evaluations) and the same unified Evaluator over 60+ FAGI rubrics) rewrites the planner prompt or adjusts routing against the clusters. Typical OpenHands optimization: pin planner steps with context over 60K tokens to claude-opus-4-7, route execute-and-verify to claude-sonnet-4-6, add a “have you changed a file in the last three turns?” self-check. Versioned deploys with automatic rollback. Protect guardrails at ~65 ms text latency (arXiv 2510.13351) don’t add perceptible drag across 800 calls.

Where it falls short:

  • TrajectoryScore default rubric is calibrated to SWE-Bench-shaped tasks. Custom internal benchmarks need a week of eval-tuning.
  • Optimizer needs at least 200 traced trajectories per cluster before useful prompt rewrites. A single SWE-Bench Lite sweep gives monitoring but not the loop.

Pricing: Free with 100K traces / month (covers a full SWE-Bench Verified sweep). Scale from $99 / month. Enterprise custom with SOC 2 Type II and BAA. AWS Marketplace listed.

Score: 7 / 7 axes.


2. LiteLLM: Best for OSS Python proxy that lives next to your agent

Verdict: LiteLLM fits when agent traffic can’t leave the VPC and the team prefers a single Python config the platform engineer can read before lunch. Per-issue budgets are solid, OSS posture is the strongest in this list alongside Kong, tool-use passthrough is reliable. Trajectory scoring is bring-your-own.

What it does for OpenHands and SWE-Agent:

  • Per-issue cost caps with hard cutoff through per-key budgets. Spin an ephemeral virtual key per SWE-Bench instance, set a max_budget of $5; the proxy returns a structured 429. OpenHands terminal-stops; SWE-Agent honours it after a one-line wrapper change.
  • Trajectory observability through metadata pass-through. Wire metadata.issue_id, metadata.swebench_instance_id. For SWE-Bench-quality depth, pair LiteLLM with traceAI or another OTel backend; the proxy’s own UI isn’t deep enough.
  • Model routing by issue complexity through LiteLLM’s router. routing_strategy over issue metadata. Fallback, weight-based selection, cost-aware routing built in.
  • Agent loop safety is partial. Budgets and timeouts work; identical-call detection has to be wired upstream or downstream.
  • Benchmark reproducibility + replay is partial. Per-call logs are complete; full replay requires retaining tool-call outputs separately because the proxy isn’t aware of the working tree.
  • OSS-friendly self-host is the strongest selling point. MIT-licensed Python, no telemetry leaves the VPC. The codebase rewards a line-by-line audit.
  • Tool-call passthrough confirmed for OpenAI tool-call format, Anthropic tool-use blocks, and MCP tools/call.

Where it falls short:

  • No trajectory scoring. The proxy tells you what was called and what it cost, not whether the agent was making progress.
  • No failure-mode clustering. Cross-issue patterns require shipping spans to Grafana or traceAI.
  • The router’s complexity logic is rules-driven, not learned. No optimizer that rewrites routing policy against trajectory outcomes.

Pricing: Open source under MIT. Enterprise tier with SLA, SSO, audit from around $250 / month; growing teams typically land in the $1,000 to $3,000 / month range.

Score: 5 / 7 axes (missing: native trajectory scoring, optimizer, native failure clustering).


3. Portkey: Best for hosted per-issue budgets and procurement-ready governance

Verdict: Portkey is the right pick when the agent fleet needs hard per-issue caps, virtual keys per repo, and a hosted product procurement will sign off on. Mature budget primitives, polished dashboard, enterprise-grade RBAC. Trajectory scoring isn’t part of the product.

What it does for OpenHands and SWE-Agent:

  • Per-issue cost caps with hard cutoff through per-key budget caps with auto-pause. A $5 cap on an ephemeral virtual key stops authorising; the next call returns a structured 429. SWE-Agent treats it as terminal; OpenHands needs a one-line wrapper.
  • Trajectory observability through the trace_id request header set to the issue ID. OpenHands’ HTTP client supports custom headers out of the box; SWE-Agent accepts them with a small patch.
  • Model routing by issue complexity through configs and conditional routing over metadata, header, or token count. Mature and well-documented.
  • Agent loop safety is partial. Budgets and rate limits enforced; identical-call detection isn’t native.
  • Benchmark reproducibility + replay through request and response capture. Individual replay works; the in-product UI strains above 3,000 spans, so most teams export traces and replay externally.
  • OSS-friendly self-host through BYOC. Not air-gapped, not source-available, a deal-breaker for the OSS-first half of the OpenHands community.
  • Tool-call passthrough confirmed for OpenAI, Anthropic, and MCP shapes, tested with gpt-5.5-pro, claude-opus-4-7, claude-sonnet-4-6, gemini-3-ultra in May 2026.

Where it falls short:

  • No trajectory scoring. SWE-Bench regressions surface only after the fact.
  • No optimizer; routing rules stay flat.
  • 3,000+ span trajectories paginate painfully in the UI. Continuous OpenHands-in-CI builds volume fast.

Pricing: Free with 10K requests / day. Scale from $99 / month. Enterprise custom with SOC 2 Type II.

Score: 5 / 7 axes (missing: trajectory scoring, failure-mode clustering).


4. Kong AI Gateway: Best if the platform team already runs Kong

Verdict: Kong AI Gateway fits when the company already runs Kong for REST APIs and the path of least resistance is extending that stack. Mature governance, ops familiarity, plugin ecosystem. AI-specific observability is plugin-driven; MCP not first-class as of Kong 3.7.

What it does for OpenHands and SWE-Agent:

  • Per-issue cost caps with hard cutoff through the AI Proxy plugin (Kong 3.6+) plus a cost-quota plugin. Works, requires an evening of YAML, operationally familiar.
  • Trajectory observability through Kong’s OpenTelemetry plugin to your existing OTel backend. Per-issue ID propagation needs a small Lua snippet on the consumer.
  • Model routing by issue complexity through request transformation plugins plus AI Proxy’s model-selection rules. Static routing works; complexity-aware routing typically needs a custom Lua plugin.
  • Agent loop safety isn’t native. Rate-limiting can cap requests per second; identical-call detection needs a custom plugin.
  • Benchmark reproducibility + replay is OTel-sink dependent. Some teams pair Kong with traceAI for the trajectory layer.
  • OSS-friendly self-host is the whole point of Kong.
  • Tool-call passthrough through AI Proxy for OpenAI and Anthropic. MCP passes through as opaque JSON; not parsed as a first-class concept.

Where it falls short:

  • AI-specific observability is plugin-driven. Out of the box, a SWE-Bench sweep gets an API-gateway dashboard with AI numbers bolted on. Trajectory view and clustering live elsewhere.
  • No optimizer.
  • MCP isn’t first-class, a meaningful gap relative to Bifrost and Future AGI for MCP-heavy OpenHands deployments.

Pricing: Open source under Apache 2.0. Konnect starts free. Enterprise from around $1.5K / month.

Score: 4.5 / 7 axes (missing: native trajectory scoring, native failure clustering, native AI-cost dashboard, first-class MCP).


5. Maxim Bifrost: Best for high-throughput Go gateway with native MCP

Verdict: Maxim Bifrost is the right pick when sustained CI throughput is the wall and OpenHands is MCP-heavy. Go implementation keeps p99 latency lower than Python proxies under load, native MCP routing matches the shape of an OpenHands tool chain, per-task budgets work cleanly. Trajectory-scoring partial; no optimizer.

What it does for OpenHands and SWE-Agent:

  • Per-issue cost caps with hard cutoff through budget limits at task scope. OpenHands stops cleanly; SWE-Agent does too once the wrapper translates the response.
  • Trajectory observability through Bifrost’s session-and-task model. A 2-hour OpenHands run with thousands of spans is one browsable record, not a paginated stream.
  • Model routing by issue complexity through routing rules over headers and metadata. Static and weighted routing are mature; learned routing isn’t part of the product.
  • Agent loop safety is partial. Per-task budgets and timeouts work; identical-call detection isn’t native.
  • Benchmark reproducibility + replay is good for the model-call layer. Full agent-trajectory replay requires pairing with a trajectory-capture layer outside the gateway.
  • OSS-friendly self-host through the Apache 2.0 OSS gateway.
  • Tool-call success/failure clustering is partial. Bifrost categorises by terminal status but not by agent-specific failure mode.
  • Tool-call and MCP passthrough is native. One of the few gateways that routes MCP tools/call as a first-class concept.

Where it falls short:

  • Eval layer is shallower than Future AGI for full-trajectory progress scoring. Maxim’s evals focus on per-call quality.
  • No prompt-and-routing optimizer in the gateway.
  • Native MCP is great for OpenHands; for SWE-Agent’s bespoke action-space the advantage is smaller because SWE-Agent’s tool protocol isn’t MCP-based.

Pricing: OSS gateway Apache 2.0 and free. Maxim platform starts free; team tier in the low hundreds per month.

Score: 5.5 / 7 axes (missing: full trajectory scoring, optimizer, agent-specific failure clustering).


Capability matrix

AxisFuture AGILiteLLMPortkeyKong AIMaxim Bifrost
Per-issue cost cap (hard cutoff)fi.alerts webhookPer-key budgetPer-key auto-pausePlugin comboBudget cutoff
Trajectory observabilityNative, 90-dayOTel-sinkPaginated above 3K spansOTel-sinkNative
Model routing by issue complexityTrajectory-feedbackRules + routerConditional routingPluginRouting rules
Agent loop safety (failure cutoffs)NativePartialPartialPluginPartial
Benchmark reproducibility + replayNative deterministicCall-level onlyPartialOTel-sinkCall-level + traces
OSS-friendly self-hostBYOC + Apache 2.0 OSSMIT OSSBYOC (not OSS)Apache 2.0 OSSApache 2.0 OSS
Tool-call failure clusteringHosted viewWire downstreamManual filterGrafanaPartial
Feedback loop / optimizerfi.optNoneNoneNoneNone

Decision framework: Choose X if

Choose Future AGI if your operating question has moved from “did this run merge a patch” to “is our SWE-Bench score moving in the right direction.” Trajectory scoring and failure-mode clustering are non-negotiable. The loop pays for itself the first time the optimizer drops Opus calls 30% on an over-prompting cluster and the SWE-Bench Verified resolved rate ticks up two points the same month.

Choose LiteLLM if your security regime forbids agent traffic from leaving the VPC and the platform engineer wants a Python proxy they can read in an afternoon. Source-availability beats hosted polish; the trajectory layer comes from pairing LiteLLM with traceAI.

Choose Portkey if you want a polished hosted gateway with per-issue budgets and procurement-ready RBAC, and your team’s job is to govern spend rather than score trajectory quality. The loop is a Phase 2 problem.

Choose Kong AI Gateway if your platform team already runs Kong and operational familiarity beats AI-specific depth. Path of least resistance.

Choose Maxim Bifrost if sustained CI throughput is the wall and the OpenHands deployment is MCP-heavy. Pair it with a trajectory-scoring layer for the benchmark story.


Common mistakes when wiring OpenHands or SWE-Agent through a gateway

MistakeWhat goes wrongFix
Tagging by session ID but not by issue IDPer-issue chargeback and per-issue replay both impossibleTag both; issue ID is the financial and benchmark unit
Soft alert only at 80% spendAgent burns past the alert; nothing in the loop is listeningHard-cutoff webhook at 110% that returns a structured stop
Truncating traces at a fixed span countSWE-Bench trajectory summarised after span 500; benchmark stops being reproduciblePick a gateway that retains full long-session traces with replay
Guardrail on the synchronous path200ms per turn becomes 2-3 extra minutes on a 600-call instanceUse a fast guardrail (Protect ~65 ms text) or move to async
Storing trace without scoring trajectory”Run failed” with no signal whether the agent looped or got stuckScore with fi.evals.TrajectoryScore or a custom rubric
Routing the planner step to the cheaper modelPlan quality drops, execute-step calls multiply, net cost is worsePin the planner; route execute-and-verify
Treating MCP tools/call as opaque JSONTool metadata lost; debug requires re-running the instancePick a gateway that parses MCP first-class (Bifrost, Future AGI)
Not freezing model versions for a sweepSilent mid-sweep model upgrade moves resolved rate 4 pointsPin model versions and seeds at the gateway; verify in trace metadata
Unbounded turn countA single instance burns $90 across 1,400 turnsMax-turns cap plus identical-call cutoff in the gateway

How Future AGI closes the loop on OpenHands and SWE-Agent spend

The other four gateways treat the trace as the end of the story: capture, surface, alert, optionally cap. Future AGI treats it as the input to a six-stage loop that bends both the cost curve and the SWE-Bench resolved-rate curve in the right direction at the same time.

  1. Trace. Every OpenHands or SWE-Agent run produces a full span tree via traceAI (Apache 2.0). Planner steps, every LLM call, every tool call, every MCP tools/call, terminal status, working-tree mutations. Issue ID, repo, and benchmark instance ID propagate through every span.

  2. Evaluate. fi.evals scores every trace against task completion, trajectory efficiency, tool-use accuracy, and code-correctness rubrics. fi.evals.TrajectoryScore is the one explicitly designed for SWE-Bench workloads.

  3. Cluster. Low-scoring trajectories cluster by failure mode: “agent looped on a failing pytest for 40 turns without changing the test file,” “agent refused after the planner mis-classified the issue as docs,” “agent timed out on the test runner,” “agent mis-used grep and ran out of context.”

  4. Optimize. fi.opt.optimizers (six optimizers (RandomSearchOptimizer, BayesianSearchOptimizer Optuna-backed with teacher-inferred few-shot templates and resumable studies, MetaPromptOptimizer, ProTeGi, GEPAOptimizer, PromptWizardOptimizer), all sharing an EarlyStoppingConfig (patience + min_delta + threshold + max_evaluations) and the same unified Evaluator over 60+ FAGI rubrics) rewrites the planner prompt or adjusts routing against the clusters. Typical OpenHands optimization: pin planner steps over 60K tokens to claude-opus-4-7, route execute-and-verify to claude-sonnet-4-6, add a “have you changed a file in the last three turns?” self-check, tighten the grep schema.

  5. Route. The gateway applies the updated policy on the next request. The agent runtime doesn’t change.

  6. Re-deploy. Versioned. Automatic rollback if the next 200 trajectories regress.

Net effect across three OSS autonomous-agent customers running this loop in Q1 2026: per-issue cost dropped 24 to 38% over six weeks, SWE-Bench Verified resolved rate moved up 2 to 4 percentage points in the same window, long-tail above the 95th percentile cost dropped by more than half.

Building blocks open under Apache 2.0:

  • traceAI, github.com/future-agi/traceAI
  • ai-evaluation / fi.evals, github.com/future-agi/ai-evaluation
  • agent-opt / fi.opt, github.com/future-agi/agent-opt

Hosted Agent Command Center adds the failure-cluster view, Protect guardrails (~65 ms text, arXiv 2510.13351), per-issue RBAC, SOC 2 Type II, and AWS Marketplace procurement.


What we did not include

We left out four gateways that show up in other 2026 listicles on this topic:

  • Helicone. Works well for interactive coding agents (covered in the Claude Code post). Not the right shape for multi-hour autonomous runs.
  • OpenRouter. Consumer-facing routing; not designed for benchmark-grade per-issue chargeback.
  • Cloudflare AI Gateway. Strong edge primitives but long-session trace story is thin; sessions over a few hundred calls get summarised.
  • TrueFoundry. Solid MLOps gateway but the autonomous-agent integration wasn’t stable in our May 2026 testing against OpenHands 0.18 and SWE-Agent 1.4.

All four worth a second look in Q3 2026.



Sources

  • OpenHands runtime (github.com/All-Hands-AI/OpenHands)
  • SWE-Agent reference implementation (github.com/princeton-nlp/SWE-agent)
  • SWE-Bench Verified benchmark (swebench.com)
  • Future AGI Agent Command Center (futureagi.com/platform/monitor/command-center)
  • Future AGI traceAI / ai-evaluation / agent-opt (github.com/future-agi)
  • Future AGI Protect latency benchmarks (arxiv.org/abs/2510.13351, 65 ms text, 107 ms image)
  • LiteLLM proxy (github.com/BerriAI/litellm)
  • Portkey AI gateway (portkey.ai)
  • Kong AI Gateway (konghq.com/products/kong-ai-gateway)
  • Maxim Bifrost (getmaxim.ai/bifrost)

Frequently asked questions

Why do OpenHands and SWE-Agent need an AI gateway?
The gateway is the only layer that can attribute cost per issue, enforce hard per-issue spend caps, score trajectory quality, cluster failure modes across a benchmark sweep, and preserve full trajectories for SWE-Bench reproducibility. The agent runtimes intentionally leave that responsibility to the layer below.
Do OpenHands and SWE-Agent support OpenAI-compatible endpoints?
Yes. OpenHands' LLM client reads `OPENAI_BASE_URL` or `ANTHROPIC_BASE_URL`. SWE-Agent supports the same through `model_name` and `api_base`. All five gateways here can sit in front of either.
How do I cap a SWE-Bench Verified instance at $5 without breaking the agent mid-step?
Use a gateway with hard-cutoff webhooks (Future AGI, Portkey, Bifrost). Soft alert at 70% lets the agent finish the current step; hard cutoff at 110% returns a structured stop if the soft signal is ignored. Both agents treat the structured stop as terminal and roll back cleanly.
What is TrajectoryScore and why does it matter for SWE-Bench?
TrajectoryScore asks at each step whether the agent was making progress or revisiting prior nodes. A flat or declining score on a long trajectory is the strongest available signal of a loop. Future AGI's `fi.evals.TrajectoryScore` is the only out-of-the-box implementation among the five picks and maps directly onto the SWE-Bench failure-analysis pattern.
Is it safe to send proprietary source code through a hosted AI gateway?
The data flow is gateway then LLM provider; both endpoints already see the code. If your compliance regime forbids both, the safe picks are self-hosted LiteLLM, self-hosted Kong, self-hosted Bifrost, or Future AGI BYOC running inside your VPC.
How is Future AGI different from LiteLLM for an OSS autonomous coding agent?
LiteLLM handles routing, budgets, and metadata pass-through. Future AGI adds trajectory scoring, failure-mode clustering, and the optimizer that rewrites prompts and routing rules. A common pattern: run LiteLLM in the VPC as the per-issue spend enforcer and ship spans to Future AGI `traceAI` for the trajectory layer.
How is Future AGI different from Maxim Bifrost for OpenHands?
Bifrost is a fast Go gateway with strong MCP routing. Future AGI adds trajectory scoring, failure-mode clustering, and the optimizer. If throughput and MCP are the constraint, Bifrost. If the operating question is 'is our SWE-Bench resolved rate climbing,' Future AGI.
Related Articles
View all
The Comprehensive Guide to LLM Security (2026)
Guides

LLM security is four layers — input, output, retrieval, tool-call. Defenders that secure all four ship reliably; defenders that secure only the input layer lose to anything beyond a hello-world attack.

NVJK Kartik
NVJK Kartik ·
17 min