# HarnessRouter Full LLM Context > HarnessRouter is the world's first unified interface for agent harnesses. Canonical site: https://harnessrouter.ai Compact context: https://harnessrouter.ai/llms.txt Sitemap: https://harnessrouter.ai/sitemap.xml ## Product Definition HarnessRouter is the world's first unified interface for agent harnesses. The category is the unified interface, and it is delivered through three inseparable product layers: 1. **One Agent API:** one Task, Run, Session, Streaming, File, Artifact, Error, and Trace contract across every supported harness. 2. **Serverless sandboxed execution:** on-demand execution in isolated environments without making product teams deploy and operate each harness runtime separately. 3. **Tracing for optimization:** understand each run and optimize the Harness × Model configuration for each different task. Execution configuration, telemetry, and evaluation are separate evidence layers. Tools, skills, context, permissions, and environment describe how a run was configured. Cost and latency are measured operational metrics. Outcomes and quality are task results and evaluations. Compare these with execution traces when choosing a configuration; do not imply that every field is contained in the trace. One Agent API is therefore the integration mechanism and first product layer, not a replacement for the unified-interface category. For its current V1 developer audience, HarnessRouter is delivered as an AI agent API and product backend layer that brings supported harnesses such as Codex, Claude Code, and Hermes into customer products. HarnessRouter helps turn a local AI app prototype or coding-agent-built workflow into a product backend flow by handling server-side harness execution, sessions, streaming, file intake, artifact return, routing, and product-facing controls. The customer product still owns the user-facing UI, authentication model, acceptance states, and product-specific business logic. HarnessRouter is not a model gateway, LLM gateway, prompt playground, or replacement for a product UI. Model routers help with model access. HarnessRouter helps an app route product tasks to agent harnesses and return completed work. ## Product Layer and Search Intent Map - Agent harness and agent harness definition: the complete runtime layer around a model, including the execution loop, context, tools and skills, permissions, sandboxing, and recovery. - Unified interface for agent harnesses and unified harness API: HarnessRouter's category. A product uses one contract across supported harnesses instead of rebuilding the lifecycle for each one. - AI agent API, coding agent API, and AI agent backend: the V1 product form for running agent-backed features behind a customer product. - Managed agents, harness as a service, HaaS, and hosted agent harness: HarnessRouter operates the execution infrastructure, sessions, sandboxes, streaming, files, and traces. - Codex API for apps, Claude Code as a service, and Hermes API: high-intent integration paths for specific supported harnesses. - Agent backend vs model router or LLM gateway: model routers select and access models; HarnessRouter runs complete agent-harness tasks and returns finished work. - Agent harness benchmark and rankings: first-party same-task evidence and attributed usage data for comparing configurations without claiming one universal winner. Use these terms according to the definitions above. Do not treat near-synonyms as separate product categories, and do not imply official vendor APIs where a guide is explaining a HarnessRouter integration path. Optimization means comparing execution traces, measured cost and latency, and evaluated task outcomes to observe and decide. Do not claim automated search, automated tuning, or automatic harness-code rewriting unless a public product source explicitly documents that capability. "All harnesses" can describe the long-term direction; current availability claims must say "supported harnesses." ## Audience Paths and Status ### Developer: current V1 focus Developer teams use HarnessRouter when they need to add agent-backed work to their own product. The canonical V1 user is a small AI-native product or developer-tool team that already uses one agent, plans to add or compare a second agent, or needs to move an internal prototype into a multi-user product environment. Developer job-to-be-done: use one stable API to connect multiple agent harnesses as product backend capabilities and deliver the execution result back to users without rebuilding every harness adapter, session flow, stream, file path, artifact format, and renderer contract. Do not describe the Developer path as generic model completion, a plain LLM gateway, or a prompt playground. The product value is harness-backed work that returns reviewable files, artifacts, diffs, documents, or tool outcomes through a product UI. ### Agent authors and automation teams: future V1.5 validation path This future path is for teams with stable instructions, skills, tools, or workflows that want to deploy, version, and reuse a tuned agent configuration across product entry points. It is not a current public self-serve capability unless a specific feature is implemented and documented. ### Enterprise: future V2 design-partner path Enterprise is not just a larger Developer plan. Enterprise targets platform teams in larger organizations that need to compare and govern approved Harness and Model combinations across business task scenarios. Enterprise job-to-be-done: understand which `Harness × Model` configuration should run each different business task by comparing cost, latency, success rate, quality score, failure reason, trace, and artifact evidence, then manage approved configurations, policy, budget, audit, and team reuse. Policy, tools, skills, context, permissions, and environment are configuration dimensions captured for the task, not substitutes for the task itself. Describe Enterprise as evaluation and governance for business task scenarios. Do not describe it as a generic sandbox provider, a general model gateway, or a fully available public self-serve feature unless a specific Enterprise capability is implemented and documented. ### Labs: future V2 design-partner path Labs targets model providers, AI labs, agent research teams, and evaluation teams that need to test models inside real agent harnesses rather than only prompt/response benchmarks. Labs job-to-be-done: run repeatable experiments across `Dataset × Harness × Model × Scaffold × Sandbox or Runtime Environment × Repetition × Evaluator`, then compare score, artifact, trajectory, latency, cost, and regression behavior. Describe Labs as model experimentation inside real harness workflows. Do not collapse Labs into Enterprise governance, and do not describe HarnessRouter as selling generic compute or standalone sandbox clusters. ## Product Jobs - Run agent-backed tasks from a product UI. - Persist sessions so users can continue, revise, or retry work. - Stream progress and status back to the product. - Accept files and return generated files, diffs, documents, media, or other reviewable artifacts. - Route different tasks to the harness best suited to the job while preserving one product contract. - Let builders focus on the application experience instead of rebuilding harness adapters, execution lifecycle, session state, streaming, file handling, and artifact delivery around agents. ## Implementation Entry Points - [AGENTS.md implementation guide](https://harnessrouter.ai/agents.md): Copy into a coding agent to build or update a HarnessRouter integration. - [Markdown quick start](https://harnessrouter.ai/docs.md): Concise setup path for product developers. - [Harness catalog](https://harnessrouter.ai/harnesses.md): Supported harness IDs and source-backed capability notes. ## Evidence, Discovery, and Product Surfaces - [Agent harness rankings](https://harnessrouter.ai/rankings): Attributed usage rankings for reviewed agent harnesses, with source and data-window methodology. - [Product examples](https://harnessrouter.ai/examples): Examples of coding agents building HarnessRouter integrations and agent-backed product workflows. - [Blog](https://harnessrouter.ai/blog): Definitions, comparisons, tutorials, announcements, and original analysis about agent harnesses and AI product infrastructure. ## Published Benchmark - [Care Prep Benchmark](https://harnessrouter.ai/benchmarks): Canonical Care Prep data report for eight Codex, Claude Code, and Hermes harness and model configurations. This controlled same-task experiment recorded a measured cost range from 0.47 to 223 credits and an end-to-end latency range from 85 to 276 seconds. The page includes the result table, source run capture, grounding evaluation, methodology, and interpretation limits. These results apply to this task and configuration set, not to every workload. # HarnessRouter Integration Docs > Quick start for adding HarnessRouter to a product with a coding agent. Canonical URL: https://harnessrouter.ai/docs Agent copy target: https://harnessrouter.ai/agents.md Use this page as a concise quick-start summary. To implement HarnessRouter in a product, copy the complete AGENTS.md instructions from https://harnessrouter.ai/agents.md into Codex, Claude Code, or another coding agent. ## Quick start ### 1. Paste AGENTS.md into your coding agent Copy the official instructions and paste them into Codex, Claude Code, or another coding agent. ### 2. Ask it to build Describe the product or feature you want. The coding agent will build the product interface and connect your backend to server-side agents through HarnessRouter. ### 3. Add your API key securely When the coding agent opens a secure secret modal, create a Workspace API key and paste it into that modal. The agent stores it as HR_API_KEY and continues the build. ## Security Note Paste the key only into the secure modal opened by your coding agent. Never paste it into normal chat, source files, AGENTS.md, browser code, logs, or screenshots. ## Key Resources - [AGENTS.md](https://harnessrouter.ai/agents.md): Canonical implementation instructions. - [Harness catalog](https://harnessrouter.ai/harnesses.md): Harness IDs, status, and source-backed references. - [Guides](https://harnessrouter.ai/guides): Architecture and integration guides. ## Human Docs Directory - [Product vs runtime agent](https://harnessrouter.ai/docs/host-app-vs-runtime-agent): Your product keeps the user experience, auth, data, permissions, and workflow. At runtime, it sends HarnessRouter one authorized end-user task. - [Workspace](https://harnessrouter.ai/docs/workspace): Workspace API keys, configured agents, sessions, and returned files all live inside the Workspace that serves your product. - [Configured agent / harness](https://harnessrouter.ai/docs/configured-agent-harness): It combines a base harness, model policy, instructions, tools, skills, and permissions. Your server calls it with the `harness_id` path segment. - [Session and response](https://harnessrouter.ai/docs/session-and-response): Save the response ID and session ID from the stream. Your product needs both to recover, continue, cancel, and fetch artifacts. - [Files and artifacts](https://harnessrouter.ai/docs/files-and-artifacts): Fetch generated files from your server, check product ownership, then preview or download them inside your product UI. - [Authentication](https://harnessrouter.ai/docs/authentication): The browser should never call HarnessRouter directly with the Workspace API key. - [Base URL](https://harnessrouter.ai/docs/base-url): Build all runtime and management requests against the HarnessRouter API host. - [Harnesses](https://harnessrouter.ai/docs/harnesses-api): Use harness management endpoints from trusted server code or an authorized admin surface. - [Models](https://harnessrouter.ai/docs/models): Ask the API for current models and for the models allowed by a configured agent. Treat the choice as part of your product evidence loop. - [Run a task](https://harnessrouter.ai/docs/run-a-task): Use the configured agent ID as the first path segment. Prefer streaming when users need visible progress. - [Streaming events](https://harnessrouter.ai/docs/streaming-events): HarnessRouter streams Server-Sent Events in an OpenAI Responses-style wire format with `data:` frames only. - [Continue a session](https://harnessrouter.ai/docs/continue-a-session): Use continuation for revise, follow-up, incomplete work, or reconnecting to a task context. - [Upload files](https://harnessrouter.ai/docs/upload-files): Use file upload for documents, data, source bundles, and other user-authorized inputs. - [Sessions and files](https://harnessrouter.ai/docs/sessions-and-files): Use session endpoints after saving `response.metadata.session_id` from the stream. - [Cancel a session](https://harnessrouter.ai/docs/cancel-a-session): Closing an SSE connection does not stop the server-side agent. Use cancel when the user intentionally stops work. - [Errors and idempotency](https://harnessrouter.ai/docs/errors-and-idempotency): Every initial runtime request should include an idempotency key. Reuse it only when retrying the exact same request. - [Server-side proxy pattern](https://harnessrouter.ai/docs/server-side-proxy-pattern): Your backend validates the product user, maps the feature to a configured agent, calls HarnessRouter, and returns a product-shaped result. - [Feature key to harness mapping](https://harnessrouter.ai/docs/feature-key-to-harness-mapping): The browser should name the product action. The server should choose the configured agent. - [Streaming UI](https://harnessrouter.ai/docs/streaming-ui): Your UI should show task progress, save recovery identifiers, and tolerate new stream event types without breaking. - [File preview and download](https://harnessrouter.ai/docs/file-preview-and-download): Generated artifacts are product data. Your server should authorize every preview and download before relaying bytes. - [Continue / revise](https://harnessrouter.ai/docs/continue-revise): Continue and revise should feel like one product task evolving, not a new unrelated run. - [Multi-tenant authorization](https://harnessrouter.ai/docs/multi-tenant-authorization): HarnessRouter returns opaque session and file IDs. Your server decides which product user or tenant may continue, cancel, preview, or download them. - [Choosing a harness](https://harnessrouter.ai/docs/choosing-a-harness): Run representative tasks through your real product path. Choose from dashboard Trace, stream behavior, recovery, files, artifacts, cost, and quality. - [Tracing and optimization](https://harnessrouter.ai/docs/tracing-and-optimization): Use the dashboard control plane and your saved product records before changing instructions, model policy, tools, permissions, or runtime limits. - [Production checklist](https://harnessrouter.ai/docs/production-checklist): Use this as a short release checklist for products that call HarnessRouter. - [LLM resources](https://harnessrouter.ai/docs/llm-resources): Use these resources when an AI coding agent, search crawler, or documentation tool needs compact HarnessRouter context. # HarnessRouter Harness Catalog > Source-backed harness IDs and integration notes for HarnessRouter. Canonical URL: https://harnessrouter.ai/harnesses ## Codex (codex) Status: Available Provider: OpenAI Category: Coding agent Last checked: 2026-07-30 Canonical URL: https://harnessrouter.ai/harnesses/codex OpenAI documents Codex as a coding agent that can read, edit, and run code across web, IDE, and CLI surfaces. Confirmed notes: - Codex web can work on tasks in the background using a cloud environment. - The IDE extension can pair with Codex locally or delegate tasks to Codex Cloud. - The CLI can inspect a repository, edit files, and run commands from a terminal session. Integration note: Use the `codex` harness ID only when the product task should return code-related work your app can review. Sources: - [Codex web](https://developers.openai.com/codex/cloud): Official or source-backed reference. - [Codex IDE extension](https://developers.openai.com/codex/ide): Official or source-backed reference. - [Codex CLI](https://developers.openai.com/codex/cli): Official or source-backed reference. ## Claude Code (claude-code) Status: Available Provider: Anthropic Category: Coding agent Last checked: 2026-07-30 Canonical URL: https://harnessrouter.ai/harnesses/claude-code Anthropic documents Claude Code as an agentic coding tool that works in a real working tree with the shell, editing files, running tests, and coordinating sub-agents to complete engineering tasks end to end. Confirmed notes: - Claude Code operates on a real local working tree: it reads and edits files, runs commands, and iterates until the task is done. - It can delegate to sub-agents and use tools such as Bash, file read/write, search, and web fetch. - HarnessRouter runs it with the `docx`, `pdf`, `pptx`, and `xlsx` document skills preloaded, so a task can return finished documents your app renders. Integration note: Use the `claude-code` harness ID when the product task should return code changes or finished documents your app can review. Sources: - [Claude Code overview](https://docs.claude.com/en/docs/claude-code/overview): Official or source-backed reference. - [Claude Code CLI reference](https://docs.claude.com/en/docs/claude-code/cli-reference): Official or source-backed reference. ## Hermes (hermes) Status: Available Provider: Nous Research Category: Autonomous agent Last checked: 2026-07-30 Canonical URL: https://harnessrouter.ai/harnesses/hermes Nous Research documents Hermes as a self-improving autonomous agent with CLI usage, toolsets, a skills system, persistent memory, MCP integration, and configurable model providers. HarnessRouter supports Hermes as an available base harness. Confirmed notes: - Hermes works on a real project workspace with shell and file access, completing tasks end to end. - It builds a persistent memory and skill library from what it learns, getting more capable the longer it runs, and supports MCP servers. - HarnessRouter has completed Hermes adapter and capability configuration with unified request, streaming, session, file and artifact, and error-handling coverage. - Do not hardcode a Hermes model default. Fetch the current model catalog and allowed models from the HarnessRouter API. Integration note: Use the `hermes` harness ID when the product task should run through the Hermes autonomous-agent harness and return reviewable work through the HarnessRouter product contract. Sources: - [Hermes Agent docs](https://hermes-agent.nousresearch.com/docs/): Official or source-backed reference. - [Hermes Agent GitHub](https://github.com/nousresearch/hermes-agent): Official or source-backed reference. ## Pi (pi) Status: Coming soon Provider: pi.dev Category: Coding agent Last checked: 2026-07-30 Canonical URL: https://harnessrouter.ai/harnesses/pi Pi is a personal, extensible coding agent designed to be shaped around an individual developer’s workflow. Its HarnessRouter route is coming soon. Confirmed notes: - HarnessRouter support for Pi is coming soon. - Its HarnessRouter route is not yet available for production tasks; the supported routing contract will be documented before launch. Integration note: The `pi` harness ID is reserved and not yet routable. Do not target it in production integrations until it is marked available. Sources: - [Pi website](https://pi.dev/): Official or source-backed reference. # Claude Code as a Service: Headless, Multi-Tenant, via API > How to run Claude Code headless behind your product: the API contract, multi-tenant authorization, per-task sandbox isolation, document skills, and configuration comparison. Canonical URL: https://harnessrouter.ai/guides/claude-code-as-a-service Published: 2026-08-12 Updated: 2026-08-12 Category: Integration Keywords: claude code as a service, claude code api, claude code headless, claude code multi-tenant, run claude code in the cloud, claude code backend, claude code behind an api, hosted claude code ## Short Answer Claude Code as a service means running Anthropic's Claude Code harness headless behind an HTTP API instead of at a terminal: your product submits tasks, streams progress to end users, persists sessions and files, and receives results and artifacts, while each task executes in an isolated sandbox. HarnessRouter provides this as a managed service through one API. ## Takeaways - Claude Code is a complete agent harness that works on a real working tree: it edits files, runs commands, delegates to sub-agents, and iterates until the task is done. - Turning it into a service adds what the terminal never needed: an HTTP contract, multi-tenant authorization, per-task isolation, and durable sessions. - Through HarnessRouter, a Claude Code task returns whatever the work produces: code changes, generated files, and reviewable artifacts. Document skills come preloaded, and the capability surface extends further: a configured agent can load custom skills and connect MCP tools your product chooses. ## A terminal tool and a service are different jobs Anthropic documents Claude Code as an agentic coding tool that works in a real working tree with the shell: reading and editing files, running tests, and coordinating sub-agents to complete engineering tasks end to end. It even ships a headless print mode (claude -p with JSON output) for scripts and CI. That is a complete agent harness, and for a developer at a terminal or a pipeline it needs nothing more. Headless, however, is still not a service: the process runs on infrastructure you operate, invoked by whoever controls that machine, with no product contract around it. A service needs four things the CLI does not provide: - An HTTP contract: tasks submitted by your server, not commands typed by a developer. - Multi-tenancy: many end users and tenants sharing the capability without seeing each other's work. - Isolation: each task in its own sandbox, keeping runs separated from other users' work and from your infrastructure. - Product-level durability: sessions, files, and results held for each end user, which your server can authorize, continue, and hand back, beyond the machine-local persistence the CLI keeps for its operator. ## The API shape Through HarnessRouter, Claude Code runs behind the same contract as every other harness: - Input: A product task, the claude-code harness selection, a model from the current catalog, optional files, and execution policy. - Lifecycle: A durable session with status, streamed progress events, continuation, and cancellation. - Output: Code changes, finished documents, generated files and artifacts, and a recorded execution trace for every run. ## Multi-tenant authorization and isolation Two responsibilities split cleanly between your server and the platform. The platform isolates execution: an isolated sandbox spins up for each task automatically, and there is no execution infrastructure for your team to size, patch, or babysit. Your server owns tenant authorization, following the server-side proxy pattern: - Keep the API key server-side; browsers never call the execution API directly. - Derive the current user and tenant from your product's trusted session, never from browser-submitted identifiers. - Map every session, response, and file ID returned by the API to its owning user or tenant, and check that mapping before every continue, cancel, preview, or download. - Return a product-level denial when ownership cannot be proven. ## Documents, custom skills, and MCP tools Claude Code as a service is not limited to code changes. HarnessRouter runs Claude Code with the docx, pdf, pptx, and xlsx document skills preloaded, so a product task can return finished documents your app renders and your users download: the same harness that refactors a repository can produce a formatted report from uploaded files. And the preloaded set is a floor, not a ceiling. A configured agent can load custom skills and connect MCP servers, so the task surface grows with whatever your product wires in, from media workflows to browser and computer-use style tooling available in the MCP ecosystem. ## Treat the configuration as a hypothesis No single harness or model setup wins every task. Claude Code pairs with a model you select per task, and the right pairing is workload-specific: in HarnessRouter's same-task benchmark, cost across harness and model configurations varied by about 475x on identical work, and results vary by task. Because every harness runs behind the same contract, the comparison is a parameter change: run your real task on Claude Code and on other configurations, read the recorded traces, and promote the winner on evidence. ## Running your first Claude Code task - Create a key and send a task to the claude-code harness through the quickstart; building and integration are free, and credits are used only when tasks run. - Stream progress into your product UI, then fetch results, files, and artifacts when the run completes. - Continue the session for revisions instead of restarting from zero. - Use the claude-code harness ID when the task should return code changes or finished documents your app can review. ## FAQ ### Does Claude Code have an official API? Anthropic offers several first-party paths: the Claude Code CLI with a headless print mode for scripts and CI, the Claude Agent SDK as a library that runs the agent loop in your own infrastructure, and Managed Agents, a hosted REST API where Anthropic runs the agent and the sandbox. What HarnessRouter adds is the cross-vendor layer: one contract that runs Claude Code alongside Codex and Hermes, with the same sessions, streaming, files, and execution traces across all of them, so your product can compare configurations and switch without a rewrite. ### Is running Claude Code multi-tenant safe? Execution is isolated by the platform: each task runs in its own sandbox provisioned on demand. Tenant separation at the product level is your server's job: derive identity from your trusted session, map returned session and file IDs to their owners, and check that mapping before every operation on existing work. ### Can end users continue or revise previous Claude Code work? Yes. Sessions and files persist across runs, so your product can offer continue and revise flows: the user returns, your server checks ownership of the session, and the next task picks up where the last one finished. ### How do I know Claude Code is the right harness for my feature? Measure instead of assuming. Run a representative task on Claude Code and on other harness and model configurations through the same API, apply a success threshold, then compare cost, latency, and artifact quality from the recorded traces. The published same-task benchmark shows the format. # Hermes API: Run the Hermes Agent Behind Your Product > How to run Nous Research's Hermes agent through an API: what Hermes is, the task and session contract, model pairing, and what its benchmark results show about cost and speed. Canonical URL: https://harnessrouter.ai/guides/hermes-api Published: 2026-08-12 Updated: 2026-08-12 Category: Integration Keywords: hermes api, hermes agent, hermes ai agent, hermes agent ai, run hermes, nous research hermes, hermes coding agent, hermes harness ## Short Answer To run Hermes behind a product, use it as a hosted agent harness: HarnessRouter exposes Hermes through a unified API with tasks, sessions, streaming, files, and results, so your application sends a task over HTTP and gets back a recorded, reviewable run without operating the harness itself. ## Takeaways - Hermes is Nous Research's autonomous agent: a complete harness with toolsets, a skills system, persistent memory, MCP integration, and configurable model providers. - Through HarnessRouter, Hermes runs behind one API with unified requests, streaming, sessions, files, artifacts, and error handling. - Pair Hermes with a model deliberately: in the published same-task benchmark, Hermes configurations recorded both the fastest run and the lowest-cost successful run, with very different profiles. ## What Hermes is Hermes is an autonomous agent from Nous Research, documented as a self-improving agent with CLI usage, toolsets, a skills system, persistent memory, MCP integration, and configurable model providers. In harness terms it is a complete agent harness: it runs the loop, manages context, exposes tools and skills, and works on a real project workspace with shell and file access, completing tasks end to end. Search interest in Hermes broke out during 2026, and the practical question that follows is how to run it programmatically. - General agent work, not only coding: Hermes operates on a workspace with shell and file access. - Skills and toolsets extend what the model can do inside a task. - Model choice is configurable, which makes Hermes a natural fit for configuration-level comparison. ## The API shape: tasks in, recorded runs out HarnessRouter supports Hermes as an available base harness with completed adapter and capability coverage: unified request, streaming, session, file and artifact, and error handling. The contract represents work, not messages: - Input: A product task, the hermes harness selection, a model from the current catalog, optional files, and execution policy. - Lifecycle: A durable session with status, streamed progress events, continuation, and cancellation. - Output: Structured results, generated files and artifacts, and a recorded execution trace for every run. ## Pair Hermes with a model deliberately Do not hardcode a model default; fetch the current catalog and allowed models from the API. The pairing decides the run's profile. In HarnessRouter's published same-task benchmark, eight harness and model configurations ran identical work five times each, and Hermes configurations recorded both ends of the useful frontier: - The fastest configuration in the benchmark was Hermes with GPT-5.5, completing the task in 85 seconds. - The lowest-cost successful run was Hermes with GPT-5.2 at 0.47 credits, 99.8% below the costliest recorded configuration. - The fastest and the cheapest were different configurations, so pick per task: latency-sensitive features and cost-sensitive batch work want different pairings. Results vary by task. ## Running your first Hermes task - Create a key and send a task to the hermes harness through the quickstart; building and integration are free, and credits are used only when tasks run. - Stream progress into your product UI, then fetch results, files, and artifacts when the run completes. - Continue the session for follow-up work instead of restarting from zero. - Compare a Hermes configuration against Codex and Claude Code on your own task through the same API, with each run's execution trace recorded for the comparison, before committing a workload. ## FAQ ### Is Hermes an agent harness? Yes. Hermes is a complete agent harness from Nous Research: it runs the execution loop, manages context and memory, exposes toolsets and skills, and completes tasks on a real workspace with shell and file access. ### Can I choose which model Hermes uses? Yes. Hermes supports configurable model providers, and through HarnessRouter you select the model per task from the current catalog. Fetch the catalog from the API rather than hardcoding a default. ### What does it cost to run Hermes through HarnessRouter? Building and integration are free; credits are used only when tasks run. In the published same-task benchmark, the lowest-cost successful run was a Hermes configuration at 0.47 credits, though cost varies by task and model pairing. ### How is running Hermes through an API different from using its CLI? The CLI is for a developer at a terminal. The API is for a product: your application submits tasks over HTTP, streams progress to end users, persists sessions and files, and receives artifacts and execution traces, without installing or operating the harness. # What Is an Agent Harness? Definition, Anatomy, Examples > An agent harness is the runtime layer around a model that turns it into a working agent: the loop, context, tools, permissions, sandboxing, and recovery. Definition, origins, examples, and how it fits the stack. Canonical URL: https://harnessrouter.ai/guides/what-is-an-agent-harness Published: 2026-08-12 Updated: 2026-08-12 Category: Concepts Keywords: what is an agent harness, agent harness, agent harness definition, agent harness examples, agent harness vs framework, harness layer, claude harness, codex harness ## Short Answer An agent harness is the runtime layer built around a model that turns it into a working agent: the execution loop, context management, tools and skills, permissions, sandboxing, and failure recovery that carry a task from request to finished result. The model reasons; the harness is everything that lets that reasoning complete real work. ## Takeaways - Agent = Model + Harness. The model is not part of the harness; the harness is everything around it. - A complete harness does six jobs: runs the loop, manages context, exposes tools and skills, enforces permissions, sandboxes execution, and recovers from failure. - What runs in production is a configured agent: a base harness, a model, and your product's settings. In HarnessRouter's same-task benchmark, cost across such configurations varied by about 475x, so the combination is worth measuring, not assuming. ## Two formulas that keep the terms straight The industry converged on one structure in 2026: the harness wraps the model, and together they make an agent. Vendors word it differently, scaffolding, wrapper, runtime layer, but every mainstream definition puts the model outside the harness. Two formulas cover the vocabulary: - Agent = Model + Harness: The identity formula. A model alone produces text; an agent completes work. The harness is the difference. - Harness = loop + context + tools and skills + permissions + sandbox + recovery: The anatomy formula. Six jobs, no model inside. Each job is detailed below. ## The six jobs of a complete harness A demo harness runs a loop. A complete harness does six jobs, and the last four are where most of the engineering lives: - Runs the execution loop: plan, act, check the result, repeat until the task is done. - Manages context: decides what to store, retrieve, and show the model at each step, so a long task stays on track. - Exposes tools and skills: the functions, commands, and packaged abilities the model can call. Mechanically, a skill is packaged instructions and scripts delivered through the context and tool machinery; to the model it is one callable surface. - Enforces permissions: what the agent may read, write, and execute, and nothing else. - Sandboxes execution: code the agent writes and runs is isolated, so the blast radius of a wrong command is a sandbox, not your infrastructure. - Recovers from failure and decides completion: retries, fallbacks, and the judgment call of when the work is actually finished. ## Where the term comes from The term entered mainstream usage in 2026 and its history is short enough to state precisely: - Mitchell Hashimoto, co-founder of HashiCorp, is widely credited with popularizing the term in a February 2026 essay on agent infrastructure. - LangChain and other framework authors used harness language in the same period for the code that operates a model in a loop. - The shorthand Agent = Model + Harness spread across engineering blogs and talks during 2026 and is now the standard way to separate the reasoning component from the execution machinery. - By mid-2026, definitions from Microsoft, Databricks, Salesforce, and independent practitioners had converged on the same structure: the harness wraps the model and turns it into an agent. ## Complete harnesses you already know The clearest examples are the terminal agents developers already know. Claude Code, Codex, and Hermes are complete agent harnesses: each ships all six jobs as one continuously engineered product. The Pragmatic Engineer's March 2026 tooling survey found Claude Code the most-used AI tool among surveyed engineers, which puts a complete harness at the top of engineers' AI tool adoption, even if few users call it a harness. - Claude Code: Anthropic's harness, driving Claude models through terminal-native tasks with tools, permissions, and sandboxing. - Codex: OpenAI's harness for autonomous coding tasks across a repository. - Hermes: a harness for general agent work whose search interest broke out during 2026. - A framework like LangGraph or CrewAI is not a harness but a kit for building one: it becomes a harness only after you assemble and operate the six jobs yourself. ## What an agent harness is not Four neighboring terms get confused with the harness, and each sits at a different layer: - Model API: Returns inference for a single call. No loop, no tools, no state. The harness is the machinery that calls it many times toward a goal. - Agent framework (LangGraph, CrewAI): A library for building your own execution logic. A framework is parts; a harness is the running whole. - Model router or AI gateway: Selects and fronts model calls. It optimizes the inference layer; it does not run tasks. - Sandbox: An isolation environment. Sandboxing is one of the harness's six jobs, not a separate layer above it. ## Why the harness choice is worth measuring What actually executes a task is a configured agent: a base harness, the model it drives, and the instructions, tools, and skills your product enables. The harness side is not neutral plumbing; it decides how many steps, tool calls, and tokens a task consumes on the way to a result. In HarnessRouter's same-task benchmark, eight harness and model configurations ran identical work five times each: measured cost varied by about 475x across configurations, and the lowest-cost successful run used 99.8% fewer credits than the costliest configuration. Results vary by task. What generalizes is that cost and success are properties of the configuration, the harness and model pair, not of the model alone. - Hold the model constant and swapping only the harness moved cost by up to about 2.1x and latency by up to about 1.9x in the recorded runs. - Success rates differed by setup, and the costliest configuration was not the best one. - The practical conclusion: treat harness choice like model choice, as something you evaluate on your own tasks. ## Where the harness sits in an AI product In a production AI product, the harness layer sits above the model and context layers and below your application. Using complete harnesses as product infrastructure normally means one integration per harness, because each exposes tasks, sessions, files, and streaming differently. HarnessRouter is the world's first unified interface for agent harnesses: through one API, a product runs complete agent tasks on Codex, Claude Code, or Hermes, with sessions, streaming, files, and results behaving the same way across every harness, and each task executing in an isolated sandbox the platform manages. - One contract across harnesses turns switching or comparing configurations into a parameter change. - Execution tracing records every run, so configuration choices rest on evidence rather than defaults. - The harness layer stays the vendors' continuously engineered software; the unified interface is how your product consumes it. ## FAQ ### Does an agent harness include the model? No. Every mainstream definition, from Microsoft, Databricks, Salesforce, and independent practitioners, puts the model outside the harness: the harness wraps the model and turns it into an agent. What runs in production is a configured agent: a base harness, a model, and the instructions, tools, and skills your product enables; that configured agent is what actually executes tasks. ### Is Claude Code an agent harness? Yes. Claude Code is a complete agent harness: it runs the execution loop, manages context, exposes tools, enforces permissions, sandboxes execution, and recovers from failure, driving Claude models through real tasks. Codex and Hermes are complete harnesses in the same sense. ### What is the difference between an agent harness and an agent framework? A framework such as LangGraph or CrewAI is a library of parts for building your own agent logic. A harness is the complete running machinery. If you assemble and operate the loop, context, tools, permissions, sandboxing, and recovery yourself with a framework, you have built a harness. ### Who coined the term agent harness? The term spread through several sources rather than one. Mitchell Hashimoto's February 2026 essay is widely credited with popularizing it, framework authors used harness language in the same period, and by mid-2026 major vendor definitions had converged on the same structure. ### How do I choose an agent harness? Evaluate configurations, not brands: run your own task across candidate harness and model pairs, apply a success threshold, then compare cost and latency among the ones that pass. HarnessRouter runs each configuration through the same API, and its published same-task benchmark shows the recorded format for this comparison. # AI agent API for product features > What a product needs when users expect completed work: sessions, streaming, files, artifacts, routing, and production controls. Canonical URL: https://harnessrouter.ai/guides/ai-agent-api Published: 2026-07-22 Updated: 2026-07-22 Category: Architecture Keywords: AI agent API, agent API, AI agent platform, agent runtime, agent orchestration, AI agent backend ## Short Answer An AI agent API should represent a work lifecycle, not only a model response. Product teams need a task or session they can stream, observe, continue, and turn into reviewable artifacts. ## Takeaways - Use a model API when the product needs inference or a conversational response. - Use an agent SDK when the team wants to operate the agent loop in its own infrastructure. - Use an agent backend when the product needs hosted runs, durable sessions, files, artifacts, routing, and a control plane. ## Represent work, not just messages - Input: A product task, selected configured agent, files, authorized context, and execution policy. - Lifecycle: A durable task, run, or session with status, streaming events, retries, and continuation. - Output: Structured results, generated files, diffs, artifacts, and metadata the product UI can render. ## Choose the layer that matches the product job | Question | Model API or agent SDK | Agent backend API | |---|---|---| | Who operates the loop? | Your application and infrastructure. | The hosted agent backend or harness layer. | | What comes back? | Messages, tool calls, or SDK events. | A run with state, files, artifacts, and continuation. | | Best fit | Custom loops and infrastructure control. | Shipping agent-backed product features without rebuilding the execution backend. | ## What to verify before choosing an AI agent API - Confirm how sessions persist and how a user continues or revises prior work. - Verify streaming semantics, idempotency, concurrency, cancellation, and retry behavior. - Check how files enter the run and how artifacts return to the product UI. - Keep enough execution evidence to explain harness choice, model choice, tool activity, latency, failure state, and cost where billing records expose it. - Keep harness-specific behavior behind a stable product contract. ## FAQ ### Is an AI agent API the same as an LLM API? No. An LLM API returns model inference. An AI agent API can also manage tools, sessions, execution state, files, and artifacts produced across a longer-running task. ### Is an AI agent API the same as an agent SDK? No. An agent SDK usually runs inside infrastructure you operate. A hosted agent API can operate the run lifecycle and expose it to your product as a service. ### When does a product need multiple agent harnesses? When different tasks benefit from different agent environments, or when the team wants to change harnesses without rewriting its product integration and output handling. # Codex API: What Exists, What Doesn't, How to Call It > The current Codex API reality: OpenAI's seven Codex surfaces, what the Codex SDK actually is, why there is no hosted REST API for Codex tasks in current docs, and how to run Codex over HTTP today. Canonical URL: https://harnessrouter.ai/guides/codex-api-for-apps Published: 2026-07-22 Updated: 2026-08-12 Category: Codex Keywords: Codex API, codex rest api, run codex programmatically, codex headless, Codex SDK, Codex agent API, Codex integration, add Codex to app ## Short Answer As of August 2026, OpenAI ships Codex across seven surfaces, including a Codex SDK that runs on your own infrastructure, but its documentation describes no hosted REST API for running Codex tasks. To call Codex over HTTP today you have two paths: wrap the self-hosted SDK in a service you build and operate, or use a harness platform: HarnessRouter runs Codex behind one API, with tasks, sessions, streaming, files, and results, alongside Claude Code and Hermes. ## Takeaways - What exists: Codex CLI, IDE extension, desktop app, web, Codex Cloud, GitHub integration, and a TypeScript/Python SDK that controls a local Codex app-server on your infrastructure. - What does not exist in current OpenAI docs: a hosted REST endpoint that accepts a Codex task over HTTP and returns the completed run. - The gap between an SDK on your machines and a multi-tenant service is the same four items every harness faces: an HTTP contract, tenant separation, per-task isolation, and product-level durability. ## What OpenAI ships today A senior engineer searching for a Codex API deserves the current inventory rather than a sales pitch. As of August 2026, OpenAI's Codex documentation covers these first-party paths: - Interactive surfaces: The Codex CLI, IDE extension, desktop app, and web give a developer direct, interactive access; Codex Cloud runs tasks in hosted browser workspaces a developer delegates to. - GitHub integration: Repository and pull-request workflows connected to Codex. - Codex SDK: TypeScript and Python libraries that run on your infrastructure: start, continue, and resume threads, drive Codex from CI/CD, or embed it in internal tools; the Python library controls the local Codex app-server over JSON-RPC. - Hosted task API: Not in the current documentation. There is no described REST endpoint that accepts a Codex task over HTTP and returns the completed run. ## The SDK is not a service The Codex SDK answers one real need: programmatic control of Codex on machines you operate, which is exactly right for CI pipelines and internal tools. Putting Codex behind a product for your users is a different job. The SDK process runs on your infrastructure, controlled by whoever operates it; a product needs an HTTP contract your servers call, tenant separation between your customers, an isolated sandbox per task, and sessions, files, and results held for each end user beyond one process's lifetime. Those four are the service layer, and a product needs them regardless of which harness sits underneath, whether Codex, Claude Code, or Hermes. ## Separate the model API from the agent harness | Question | Codex-optimized model API | Codex agent run | |---|---|---| | Primary interface | OpenAI API request and model response. | A task executed by Codex in a working environment. | | Infrastructure | Your team builds the loop, tools, sandbox, files, and persistence. | The harness provides the execution workflow around the model. | | Product output | Text, structured output, or tool-call data you assemble. | Repository changes, test results, files, and a reviewable task outcome. | ## How to actually run Codex behind your product HarnessRouter runs Codex as a managed harness behind one API: your server submits a task, an isolated sandbox spins up for the run, progress streams to your product UI, and the session, files, and reviewable results come back under one contract. The same contract runs Claude Code and Hermes, so a Codex integration is also a comparison instrument: - Send a product task with the codex harness selection and a model from the current catalog; building and integration are free, and credits are used only when tasks run. - Stream progress, then fetch diffs, files, test evidence, and artifacts as explicit product outputs. - Continue sessions for revise-and-retry flows; keep keys and execution server-side with ownership checks per tenant. - Run the same task on other configurations and read the recorded traces before committing a workload. ## Use the smallest layer that completes the job - Choose the model API: When you need coding-oriented inference and already own the agent loop and runtime. - Choose the Codex SDK: When developers on your team drive Codex on infrastructure you operate: CI pipelines, internal tools, one trusted operator surface. - Choose a Codex agent run behind an API: When end users of your product expect completed repository work, commands, tests, and a reviewable change, delivered multi-tenant. - Choose a multi-harness backend: When the product must route between Codex and other agent harnesses behind one stable integration and compare configurations on evidence. ## FAQ ### Does Codex have a hosted REST API? Not in OpenAI's current documentation as of August 2026. The Codex SDK runs on your own infrastructure and controls a local Codex app-server; Codex Cloud is delegated through OpenAI's own surfaces rather than a documented public task endpoint. To run Codex tasks over HTTP, use a harness platform such as HarnessRouter. ### What is the Codex SDK and where does it run? TypeScript and Python libraries for controlling Codex programmatically: starting, continuing, and resuming threads, typically for CI/CD and internal tools. It runs on machines you operate, with the Python library controlling the local Codex app-server over JSON-RPC. ### Is the Codex API the same as the OpenAI Responses API? Not exactly. OpenAI exposes Codex-optimized models through its API, while Codex as an agent also includes an execution workflow around the model. Choose based on whether you need inference or completed agent work. ### Can I put Codex behind my own product UI? Yes. Through HarnessRouter your server submits Codex tasks over HTTP, streams progress to your users, and returns diffs, files, and artifacts as reviewable results, with sessions persisting for continue-and-revise flows and each run isolated in its own sandbox. ### Why route Codex with other agents? Routing lets a product use the harness best suited to each task while preserving one task, session, streaming, file, and artifact contract, and it turns configuration comparison into a parameter change backed by recorded traces. # Which layer should your product use? > Use this page to separate model access from product-facing agent work with sessions, files, artifacts, and traces. Canonical URL: https://harnessrouter.ai/guides/agent-backend-vs-model-router Published: 2026-06-23 Updated: 2026-06-23 Category: Architecture Keywords: agent backend, model router, OpenRouter, TokenRouter, LLM gateway, AI gateway, agent harness, harness routing ## Short Answer Use a model router when your product needs model access, provider choice, or fallback. Use HarnessRouter when an end user expects completed work that your product must stream, recover, preview, download, continue, or revise. ## Takeaways - Model routers solve model access and routing. - HarnessRouter handles the product-facing agent run: status, sessions, files, artifacts, and control-plane Trace. - A product can use both layers, but they answer different user needs. ## Match the layer to the user job - Product UI: Collects the user's task, shows run status, and lets the user review the result. - HarnessRouter: Runs the product task through the configured agent and returns a result your app can handle. - Agent harness: Executes the task in a specialized agent environment such as Codex, Claude Code, or Hermes. Pi is reserved until the harness catalog marks it available. - Model router: Selects or accesses models, providers, fallback paths, or gateway controls. ## Decide by the output your UI needs | Question | Model router / LLM gateway | HarnessRouter | |---|---|---| | Input | Prompt, message, model name, provider preference, or inference request. | Product task that should become completed work inside your app. | | Output | Model response, JSON, tool-call data, media, embedding, or stream. | Harness run result your product can inspect, render, accept, save, or ship. | | Best for | Provider access, fallback, cost control, and model choice. | Agent-backed product features without building the harness backend. | ## Use both when the product needs both layers - Keep OpenRouter, TokenRouter, or another model router at the model access layer. - Use HarnessRouter for user-facing work requests that need a harness run. - Keep the UI language focused on the user's task, not the infrastructure stack. ## FAQ ### Is HarnessRouter an OpenRouter alternative? No. OpenRouter focuses on model access and routing. HarnessRouter focuses on product tasks that need agent harnesses, sessions, files, artifacts, and traces. ### Is HarnessRouter a TokenRouter alternative? No. TokenRouter-style products belong near the model gateway layer. HarnessRouter belongs where product workflows become agent runs. ### Can a product use both? Yes. A product can use a model router underneath while HarnessRouter routes the user-facing agent task. # HarnessRouter and OpenRouter > How model routing and agent-backed product work fit together in one stack. Canonical URL: https://harnessrouter.ai/guides/harnessrouter-and-openrouter Published: 2026-06-23 Updated: 2026-06-23 Category: OpenRouter Keywords: OpenRouter vs HarnessRouter, OpenRouter alternative for agents, use OpenRouter with agents, model routing for AI agents, agent backend, LLM gateway ## Short Answer OpenRouter helps a product reach and route models. HarnessRouter helps a product run user tasks through configured agent harnesses. They solve different layers and can be used together. ## Takeaways - Do not pitch HarnessRouter as a drop-in OpenRouter replacement. - Use OpenRouter when the problem is model access, provider choice, fallback, or model routing. - Use HarnessRouter when the product needs an agent harness to return reviewable work. ## Give each layer a clear job - OpenRouter: A unified model API layer for accessing models, choosing providers, and handling model routing or fallback. - HarnessRouter: An agent backend layer that runs product tasks through configured harnesses such as Codex, Claude Code, and Hermes. Pi remains reserved until the catalog marks it available. - Product UI: The place where a user asks for work, sees status, reviews output, and decides whether to save or ship it. ## Where OpenRouter fits in an agent product - Put OpenRouter near the model/provider layer when the stack needs model choice or fallback. - Put HarnessRouter between the product UI and the harness run when the user is asking for completed work. - Keep model routing invisible to the user unless model choice changes the product outcome. ## Answer the alternative question without misleading users - If someone wants an OpenRouter alternative for model access, HarnessRouter is not that product. - If someone wants to add agent-backed work to an app, HarnessRouter is the relevant layer. - A product can use both: OpenRouter for model access, HarnessRouter for harness-backed workflows. ## FAQ ### Is HarnessRouter an OpenRouter alternative? No. OpenRouter is for model access and routing. HarnessRouter is for product tasks that need agent harnesses, sessions, files, artifacts, and traces. ### Can I use OpenRouter with agents? Yes. OpenRouter can sit below an agent or harness as the model access layer, while HarnessRouter handles the product-facing run lifecycle. ### When should I use HarnessRouter instead? Use HarnessRouter when the user expects completed work inside your product, not just a model response. ## Editorial Intent Directory The Blog publishes timely definitions, comparisons, tutorials, announcements, and evidence-backed analysis. Use the canonical Blog URLs below for articles that are not implementation documentation: - [From Model Layer to Harness Layer: AI Product Infrastructure](https://harnessrouter.ai/blog/ai-product-infrastructure): Insights. Updated 2026-08-12. Search topics: AI product infrastructure, AI infrastructure layers, harness layer, model layer, context layer, agent harness, AI product architecture, agent infrastructure. - [Model Evals: How to Pick the Best Model for Your Use Case](https://harnessrouter.ai/blog/model-evals): Tutorials. Updated 2026-08-13. Search topics: model evals, model eval, LLM evals, how to evaluate LLMs, AI model evaluation, LLM-as-a-judge, agent evals, harness and model configuration. - [How to Build an Agent Harness (and When You Should Not)](https://harnessrouter.ai/blog/how-to-build-an-agent-harness): Tutorials. Updated 2026-08-12. Search topics: how to build an agent harness, build agent harness, agent harness architecture, agent harness tutorial, custom agent harness, agent execution loop, agent harness, AI agent backend. - [Managed Agents Compared: Claude vs Google vs AWS vs Multi-Harness](https://harnessrouter.ai/blog/managed-agents): Comparisons. Updated 2026-08-11. Search topics: managed agents, claude managed agents, aws bedrock agentcore, bedrock managed agents, google managed agents api, managed agents comparison, managed agent harnesses, hosted ai agents, agent infrastructure, managed agents alternatives, agent harness. - [What Is Agent as a Service (AaaS)? Definition and Examples](https://harnessrouter.ai/blog/agent-as-a-service): Insights. Updated 2026-08-11. Search topics: agent as a service, AaaS, what is agent as a service, agents as a service, aaas meaning, saas to aaas, aaas platform, ai agents as a service, agent infrastructure, harness as a service. - [What Is Harness as a Service (HaaS)?](https://harnessrouter.ai/blog/what-is-harness-as-a-service): Insights. Updated 2026-08-13. Search topics: harness as a service, HaaS, managed agent harnesses, agent harness infrastructure, agent as a service, AaaS, agent harness, hosted agent harness, agent infrastructure, run agent harnesses. - [What Is a Meta-Harness? The Interface Layer Above Agent Harnesses](https://harnessrouter.ai/blog/what-is-a-meta-harness): Insights. Updated 2026-08-13. Search topics: meta-harness, what is a meta-harness, meta harness, agent harness interface layer, unified interface for agent harnesses, agent harness, run multiple coding agents, AI agent backend, harness routing, agent infrastructure. - [Agent Harness vs Model: Why Developers Swap One and Keep the Other](https://harnessrouter.ai/blog/agent-harness-vs-model): Comparisons. Updated 2026-08-10. Search topics: agent harness vs model, what is an agent harness, claude code with other models, open weight coding models, coding agent architecture, harness model decoupling, best coding agent 2026, agent harness, AI agent backend, model commoditization. - [Codex vs Claude Code for Product APIs: A Same-Task Benchmark](https://harnessrouter.ai/blog/codex-vs-claude-code-api): Comparisons. Updated 2026-08-13. Search topics: codex vs claude code, claude code vs codex, codex vs claude code api, claude code vs codex benchmark, agent harness benchmark, run codex in your app, run claude code in your app, agent harness, AI agent API, cost per successful task. - [AgentAPI vs HarnessRouter: The Hosted Alternative](https://harnessrouter.ai/blog/agentapi-alternatives): Comparisons. Updated 2026-08-13. Search topics: agentapi alternatives, agentapi vs harnessrouter, agentapi, coding agent api, run coding agents in your app, claude code http api, codex http api, agent harness, AI agent backend, hosted coding agent api. - [AI Agent Stack: 7 Layers From Infrastructure to Customer Outcomes](https://harnessrouter.ai/blog/ai-agent-stack): Insights. Updated 2026-08-04. Search topics: AI agent stack, AI infrastructure stack, agent harness, agent infrastructure, AI application stack, model commoditization, AI agent runtime, agent orchestration, harness router, model harness routing. - [What Is an LLM Router? A Practical Guide to Model Routing](https://harnessrouter.ai/blog/what-is-an-llm-router): Tutorials. Updated 2026-08-13. Search topics: LLM router, LLM routing, model router, multi-model routing, LLM router vs AI gateway, AI gateway, semantic routing, cost-aware routing, model fallback, agent router, harness router. - [HarnessRouter: The World's First Unified Interface for Agent Harnesses](https://harnessrouter.ai/blog/harnessrouter-unified-interface-for-agent-harnesses): Announcements. Updated 2026-08-13. Search topics: HarnessRouter, agent harness, unified interface for agent harnesses, AI agent API, Hermes agent, Pi agent, serverless AI sandboxes, agent infrastructure, QM multiplayer agent harness. # HarnessRouter Pricing > Start free. Scale when you’re ready. Canonical URL: https://harnessrouter.ai/pricing Get 500 free credits. Available for a limited time. When you need more capacity, choose Developer, Production, or Scale. Additional usage can draw from purchased top-up credits. ## Plans | Plan | Price | Credits | Note | |---|---:|---:|---| | Developer | $20/month | 500 monthly plan credits | Best place to start | | Production | $100/month | 3,000 monthly plan credits | | | Scale | $200/month | 10,000 monthly plan credits | | | Enterprise | Custom | Tailored capacity | Book a demo | Top up usage credits whenever you need them. ## FAQ ### When do credits get consumed? Building and integrating are free. Credits are consumed only when tasks run through your API key, whether you trigger them or your end users do. A task's cost depends on the harness and model you configure. ### Do I need a card to claim launch credits? Yes. Create an account and add a card to receive 500 free credits. You can build without a card; the card unlocks the free credits your tasks will consume. ### How many credits renew with each plan? Developer includes 500, Production includes 3,000, Scale includes 10,000 monthly credits. Plan credits refresh with each billing period. ### How do plan changes work? Upgrades take effect immediately. Before you confirm, you will see the prorated amount due for the rest of your current billing period and your next renewal price. Additional monthly plan credits are prorated for the same period. Downgrades take effect at your next renewal. ### Can I add credits without changing plans? Yes. Top-ups add prepaid usage credits without changing your plan, renewal date, or monthly plan credits.