OpenAI Agents API

Original Article ↗ Hacker News Discussion ↗

OpenAI’s new Agents API, which offers managed “agent” runtimes and sandboxes on top of its models, is seen as a powerful way to offload scaling, security patching, and environment management—but also as a strong push toward vendor lock‑in. Commenters weigh the convenience of a hosted harness against concerns about data security, opaque “reasoning tokens,” confusing pricing, and the loss of control compared with running their own local or open‑source agent frameworks. Many point to emerging vendor‑neutral runtimes and self‑hosted sandboxes as preferable for long‑term flexibility, even if they require more engineering effort today.

API vs SDK, and Managed Sessions

  • Some see the Agents API as redundant with the existing SDK and CLI, preferring local SDK-based development where they control the harness.
  • Others argue the API reduces operational burden: OpenAI manages scaling, security patching, and session orchestration. A suggested pattern is “develop via SDK, deploy via API.”

Vendor Lock‑in, Trust, and Data Control

  • Strong concern that this deepens lock‑in and nudges people away from owning their harness and state.
  • Several commenters say they prefer lightweight, replaceable harnesses on top of base LLM APIs to avoid dependency on any single lab.
  • Data‑leak risk is raised: automatic tool calls or networked agents could send sensitive data to external services without explicit user control.

Sandbox Environments and Security

  • Network controls (enabled/disabled/restricted) attract scrutiny given past reports of agents altering /etc/hosts to bypass restrictions.
  • Some doubt OpenAI’s ability to fully secure these sandboxes; others note at least some basic bypass attempts are blocked.
  • A self‑hosted environment option is viewed positively, especially for private networking and stricter control.

Pricing, Limits, and Subscriptions

  • Confusion over environment billing (20‑minute units, minimum ~5 minutes per activation). Unclear to some whether each session creates a fresh billable environment or how to shut it down early.
  • Consumer subscriptions (Codex, ACP, etc.) generally cannot be used with this API; seen as favoring larger customers.
  • Multiple reports that Codex usage on some accounts now burns through quota disproportionately, though causes are debated and unclear.

Use Cases and Scaling

  • Positive reactions from people running many concurrent agent sessions (e.g., code agents or crawlers) who are currently limited by their own VPS capacity.
  • Others think hosting agents themselves (VMs, Docker, local harnesses) is easy enough that managed agents add little value.

Abstractions, Harnesses, and Alternatives

  • Broad agreement that “agent harness” design is tricky and evolving; no consensus abstraction yet.
  • Some say building a good harness is a deep rabbit hole; others report success with minimal custom harnesses or open‑source frameworks and argue every serious developer should own their harness.
  • Several vendor‑neutral or open‑source agent platforms and “agents‑as‑a‑service” competitors are mentioned as preferable for model flexibility and owning long‑term state.

Local vs Remote Control

  • Some view remote, lab‑hosted harnesses as backwards: their main pain is granting remote agents access to local data. They would prefer local agents with optional remote sandboxes.
  • Others emphasize convenience: being able to trigger and monitor agents from Slack, web, or phone, and not worrying about uptime or orchestration.