Forge 0.9.0: consolidating the Proxy around how people actually use it

[antoinezambelli]

Forge’s success caught me somewhat by surprise. I originally thought of it primarily as a guardrail library and native workflow runner. In practice, the Proxy became its most popular entry point: put Forge between an existing client and backend, keep the surrounding system intact, and gain the guardrails without rewriting the agent loop.

Backend support then grew organically—llama-server, llamafile, Ollama, vLLM, OpenAI-compatible services, Anthropic-compatible gateways. The underlying guardrail behavior became fairly stable, but the Proxy accumulated naming, routing, metadata, and configuration decisions made while rapidly unblocking each new integration.

Some recent, more expansive proposals forced a useful product decision: Forge Proxy should be a boring, backend-neutral sidecar. The caller owns its conversation. Operators own their unmanaged backends. Forge owns the routing, guardrails, configuration contract, and honest observability between them.

Forge 0.9.0 is the intentional pre-1.0 cleanup that follows from that decision. It consolidates backend profiles and endpoint topology, removes Proxy-side compaction, makes metadata forwarding honest, adds current-context reporting, and replaces several overlapping configuration concepts with one clearer contract. Native Forge workflows and the core guardrail behavior remain intact.

This is a breaking Proxy release, but deliberately one concentrated break rather than a series of smaller compatibility cuts. It also gives Forge a stable foundation for the next piece of work: a standalone, dependency-free Proxy installer that can make the sidecar genuinely painless to deploy.

• Forge 0.9.0 release
• Migration guide
• pip install forge-guardrails==0.9.0