K-Dense-AI/karpathy: an agentic ML engineer built on Claude Agent SDK and Google ADK

What karpathy actually automates, and for whom

The README describes karpathy as an agentic Machine Learning Engineer that trains state-of-the-art ML models using the Claude Agent SDK and Google ADK, and calls it a simple implementation demonstrating the power of Scientific Agent Skills for machine learning. That framing matters. This is a demonstration repository, not a framework with a versioned API. The homepage link and the note at the top of the README both redirect readers to www.k-dense.ai for more advanced capabilities and end-to-end machine learning, so the open repository is positioned as the entry point rather than the destination.

The audience is narrow and identifiable. You need Python 3.13 or higher, the uv package manager, and Claude Code installed and authenticated. If you have never installed Claude Code, the prerequisites section sends you to the Claude Code documentation before you can run anything. The project assumes you are comfortable with an agent loop, that you can read a Python file to understand what the setup script does, and that you are willing to place your own datasets into a directory by hand. Someone looking for a point-and-click model trainer will not find one here.

The sandbox is the architecture

There is no elaborate control plane. The mechanism is a prepared directory plus an agent that operates inside it. Running the startup script creates a sandbox directory containing skills pulled from Scientific Agent Skills, sets up a Python virtual environment with ML packages listed as PyTorch, transformers and scikit-learn, copies your .env file into that directory, and starts the ADK web interface. The agent then works against that sandbox, and the README states plainly that all outputs will be in the sandbox directory, so you monitor that folder while you converse with the agent.

The skills layer is the interesting part. Scientific Agent Skills is described as a collection of 130+ ready-to-use Agent Skills for research, science, engineering, analysis, finance and writing, built on the open Agent Skills standard, and the badges indicate the project works with Cursor, Claude Code, Codex and Google ADK. So the data flow is: your prompt goes into the ADK web UI, the agent selects from skills that are physically present in the sandbox, and execution happens in the sandbox virtual environment where the ML packages live. The environment variables are copied into the sandbox specifically so the agents can use any API keys you provide, which tells you the agent process is expected to make outbound calls from inside that directory context.

One consequence of this design deserves emphasis. Because the sandbox is a plain directory and not a container, isolation depends entirely on how the agent is configured and on what you put there. The README mentions Modal sandbox integration under upcoming features, which suggests the maintainers know that compute isolation is not solved yet.

Setup commands and the two environment variables that matter

The installation path is short. Clone the repository, change into it, and run uv sync. Then create a .env file in the karpathy directory containing OPENROUTER_API_KEY and AGENT_MODEL. The README states that OPENROUTER_API_KEY is required for the agent to function properly, and notes that this is the same environment variable that will be copied to the sandbox directory. AGENT_MODEL is left as a placeholder value in the example, so you supply the model name yourself. There is no list of supported model names in the material provided.

From there you have two routes. Running python start.py performs the full sequence: sandbox creation, virtual environment setup, .env copy, and the ADK web interface launch. You then open http://localhost:8000, select karpathy under Select an agent in the top left, and start a conversation. Alternatively, python -m karpathy.utils sets up the sandbox without starting the web interface, and you launch the UI separately with adk web, again at http://localhost:8000.

The manual route is the one worth knowing about, because it separates provisioning from serving. If the sandbox already exists and you only want to restart the interface, running the full start.py again means repeating environment setup you may not need. The README repeats the same warning in both places: any files you want the agent to use, including datasets and scripts, should be manually added to the sandbox directory. There is no documented ingestion command, no mount point, and no path configuration key.

Where the demonstration stops being enough

The most concrete limitation is stated by the project itself. The README says that if you want substantially more powerful ML capabilities through a multi-agentic system, you should sign up for www.k-dense.ai. That is an explicit boundary: the open repository is single-agent in the sense the README presents it, and the multi-agent path lives behind a hosted product. If your workflow needs several agents dividing preprocessing, training and evaluation, this repository is not that.

Compute is the second gap. The upcoming features list Modal sandbox integration with the note that you can choose any type of compute you want. Until that lands, training happens in whatever environment the sandbox virtual environment runs in, which in practice means your own machine. For anything beyond small experiments, that is the wrong tool, and the README does not claim otherwise.

Third, there is no release history. The repository metadata shows no releases retrieved, so there is no tagged version to pin, no changelog to read before upgrading, and no compatibility promise between commits. The last push timestamp is the only signal of activity. Anyone treating this as a dependency rather than a reference should weigh that carefully.

Finally, the name. The disclaimer states the project is not endorsed by or affiliated with Andrej Karpathy and that the name is used as a tribute. That is honest, but it also means search results and package references will be ambiguous, and you should not assume any relationship between this code and his work.

How this differs from a conventional AutoML library

The obvious comparison is a library such as scikit-learn's own model selection tooling or a dedicated AutoML package. Those give you a fixed API: you pass an estimator, a parameter grid or a search space, and you get back fitted models and scores. The behaviour is deterministic given the same inputs, the search is bounded by the space you declare, and the output is a Python object you can inspect programmatically.

Karpathy inverts that. The search space is not declared in code. It emerges from the agent's reading of your prompt and its selection among the skills present in the sandbox, with the model named by AGENT_MODEL doing the reasoning. The output is files written into the sandbox directory rather than returned objects. You get flexibility in exchange for reproducibility: two runs of the same prompt are not guaranteed to take the same path, and there is no configuration file that pins the strategy.

That trade-off is the whole point of the project, and it is also why it should not be dropped into a pipeline that needs auditable results. If you need to explain to a reviewer exactly which hyperparameters were tried, a declarative search in scikit-learn will serve you better. If you want to see whether an agent can pick sensible ML steps from a library of skills and run them, this is the experiment.

Maintenance cost, licence and what to check before depending on it

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement and imposes no copyleft obligation on your own code. This is a description of the licence text, not legal advice; if you are embedding the project in a product, have your own counsel review how you distribute it and how the attribution requirement is satisfied.

The maintenance picture is less comfortable. With no releases, upgrading means pulling from main and re-reading the README, because there is no changelog to tell you what moved. The setup script provisions a virtual environment and copies your .env into the sandbox, so a re-run after an upgrade can overwrite environment state you have customised. Skills come from the separate Scientific Agent Skills repository, which means the behaviour of your agent can change when that upstream collection changes, independently of anything in this repository. Two moving parts, one of them external.

The practical check before you build on it: confirm that the sandbox directory is not inside a path you would mind the agent writing to, since all outputs land there and you add datasets to it manually. Confirm that your OpenRouter key and chosen AGENT_MODEL are valid together, because the README gives no fallback if the model name is wrong. And read karpathy/utils.py before running python -m karpathy.utils, since that module is what performs the sandbox provisioning and is the only place the actual steps are defined.

Editorial conclusion

Adopt karpathy if you want a readable reference for how an agent drives PyTorch and scikit-learn inside a prepared sandbox, and you already run Claude Code with an OpenRouter key. Do not adopt it if you need a supported AutoML service, multi-agent orchestration, or anything with a release history, since the repository lists no releases. Before committing, verify that Python 3.13 and uv are available on your machine, that AGENT_MODEL resolves to a model your OpenRouter key can call, and that the sandbox directory created by start.py is somewhere you are willing to drop datasets by hand.

Official sources

1. Issues
2. K-Dense-AI/karpathy on GitHub
3. License: MIT
4. Project website
5. README