Show HN: Arch – an intelligent prompt gateway built on Envoy

I'm affiliated with Portkey, so can answer who would need such a proxy/gateway:

Sidenote: Arch is def interesting!

A typical user we've seen at Portkey is a mid or a large size eng org where a central "Gen AI team" has now come up. This Gen AI team builds services that the rest of the company uses to build whatever AI features or products they want.

To build such a service, they need traditional API Gateway features like rate limiting, access rules, and also AI-specific features like universal API to multiple LLM providers, universal routing, central guardrails, AI-native observability + central dashboard for other stakeholders, and more.

It can absolutely be a plugin on top of existing Gateways.. like we've explored putting Portkey on Kong, but the need for a dedicated AI Gateway still remains, that can do all of these things I described in an easier way.

Probably, solutions like Langchain/Llamaindex etc. also fit in somewhere here, but a dedicated service for "ops" related issues for LLM APIs is something that we're seeing orgs adopt as a good practice.

Two things

1/ Arch builds on Envoy so that we don't re:invent all the HTTP(s)/TCP level capabilities needed in a modern gateway for applications. So in that sense, we agree with you that it should "extend" something vs. rewriting the whole stack. There are several security and robustness guarantees that we borrow from Envoy as a result of this. To be more specific, a lot of Arch's core implementation today is an Envoy filter written in Rust.

1/ Arch's core design point is around the handling and processing of prompts, which we believe are nuanced and opaque user request that require secure handling, intelligent routing, robust observability, and integration with backend (API) systems for personalization – all outside business logic. This requires the use of models and LLMs that are fast, cheap and capable to help developers stay focused on application features. For example, Arch uses (fast) purpose-built LLMs for jailbreak detection, converts prompts into API semantics for personalization, and (eventually) automatically routing to the best outbound LLM based on the complexity of a prompt to improve the cost/speed of an app.

We believe #2 will continue to be different and evolve further away from traditional API/HTTP routing that it will require constant invention and work to make the lives of developers easy.

Hope this helps!

Untrusted inputs to systems with agency or access to privileged data. Here’s a data exfiltration example in Google AI Studio:

https://x.com/wunderwuzzi23/status/1821210923157098919

That's a fair point - technically it protects the application from malicious attempts to subvert the desired LLM experience. The more specific language (and I think we could do better here) would be that Arch ensures users remain within the bounds of an intended LLM experience. That at least was the intention behind "ensure safe user interactions"...

Jailbreak ensures a smooth developer experience by controlling what traffic from user make its way to the model. With jailbreak (and other guardrails soon to be added) developers can short-circuit response and with observability developers can get insights on how users are interacting with their APIs.

It's early days, so while there might be some overlap, I am sure there is a lot that we can do together to build complimentary products.

Based on the press release, its kinda hard to tell exactly how different/alike we will be, but Arch will always be "designed-first" for prompts and LLM application workloads without exposing all Envoy related features. And Envoy is "designed-first" for micro-services application workloads. So there will be some overlap but our design principles will deviate over time I feel. But we are very open to collaborating with the community here...

You can also see current list of issues at https://github.com/katanemo/arch/issues, and can also post new feature requests and bug fixes there.

We agree Envoy is legendary - and per se doesn't lend anything to the AI space. That's essentially what we are doing here, building on top of Envoy to add capabilities specifically for AI and prompts. For instance, we use Envoy's filtering capabilities to handle and process prompts - this was get to keep all the robustness and security features for TCP/HTTP from Envoy and solve the critical but undifferentiated tasks related to prompts like safety, observability, routing, function calling, etc.

Yea - that’s gonna be an issue. It was a hotly debated name but we figured the SEO will adapt with GenAI and the way we know SEO today might not be problematic. Let’s see - tricky for sure