Thank you Juraj!
1,506 karma · joined September 12, 2016
https://github.com/e2b-dev/e2b
vasek at e2b.dev
We're a company called E2B [0]. We're building and open-source [1] secure environments for running untrusted AI-generated code and AI agents. We call these environments sandboxes and they are built on top of micro VM called Firecracker [2]. We specifically decided to use Firecrackers instead of containers because of their security and ability to do snapshots.
You can think of us as giving small cloud computers to LLMs.
We recently created a dedicated SDK for building custom code interpreters in Python or JS/TS. We saw this need after a lot of our users have been adding code execution capabilities to their AI apps with our core SDK [3]. These use cases were often centered around AI data analysis so code interpreter-like behavior made sense
The way our code interpret SDK works is by spawning an E2B sandbox with Jupyter Server. We then communicate with this Jupyter server through Jupyter Kernel messaging protocol [4]. Here's how we added code interpreter to the new Llama-3 models [5].
We don't do any wrapping around LLM, any prompting, or any agent-like framework. We leave all of that to our users. We're really just a boring code execution layer that sits at the bottom. We're building for the future software that will be building another software.
Our long-term plan is to build an automated AWS for AI apps and agents where AI can build and deploy its own software while giving developers powerful observability into what's happening inside our sandboxes. With everything being open-source.
Happy to answer any questions and hear feedback!
[0] https://e2b.dev/
[1] https://github.com/e2b-dev
[2] https://github.com/firecracker-microvm/firecracker
[4] https://jupyter-client.readthedocs.io/en/latest/messaging.ht...
[5] https://github.com/e2b-dev/e2b-cookbook/blob/main/examples/l...
We're a company called E2B [0]. We're building and open-source [1] secure environments for running untrusted AI-generated code and AI agents. We call these environments sandboxes and they are built on top of micro VM called Firecracker [2].
You can think of us as giving small cloud computers to LLMs.
We recently created a dedicated SDK for building custom code interpreters in Python or JS/TS. We saw this need after a lot of our users have been adding code execution capabilities to their AI apps with our core SDK [3]. These use cases were often centered around AI data analysis so code interpreter-like behavior made sense
The way our code interpret SDK works is by spawning an E2B sandbox with Jupyter Server. We then communicate with this Jupyter server through Jupyter Kernel messaging protocol [4].
We don't do any wrapping around LLM, any prompting, or any agent-like framework. We leave all of that on users. We're really just a boring code execution layer that sats at the bottom that we're building specifically for the future software that will be building another software. We work with any LLM. Here's how we added code interpreter to Claude [5].
Our long-term plan is to build an automated AWS for AI apps and agents.
Happy to answer any questions and hear feedback!
[0] https://e2b.dev/
[1] https://github.com/e2b-dev
[2] https://github.com/firecracker-microvm/firecracker
[4] https://jupyter-client.readthedocs.io/en/latest/messaging.ht...
[5] https://github.com/e2b-dev/e2b-cookbook/blob/main/examples/c...
We're a company called E2B [0]. We're building and open-source [1] secure environments for running untrusted AI-generated code and AI agents. We call these environments sandboxes and they are built on top of micro VM called Firecracker [2].
You can think of us as giving small cloud computers to LLMs.
We recently created a dedicated SDK for building custom code interpreters in Python or JS/TS. We saw this need after a lot of our users have been adding code execution capabilities to their AI apps with our core SDK [3]. These use cases were often centered around AI data analysis so code interpreter-like behavior made sense
The way our code interpret SDK works is by spawning an E2B sandbox with Jupyter Server. We then communicate with this Jupyter server through Jupyter Kernel messaging protocol [4].
We don't do any wrapping around LLM, any prompting, or any agent-like framework. We leave all of that on users. We're really just a boring code execution layer that sats at the bottom that we're building specifically for the future software that will be building another software. We work with any LLM. Here's how we added code interpreter to Claude [5].
Our long-term plan is to build an automated AWS for AI apps and agents.
Happy to answer any questions and hear feedback!
[0] https://e2b.dev/
[1] https://github.com/e2b-dev
[2] https://github.com/firecracker-microvm/firecracker
[4] https://jupyter-client.readthedocs.io/en/latest/messaging.ht...
[5] https://github.com/e2b-dev/e2b-cookbook/blob/main/examples/c...
Managing tech debt is and will be an important issue in the world of AI software. I'm glad there's a company solving this. Additionally, this is something the current generation of LLMs are already helpful at solving. GritQL is very unique way of approaching this problem.
OT: We've been working with Grit and Morgante for the past months and I have only positive things to say about them. If GritQL looks useful to you, you should reach out.
We are running on GCP at the moment and using Nomad as our orchestration layer.
Our future goal is to move to bare metal as much as possible (I'm especially fan of Oxide https://oxide.computer/)
I'm the CEO of E2B. We're building a cloud runtime for AI agents. You can use it to build custom code interpreters for example.
We build this demo example with our sandboxes. Our sandboxes are isolated microVMs (Firecrackers) that you can quickly spawn (~1s) and control with our SDK. It's like a playground for AI agents.
We took GPT-4-Turbo, connected it to GitHub, and gave it our cloud sandbox as a playground.
The AI can:
- clone repo
- list, read, and edit files
- make commits and make PRs
You control everything from your terminal. The whole code is open source.
I'm a co-founder of E2B and we just released a simple way to run LLM-generated code in a sandboxed environments powered by Firecracker microVMs [0].
You essentially just import the `run_code` method, select a runtime and pass the code. We run it and return stdout and stderr. Without worrying about any infra.
A lot of E2B is open-source and we're on a track to open source our whole infra. [1]
[0] - https://github.com/firecracker-microvm [1] - https://github.com/e2b-dev/e2b
You can use to start sandboxed playgrounds where you can run LLM generated code, run headless browsers, let LLMs do data analysis, and more.
We've been building cloud for AI agents/copilots/AI apps. One of the first products that we're launching are AI Playgrounds. It's essentially a sandboxed VM (Firecracker [0]) where your agent can freely run code, use filesystem, use headless browser, and more. Every playground has also it's own URL. So for example you can have your agent start a webapp, let the agent work on it inside the playground, and because the playground has URL, the user can see all of the changes.
We've seen that it's especially useful for coding copilots and agents. They can easily run linters, formatters, or debug code and feed all this information back to LLM to make the next iteration better. Our short-term goal is to offer coding agents/copilots all of the tooling that human developers get in their coding editors. And have all of this happen in a secure sandboxed environment that people will eventually be able to self-host it.
You don't need to manage any infrastructure. You just call a single line of code with our SDK and we spin up a cloud playground in a few hundred ms for your AI app.
We have parts of our product open source here https://github.com/e2b-dev and are thinking of actually open-sourcing the whole infrastructure and make it really easy to 1-click deploy for anyone. One of the reasons we haven't done that is how much tooling we had to build on top Firecrackers and how much specialized environment they need. Which makes it a bit of challenge to offer great DX.
Happy to answer more questions!
I wanted to ask if you accept PRs for integrations?
I'm a co-founder of E2B [0]. We give private sandboxed cloud envs to any agent. We're building two things:
- [1] Agent Protocol - it's an open protocol that defines how to communicate with an agent. The current goal is to make benchmarking agents simple (it's used for example by folks at AutoGPT and other popular agents)
- [2] SDK that gives your agent a cloud environment (currently in early access)
Would love to figure out how to integrate these to into Axilla if it makes sense to you. What would be the best way to connect?
[0] https://e2b.dev/
[1] https://github.com/e2b-dev/agent-protocol
[2] https://github.com/e2b-dev/rest-api We built for example our ChatGPT plugin with it https://github.com/e2b-dev/chatgpt-plugin
We built a ChatGPT plugin that gives your ChatGPT instance access to a full cloud environment that's sandboxed. That means: - Access to Linux OS
- Using filesystem (create, list, and delete files and dirs)
- Run processes
- Sandboxed - you can run any code
- Access to the internet
Check out a demo where ChatGPT writes Nodejs code that scrapes GitHub [1]
These cloud instances are meant to be used for AI agents. Like a sandboxed playgrounds, where the agent can do whatever it wants.
The plugin is open source (not the infra where the cloud envs are running though) but isn't in the store yet so you need to have a dev access to ChatGPT plugins.
Happy to answer any questions!
[1] https://www.youtube.com/watch?v=kJuJnsatU2s?utm_source=githu...
> I do feel that long term there might be a common interface for agent <-> agent or user <-> agent communication. Definitely! We're just starting really small so we don't build the wrong thing and abstraction.
We'd would love to hear your thoughts and feedback on the direction of the protocol. And how the protocol could help Chidori and your users. Essentially, how we can get it to more agent devs and make it useful for them.
Would you be up for a chat? I'm @mlejva on Twitter
We've been exploring the space of AI agents and as part of our research we've made a list of both open source and closed source AI agents.
We've tried to include mostly just agents but the lines sometimes get blurry as it's hard to sometimes distinguish agents from SDK.
At the moment, a lot of these agents are still in the "toys" stage but we think the future looks very promising. Especially some of these agents are already pretty helpful.
Curious to hear what has been yours experience with agents?
Our editor isn't a regular coding editor. You don't actually write code with e2b. You write technical specs and then collaborate with an AI agent. Imagine it more like having a virtual developer at your disposal 24/7. It's built on a completely new paradigms enabled by LLMs. This enables to unlock a lot of new use cases and features but at the same time there's a lot that needs to be built.
A lot of UX, UI, DX work related to LLMs is completely new. We ourselves have a lot of new realizations.
> While you mention that you can bring your own model, prompt, etc, the current main use case seems to be integrating with OpenAI
You're right. This is because we started with OpenAI and to be fair it's easiest to use from the DX point of view. We want to make it more open very soon. We probably need more user feedback to learn what would be the best way how this integration should look like.
> How, if at all, do you plan to address the current shortcoming that the code generated by it often doesn't work at all without numerous revisions?
The AI agents work in a self-repairing loop. For example they write code, get back type errors or a stack trace and then try to fix the code. This works pretty well and often a bigger problem is short context window.
We don't think this will replace developers, rather we need to figure out the right feedback loop between the developer and these AI agents. So we expect that developers most likely will edit some code.
It's pretty nascent and a lot of work needs to be done so bear with us please. I'm traveling in 30 minutes but I'm happy to answer your questions.
A little about my co-founder and myself: We've been building devtools for years now. We're really passionate about the field. The most recent thing we built is https://usedevbook.com. The goal was to build a simple framework/UI for companies to demo their APIs. Something like https://gradio.app but for API companies. It's been used for example by Prisma - we helped them build their playground with it - https://playground.prisma.io/
Our new project - e2b - is using some of the technology we built for Devbook in the past. Specifically the secure sandbox environments where the AI agents run are our custom Firecracker VMs that we run on Nomad.
If you want to follow the progress you can do follow the repo on GH or you can follow my co-founder, me, and the project on Twitter:
- https://twitter.com/t_valenta
And we have a community Discord server - https://discord.gg/U7KEcGErtQ