Sandboxed Python in the conversation
A sandboxed Python execution environment that Althea uses to write, run, and check code without leaving the conversation.
The code agent generates scripts, installs dependencies, runs code, and returns the results, plots and metrics included, directly in the conversation.
Much of its research value is reproducibility. A claim in a paper looks load-bearing for your work, but the paper is vague about the detail you need. The repo may or may not run outside the authors' machine. The code agent clones it and finds out.
A query that triggers the code agent
The code agent operates as one tool in Althea's toolkit, and a single request can trigger several agents in sequence. The prompt, verbatim: "Find the official code base of the FSNet paper (NeurIPS 2025), clone the repo and figure out if they use dropout."
The Research Agent locates the paper and its official repository, then hands off to the Code Agent, which clones it and searches the codebase for dropout. The answer comes back within seconds, with the relevant files and line numbers.
The plan
Research Agent finds the paper and its repository, Code Agent clones and searches.
Okay, so the task is to locate the official code for that "FSNet" paper from NeurIPS 2025 and figure out whether they're employing dropout. This sounds straightforward enough, but it's a methodical process. I need to break this down into logical steps.
First, I need to get my hands on the paper itself. It's the most likely place to find a direct link to the code. I'm going to start by leveraging my search capabilities using tiptree-systems/scientific-research/search-literature – seems like the right tool for the job.
If, and it's a big "if," the paper doesn't have a code link, I won't panic. I'll simply resort to a focused web search. I'll fire up tiptree-systems/web-search/search and craft a specific query. Something like "FSNet NeurIPS 2025 code repository" should do the trick. I'll adapt my search terms as needed if the initial query isn't fruitful.
Once I have that repository URL, the rest is easy. I'll tap into the code_assistant to clone the repository, and then I'll perform a quick scan of the code for any mentions of "dropout." It's a simple text search, but it's crucial to confirm whether they're using that regularization technique. Let's start with step one; finding that paper is the priority.
Okay, so the user wants me to track down the official codebase for the FSNet paper and see if they're leveraging dropout. My plan is pretty straightforward, leveraging my typical workflow for these types of requests.
First, I've got the arXiv preprint link, which is a great starting point. I'll kick things off by assuming, as I usually do, that the authors were responsible and included a link to their repository directly on the arXiv page. So, step one involves using the answer-from-url task to quickly parse that page and locate any obvious codebase links. I'm quite efficient at this; I've seen this setup countless times.
Assuming I find the repository link, the next logical step is to dive into the code. I'll hand things off to the code_assistant. I'll use it to clone the repository, which is a fairly standard operation for me. After the clone is complete, I'll direct it to run a search for the keyword "dropout" within the codebase. This is a quick and effective method to get an initial overview of the code and understand if it's utilized.
Finally, I'll synthesize my findings and respond directly to the user. I'll provide a clear summary of whether or not dropout is used, and potentially other related details, based on my analysis of the codebase. That's the plan. Let's get to work.
The same pattern runs across tools. A deep-research run can produce citations the code agent then validates by inspecting the linked source code, and a web search can retrieve a dataset URL that it downloads and analyzes. When subtasks are independent, Althea dispatches them concurrently instead of queueing them.
Plots on request
The sandbox also works from a rough one-liner. Below is a real exchange, kept verbatim, and the sandbox's own log of the work behind it.
Step 1 · The request
The prompt as typed, and the plot that came back.
do a little scikit learn plot as an example of code agents
Here is a quick example of what the code agent can do with scikit-learn.
I had the agent generate a synthetic "moons" dataset and train a Support Vector Classifier (SVC) to separate the two classes. The plot below visualizes the decision boundary it learned.
Step 2 · A different dataset
The follow-up. The agent swaps in iris and a different model.
can you use a diff datset?
Absolutely. Here is an example using the classic Iris dataset.
This time, I had the agent train a Decision Tree Classifier using just the first two features (sepal length and width) so we can easily visualize the decision boundaries.
Step 3 · Inside the sandbox
The log behind the first plot. The script written to disk, run, and verified.
How it works
The sandbox is an ephemeral container. It writes the script, installs dependencies, runs, and returns plots and metrics inline. Drop a CSV or JSON straight into the chat (up to a few gigabytes) and the sandbox sees it. Point it at public repos, or connect GitHub to run the same treatment on your own code, and let it open pull requests. For the bigger version of this loop, launching and tracking actual training runs, see Integrations.
Compute-heavy reproductions belong on your own hardware rather than the sandbox, which is what the W&B connection is for.