Bring your team into sessions with your AI coding agents so you can make decisions quickly and iterate fast.

🔒buildautomaton.com/w/acme/sessions

Checkout flow — agent iteration

In progress

Add token-bucket rate limiter per API key and a simple usage dashboard.

I'll add rate limiting middleware and wire it to Redis. I'll create a new middleware file that implements token-bucket per API key, then update the API routes to use it. I'll also add a simple usage dashboard so you can see request counts per key.

Create file

Middleware file is in place. Now I need to check the existing API structure and apply the middleware to the v1 items routes. I'll look at how other middleware is applied in this codebase so the pattern is consistent.

Update file

Routes are updated. I'll add the retry-after header to the 429 response so clients know when to retry, and double-check that the Redis key TTL is set correctly for the sliding window.

Update file

Summary of what was done:

  1. New middleware (api/src/middleware/rate-limit.ts): Token-bucket rate limiter keyed by API key. Uses Redis in production and in-memory in dev. Default 100 requests per minute per key; 429 responses include a Retry-After header.

  2. API integration (app/api/v1/items/route.ts): The v1 items routes (GET, POST, DELETE) now run through the rate limit middleware. Unauthenticated or missing-key requests skip limiting.

  3. Dashboard: A minimal usage view was added so you can see request counts per key over the last 24h. You can expand this later with charts or export.

If you want to tweak limits, Redis key prefix, or add more routes, say what you’d like changed.

Bring product, design, and engineering into the same sessions.

Follow what teammates are building with agents

Skim their Changes view—files touched, summaries, and +/− counts—so you stay in the loop without jumping into their IDE or branch.

🔒buildautomaton.com/session/demo

Rate limit middleware for public API

In progress

Add token-bucket rate limiter per API key and a simple usage dashboard.

Introduces token-bucket limits per API key, Redis-backed counters, and 429 responses with Retry-After.

Routes GET, POST, and DELETE for v1 items through the shared rate-limit middleware.

Adds a small GET endpoint that returns per-key usage snapshots for the dashboard.

1
+ export async function GET() {
2
+ return Response.json({ keys: [] });
3
+ }
Your network
LocalVPCPrivate cloudOn-prem

Pick your agent—each teammate can use their own

Claude CodeCursorCodexOpenCodeClineEnterprise agentVendor SDK
Agent Client Protocol (ACP)
and supported bridges
BuildAutomaton
Workspace in the cloud

Every teammate’s favorite local agent—same workspace

Each engineer keeps their preferred local agent; the team still shares one session, preview, and Changes surface—ACP and bridges make that possible. Supported agents.

Your agent, any device. Your team, same loop.

Shared sessions let everyone follow Changes, follow-ups, and proxied previews in one thread—fewer recap meetings.

Frequently asked questions

What types of agents are supported?
BuildAutomaton uses the Agent Client Protocol (ACP), so it supports any agent that implements ACP—including Cursor, Claude Code, Codex CLI, Kiro, and more. See our Supported agents docs for the full list and compatibility notes.
How do I set up a bridge?
Run the CLI on the machine you want to make accessible. After installing Node.js, run npx @buildautomaton/cli (or install the CLI globally). The bridge stays connected until you stop the CLI. See our Getting started guide for full steps.
What does it cost?
We have a flat subscription fee for BuildAutomaton—see our Pricing page. Your local agents (Cursor, Claude Code, etc.) are priced separately by their providers; you’ll need a subscription for those separately.
How is the local bridge secured?
The bridge requires authentication. Only authenticated users can access the resources that the bridge makes available.