The Replit Team

We’re excited to introduce Agent 3—our most advanced and autonomous Agent yet. Compared to Agent V2, it is a major leap forward. It is 10x more autonomous, with the ability to periodically test your app in the browser and automatically fix issues using our proprietary testing system—3x faster and 10x more cost-effective than Computer Use models. Even better, Agent 3 can now generate other agents and automations to streamline your workflows.

 

What’s New



1. App Testing: Agent tests the apps it builds (using an actual browser)

Agent 3 now tests and fixes the app it is building, constantly improving your app behind the scenes. We are launching two different options here, depending on your needs:

Introducing Agent 3: Our Most Autonomous Agent Yet

Amjad Masad

Rate limiting is standard practice for services offering an API. It's used for both protecting against bad actors, for example, attempting DOS attacks and to simply enforce limits on the service. There are many resources on the web on how to implement a rate limiter in your favorite language/stack. However, I couldn't find anything on how to rate limit Websocket connections (they differ in that they are persistent connections).[](preview end)

If you're implementing an HTTP API rate limiter and your service endpoint is a single server then it's pretty simple -- you keep an in-memory variable that you increment. Things get trickier, however, when you're serving requests from multiple servers. That's when you start needing a central shared "state". For this, most developers use Redis. In fact, the rate limiting use case is so prevalent in Redis that it gets a mention on the docs for the INCR function:

The requirement here is to limit calls to 10 calls per second per IP address. So a key is constructed by concatenating the user's IP address with the current timestamp. This is then incremented with every call and checked to make sure they haven't exceeded the limit. Simple enough (you can also implement this using your favorite language and Redis library).

In our case, our code execution API gives our customers and users an HTTP and a Websocket interface. The reason you'd need a persistent connection is to build a stateful interpreter/REPL. But persistent connections costs us system resources because we need to start a container and an interpreter/compiler process that waits for the next command to execute. For this reason we have to enforce a limit on concurrent open connections. The challenge with this is implementing it for a distributed service (we serve our users from different servers with no centralized server managing state). As we've seen above, Redis is the go-to technology to solve this problem. However, our use case differs in that we don't limit calls for a certain time interval, instead our limit is one the total number of open connections at any given time.

The first solution that came to mind:

Distributed Websocket Rate Limiting

[Update Oct 2022: We have retired our API, we are excited by our previous work but we do not have the resources to support this at the moment.]

Repl.it's code execution API is an HTTP and WebSocket endpoint that you connect to and send code to execute. You can connect from any device or browser and start executing code. This guide will describe the concepts behind the service, how it can be used, and provide a step-by-step guide for signing up and trying out the service!

Code Execution

You're probably here because you want to run some user code in an app or website somewhere. Our customers use the Repl.it API for many different things including:

In-browser coding environments

In-browser coding exercises

API Docs

Faris Masad

Autocomplete plays a big role in how we use software, imagine a world where you have to type full search terms without predictions into google search, ugh, the savagery! Many developers employ this technology when writing code in order to increase their productivity. So we decided to implement this feature to help you become the power user you want to be.[](preview end)

BEHOLD! Note: if you're not a fan of autocomplete you can always turn it off from the preferences menu (⋮) at the top left of your editor.

We've also been getting many requests to enable renaming the repl from the workspace. Now, after you hit save, you can click at the top to change the name of your repl. Soon, we'll add a way to add tags without having to go to the repls page so you can organize and easily search for your repls.



Autocomplete Your Code with Replit

In this age of containers it's much easier to run arbitrary code in the cloud. The harder parts are scaling the service, making it reliable, and —as in this case— creating cool and useful experiences. When we looked at existing Swift REPL implementations on the web we found that none delivered a stateful and interactive environment. Just an editor with a run button.[](preview end)

As for us, as much as possible, we try to create an environment similar to the original inspiration for our website: DrScheme (now DrRacket).





A Swift REPL

We're excited to launch this new part of our site.[](preview end) First, we have a place to share with you all the exciting features we're building (things that don't fit in a 140 characters and a GIF). You can also look forward to posts sharing what we learn in engineering and design.

Second, we're putting all the informational pages for our product and company here. This way you don't have to download tons of JavaScript that is intended for the development environment when all you want to do is read words. That'll also make it easier for Google to index our stuff.

For now, you can check out our new about us page, sign up for our classroom product beta, or checkout our new languages landing pages.

Introducing Agent 3: Our Most Autonomous Agent Yet

Distributed Websocket Rate Limiting

API Docs

Autocomplete Your Code with Replit

A Swift REPL

Hello World