Introducing Yaha AI

We started as an OpenAI-compatible gateway because that was the gap: keys scattered across repos, no shared allowlist, and no single place to see spend. That layer still matters. It is no longer the whole product.

Yaha AI is the platform. Gateway, Agents, and Workflows are products on it. Point your apps at one endpoint, then build the assistants and automations your team actually runs, under the same policy and usage trail.

What stays the same

The Gateway contract did not change. Create a project key in the console, set the base URL to https://gateway.yahagateway.io/v1, and keep your OpenAI-compatible SDK. Coding agents such as Cursor and Claude Code still connect with a yaha.* key.

If you read Introducing Yaha AI Gateway earlier this year, that post is still the origin story for the proxy layer.

What is new

Teams were already using the gateway as the control plane for every model call. The next step is to build on that plane instead of standing up another stack for assistants and jobs.

• Agents — versioned assistants with planning modes, tools, a builder playground, and deployments
• Workflows — visual DAGs that can invoke those agents, call HTTP APIs, run on a schedule, and pause for approval

Both products use the same workspace, models, and cost tracking you already have.

Why a platform, not another sidecar

A chat assistant that bypasses your allowlist is just another shadow key. A cron job that calls a provider directly is another bill you cannot explain. Yaha AI keeps those paths on the gateway: publish an agent, drop it on a workflow canvas, and the run still hits routing, quotas, and logs.

Where to start

1. Keep routing app and coding-agent traffic through the Gateway.
2. Create a first Yaha Agent and publish a version.
3. Wrap a repeatable process in a workflow.

Ready to try it? Sign in to the console and open Products → Agents or Products → Workflows.