TL;DR

TrueForge is TrueFoundry’s open-source agent harness — the runtime layer that sits between a model and a working agent. It owns the execution loop (model calls, MCP tools, skills, sandboxing, approvals, context management, session state) and exposes it three ways: a chat UI, an HTTP API with a TypeScript SDK, and an embeddable UI SDK.

Key facts (verified 2026-09-05):

  • 5,226 GitHub stars, 375 forks, 91 open issues — created 2026-07-23, last push 2026-09-04
  • MIT licensed, TypeScript, requires Node.js ≥ 22.14; ~31 contributors
  • Ships as four npm packages (trueforge, -core, -sdk, -ui) plus an OCI Helm chart
  • Current release train is 0.2.0-rc.0 (2026-08-27) — still pre-1.0
  • Two modes: local (one process, SQLite) or hosted (Postgres + Redis via Docker Compose, Helm, or Railway)
  • Vendor benchmark on DevRev’s Enterprise-Bench: ~30% cheaper than Claude Managed Agents on the same model, ~2.5× cheaper than deepagents, ~75% cheaper on GLM-5.2
  • Sandbox is a tool, not the execution environment — the agent loop stays on the server, secrets stay out of the sandbox

The pitch isn’t a smarter agent. It’s that the loop is the expensive part, and TrueForge argues most harnesses are wasting your money in it.

Why This Matters Now

We’ve reviewed a lot of harnesses this year, and they mostly cluster into two shapes. There’s the terminal-native coding agent — Pi competing on minimalism, DeepSeek Harness on extensibility. And there’s the framework you assemble at runtime — LangGraph, deepagents, and friends, where you write the loop yourself.

TrueFoundry’s team put the gap plainly in the Hacker News thread, responding to a comparison with Pi:

It’s a CLI coding agent that lives in your terminal, built mainly for devs working on a codebase on their own machines. TrueForge is a runtime for building and running general agents. It comes with a server and web UI, plus an SDK and API. So you can build production agents and run them for yourself or your org, self-hosted behind SSO.

That’s the actual positioning: not a coding agent, and not a library. A server you deploy, configure once, and hand to an org. The closest thing we’ve covered structurally is QM, which solves the multi-person scoping problem; TrueForge is aiming at the multi-agent, multi-application problem instead — one runtime, many agents defined as data, consumed over HTTP.

The Benchmark Claim, Examined

This is the part worth reading carefully, because it’s the strongest claim and the one most likely to be misread.

TrueFoundry ran 14 L1–L2 tasks from DevRev’s Enterprise-Bench — cross-system B2B operations tasks spanning engineering, sales, and support, where each task forces the agent to join data across three MCP servers (a Salesforce-style CRM, a Jira-style tracker, a Drive-style doc store). Every harness got the same model, same three MCP servers, same system prompt, fresh session per task, n = 3 trials, graded by a blind LLM judge that never sees which harness produced the answer.

ConfigurationSolved / 14$ / runTokens / run
Claude Managed Agents · Opus 4.810.7$11.810.0M
TrueForge · Opus 4.810.7$8.63.7M
TrueForge · GLM-5.211.7$3.03.8M
deepagents · Opus 4.810.0$21.216.5M
deepagents · GLM-5.212.0$9.111.9M

The headline is cost, but the token column is the real story. TrueForge solves the same number of tasks as Claude Managed Agents using 37% of the tokens (3.7M vs 10.0M), and roughly 22% of what deepagents burns on Opus. That’s not a pricing trick — it’s a structurally leaner loop.

Their explanation of why holds up:

  • Leaner context each turn — a compact instruction instead of heavy scaffolding. deepagents carries planning state, a virtual filesystem, and sub-agent machinery on every turn.
  • Fewer tool calls — 19 per task, versus 32 and 40 for the other two. Every extra round-trip re-ships the entire growing context.
  • Compaction instead of replay — history gets trimmed and large tool responses offloaded, rather than re-sent verbatim.

The honest caveats. This is a vendor-run benchmark — TrueFoundry designed the comparison, tuned their own configuration, and published the result. Fourteen tasks at n=3 is a small sample, and the per-task table shows genuine variance (deepagents beats TrueForge outright on eng-l2-a and eng-l2-b; TrueForge wins sales-l2-d and support-l1-b where deepagents scores 0/3). Note too that deepagents on GLM-5.2 scored the highest raw accuracy of any configuration (12.0/14) — TrueForge’s own table doesn’t hide that. To their credit the benchmark kit is in the repo and points at DevRev’s canonical rubric rather than redistributing a private copy, so the claim is falsifiable. Treat it as “plausible and reproducible,” not “independently verified.”

Architecture: Sandbox as a Tool

The design decision that most separates TrueForge from its peers is where the agent loop lives.

Most sandboxed harnesses — Tilde Run among them — run the whole agent inside a VM or container. TrueForge inverts it: the agent loop stays on the server, and the sandbox is just another tool it can call for code, files, and shell.

Chat UI ─┐
SDK ─────┼─→ TrueForge server ─→ SQLite | Postgres+Redis
UI SDK ──┘      (agent loop)    ─→ models (BYO)
                     │           ─→ MCP servers
                     └─────────→ sandbox (Daytona) — provisioned on demand

Two consequences fall out of that:

  1. Secrets stay in the harness. Your API keys and MCP OAuth tokens never enter the sandbox, so a prompt-injected agent that gets shell access still can’t read your credentials off disk.
  2. Compute is provisioned only when needed. A conversational agent that never writes code never spins up a sandbox at all. Skills and Code Mode require one; nothing else does.

The tradeoff: you’re depending on an external sandbox provider. Today that means Daytona, with “more providers planned.” If you need fully air-gapped execution right now, that’s a real gap.

Context Engineering: The Actual Product

Strip away the UI and TrueForge is a set of opinions about what the model sees each step. The docs split it into two phases, and the distinction is genuinely useful even if you never run TrueForge.

Input context is loaded at the start of every run and is mostly static: instructions, skills, MCP tool definitions.

  • Skills are git-backed SKILL.md instruction packs. Critically, each attached skill contributes only its name and description to context — the full body is read from the sandbox on demand when the agent decides it’s relevant. That’s progressive disclosure, and it’s the same pattern that makes agent skills scale past a handful.
  • MCP tool definitions are the sneaky context killer. Name, description, input schema, and output schema all cost tokens, and a few MCP servers exposing dozens of tools each can eat a large chunk of the window before the user types anything. TrueForge defaults to preload: false: each server contributes only its name and description, and individual tool schemas get discovered on demand.

Runtime context is what accumulates during the run — user messages, tool calls, tool results, subagent output. This is what compaction, large-result offloading, and subagents manage.

The docs also give the single best piece of prompt advice in the whole project, which applies regardless of harness:

Don’t duplicate MCP tool docs or skill content — the harness already injects those. Move long procedures into skills — anything that reads like a workflow or playbook belongs in a skill, not the instructions.

Getting Started

Local mode is genuinely one command:

npx @truefoundry/trueforge@latest

That gives you one process backed by SQLite, a chat UI, and the HTTP API. Connect a model provider (OpenAI, Anthropic, Gemini, or any OpenAI-compatible endpoint), point it at some MCP servers, and you have a working agent.

Read the warning before you get clever with it. The README is unusually blunt:

Local mode is for your machine only… There is no login by default, and data lives in a local SQLite file. Please keep it on localhost.

For anything shared, hosted mode means Postgres + Redis via Docker Compose, the Helm chart, or Railway, with optional OIDC login.

Agents themselves are data, not code — an AgentSpec you POST once and reference by name:

{
  "model": {
    "name": "anthropic/claude-sonnet-4-6",
    "params": { "max_tokens": 4096 }
  },
  "instructions": "You help customers with orders. Look up order details before taking action. Always confirm before processing refunds.",
  "mcp_servers": [
    {
      "name": "orders-api",
      "enable_tools": ["get_order", "process_refund"],
      "require_approval_for_tools": ["process_refund"]
    }
  ],
  "config": { "iteration_limit": 25 }
}

Note require_approval_for_tools — human checkpoints are a field on the spec, not something you wire up yourself. Same for iteration_limit, which is your runaway-loop circuit breaker.

The SDK’s mental model is a clean hierarchy: one Agent → many Sessions → many Turns → many Events → some Deltas. An agent is a reusable definition; a session is one issue worked through (persist its id and the user resumes tomorrow); a turn is one request; events stream out (turn.created, model.message, tool.response, tool.approval_required, turn.done), with deltas as the streaming chunks. Turns chain automatically via previous_turn_id: "auto", so you never resend history — a small API decision that eliminates a whole class of bugs.

Who Should Use This

Good fit:

  • Teams that need several agents behind one runtime, consumed by apps over HTTP rather than by one developer in a terminal
  • Anyone who wants model portability as a structural property — the benchmark’s GLM-5.2 column is the argument, and in 2026 the best-value model changes roughly monthly
  • Orgs with self-hosting or SSO requirements that rule out Claude Managed Agents outright
  • Teams currently on deepagents/LangGraph who are feeling the token bill and would rather configure a loop than maintain one

Poor fit:

  • Solo devs who want a coding agent in their terminal — use Pi or a CLI agent; TrueForge’s own team says so
  • Python-first shops — the SDK is TypeScript, and while the HTTP API is language-neutral, the ergonomics aren’t there yet
  • Anyone needing air-gapped sandboxing today (Daytona-only)
  • Teams that can’t run pre-1.0 software in production. It’s 0.2.0-rc.0 with 91 open issues, six weeks old

Honest Limitations

  • Pre-1.0, and young. Created 2026-07-23. The changelog still contains things like “migrate persisted legacy token thresholds” — schema churn is ongoing.
  • Self-reported benchmarks. Reproducible, but designed and run by the vendor. See the caveats above.
  • Single sandbox provider. Daytona today.
  • Commercial parent. TrueFoundry is a paid platform company. The MIT license is real and the company insists it’s “not a cut-down free tier with the good parts held back” — but the open-core funnel risk is the standard one, and worth pricing in.
  • Local mode has no auth. Easy to misdeploy; the README warns you, but warnings in READMEs have a poor track record.

FAQ

What is an agent harness, exactly? The runtime layer between an LLM and a working agent: it runs the loop of model call → tool call → result → model call, while managing session state, context size, tool permissions, and sandboxing. A framework makes you assemble that; a harness ships it.

How is TrueForge different from LangGraph or deepagents? deepagents is a framework you build a loop with; TrueForge is a server you deploy that already has one. Practically, TrueForge’s benchmark shows it using 3.7M tokens per task versus deepagents’ 16.5M on the same model — mostly from compaction and deferred tool loading rather than replaying accumulated context every step.

Is TrueForge really free? Yes — MIT licensed, all four npm packages and the Helm chart. You pay for your own model tokens, infrastructure, and sandbox provider.

Can I use open models instead of Claude or GPT? Yes, and that’s the main cost argument. Any OpenAI-compatible endpoint works. The vendor benchmark puts GLM-5.2 at $3.0/run versus $8.6 for Opus 4.8 — with higher measured accuracy (11.7 vs 10.7 of 14).

What do I need to run it? Node.js ≥ 22.14 and npx @truefoundry/trueforge@latest for local mode. Hosted mode needs Postgres and Redis, deployable via Docker Compose, Helm, or Railway. A Daytona sandbox is only required for skills and Code Mode.

Does it support MCP OAuth? Yes — remote MCP servers with header auth or OAuth, including in-chat authorization, where the agent surfaces a Connect button mid-conversation when a connector needs authorizing.

Is it production-ready? Hosted mode is the supported path, with OIDC login and multi-replica Postgres/Redis. But at 0.2.0-rc.0 and six weeks old, pin your versions and expect breaking changes. Local mode is explicitly not production.

Sources