CodeAct Agent

Generates executable Python code as the primary action mechanism for LLM agents instead of JSON tool calls or text responses. The system consolidates all agent actions (tool invocations, computations, state management) into a single Python code generation target, allowing the LLM to leverage full programming language expressiveness. This unified action space is then executed in isolated environments and results are fed back to the LLM for multi-turn refinement.

Executes LLM-generated Python code in containerized or sandboxed environments (Docker containers, Kubernetes pods, or Jupyter kernels) with automatic capture of execution results, errors, and stdout/stderr. Failed executions are returned to the LLM with full error context, enabling multi-turn refinement loops where the agent can inspect errors and regenerate corrected code. Each conversation maintains its own isolated execution context to prevent state leakage.

Automatically captures execution errors (exceptions, syntax errors, import errors), stdout/stderr output, and return values from executed code. Formats results into structured objects that include error type, traceback, execution duration, and output. This structured format enables the LLM to parse and understand execution outcomes for subsequent reasoning steps.

Stores complete conversation transcripts in MongoDB including user queries, generated code, execution results, and LLM responses. Enables session resumption, conversation browsing, and audit trails. Conversation state includes metadata like timestamps, execution durations, and error counts. Supports querying and filtering conversations by various criteria.

Implements a feedback loop where execution errors are returned to the LLM with full context (error type, traceback, failed code), and the LLM generates corrected code in the next turn. The system tracks error history and can provide hints about common failure patterns. Supports multiple refinement iterations until code succeeds or user-defined iteration limits are reached.

Implements a conversation loop where the LLM generates code, the system executes it, captures results, and feeds execution output back to the LLM for subsequent reasoning steps. The LLM can inspect execution results, errors, and state changes to dynamically adjust its next action. This creates a feedback loop where agent behavior is informed by real execution outcomes rather than simulated tool responses.

Provides a full-featured web UI for interacting with CodeAct agents through a chat-like interface. Conversation history is persisted in MongoDB, enabling users to resume sessions, review agent reasoning, and inspect generated code and execution results. The interface handles multi-turn interactions, displays code generation and execution output, and manages conversation state across browser sessions.

Exposes CodeAct agent functionality through a Python API, allowing developers to instantiate agents, send queries, and retrieve results programmatically. This interface abstracts away infrastructure details (execution engine, LLM service) and provides a simple function-call API for integrating agents into larger Python applications or scripts.

Abstracts LLM inference across multiple backend options (vLLM for high-throughput serving, llama.cpp for local inference, cloud APIs) through a unified interface. The system can be configured to use different LLM backends depending on deployment context (laptop, server, Kubernetes cluster) without changing agent code. Supports CodeActAgent-Mistral-7b-v0.1 (32k context) and CodeActAgent-Llama-7b (4k context) variants.

Deploys code execution in Docker containers where each conversation spawns a dedicated container with a clean Python environment. Containers are created on-demand, execute code, capture output, and are destroyed after the conversation ends. This approach provides strong isolation between conversations and prevents state leakage while maintaining simplicity compared to Kubernetes.

Deploys code execution across Kubernetes pods where each conversation or execution request spawns a pod in a Kubernetes cluster. Pods are managed by Kubernetes for resource allocation, scheduling, and automatic cleanup. This enables horizontal scaling across multiple nodes and automatic load balancing. Integrates with vLLM for distributed LLM serving on the same cluster.

Executes code using persistent Jupyter kernels running locally or on a server. Code is sent to the kernel, executed in the same Python process, and results are captured. This approach maintains state between executions (variables, imports, definitions persist) and provides fast execution without containerization overhead. Suitable for development and research workflows.

Exposes code execution functionality through a REST or gRPC API, allowing external systems to submit code for execution and retrieve results. The API abstracts the underlying execution backend (Docker, Kubernetes, Jupyter) and provides a unified interface for code submission, result retrieval, and error handling. Enables integration with non-Python systems and microservice architectures.