Repository navigation
Add NRP + Claude AI credential support to CryoCloud config #6
Description
Activity
@cboettig and @mfisher87 do y'all have a sense of the first Open Question about the best practices for adding MCP/skills/etc on the fly vs. via the image? It doesn't seem like there is a simple way for people to install things on the fly via Jupyter-AI
Your assessment about Jupyter AI and installing personas is correct last I looked! Jupyter AI v3.2 is working on that.
I think in JAI 3.1 you can do slash commands in the normal way you would with your harness, but I haven't had the time to play with it yet. For example, installing Claude Code plugins that include skills:
/plugin install plugin-name@claude-plugins-officialOr make your own skills, by creating them in
~/.config/opencode/skillsor~/.claude/skills. Then you can let the LLM decide when to use them or invoke them manually with slash commands like/skill:my-skillin Opencode or/my-skillin Claude Code.I don't know about installing skills in an image. With personas, they can be installed as Python packages, but that may not always be the case, I'm not following that piece right now. For Claude Code and opencode, they support user-level "global" skills (in the home directory) and project-level skills (in the current directory). I believe these lookup locations are not friendly to truly global skills installations like you might do in a Docker image, i.e. outside the home directory. You can override opencode's whole config directory, but I think that's not what you want, you still want the user to have opencode config in their home dir and give them access to a library of skills on the image. I'm really struggling with how to achieve this.
so currently in JAI 3.0 it just calls the harness (opencode or claude code etc), and if the harness is already configured with the MCP it just works, so like Matt says I think the easy route is to just do that, e.g. in the standard home folder directory or project directory.
The lack of slash commands isn't really limiting since all harnesses can invoke mcp and skills implicitly from regular text anyway.
Hey all, if you have vercel's skills package in the docker image: https://github.com/vercel-labs/skills participants should be able to install any skills to any harness. During build you can potentially use the skills to install to the JHUB user home or if there's a postinstall, this can happen when things spin up. The following example is used for codespace, but I think it's transferrable (https://github.com/uw-ssec/llmoxie-rse-sandbox/blob/main/.devcontainer/install-skills.sh).
The lack of slash commands isn't really limiting since all harnesses can invoke mcp and skills implicitly from regular text anyway.
I think this is an important point for researchers to learn that one can create a model invokable and user invokable skills as some skills might be better to be invoked manually to be more explicit. Model-invoked skills increase the agent’s context size, adding token overhead and complexity. While User-invoked skills reduce unpredictability and invisible to the AI agent until called, so it lowers the token overhead.
Reacted by Tasha Snow@mfisher87 I think one could set CLAUDE_CONFIG_DIR to point to an image-controlled path, and then symlink subpaths there into
$HOMEto ensure that some user data is persisted.I think that @lsetiawan has a good idea here. I think that skills in general are a good idea to develop community practices around and a very useful llm workflow shaper in general. I think it's relevant to two goals/outcomes these kinds of meetings around AI often have:
- Shared domain practices: Skills are an easy way to encode a practice in a single text file and share it in a re-usable way. How to do this well, scope it properly, how to share it, what's worth a skill vs. not are all open questions that workshops like this can help build knowledge around.
- Model-agnostic practices: Skills mostly just text files, and things like the vercel skills tool make it really easy to install and put them where you want, so you don't need to constantly copy/paste etc. It helps de-risk any one model becoming too important for a researcher.
Reacted by Don Setiawan, Angus Hollands and Anshul T. Tambay
Context
We need to get NRP and Claude model access working in the CryoCloud 2i2c-based JupyterHub config, similar to what's already working for NRP via
opencodein the BIDS system, and eventually reaching parity in functionality with Scott Henderson's UW eScience CloudBank setup for Claude/Jupyter-AI, but ideally in a more user friendly way. We will also want to add more functionality and Carl's image below is a place where we can get an idea of how that works. We also need to figure out how we add agentic tooling on the fly and via the image in the best ways possible for developers and for users.Current image:
quay.io/cryointhecloud/cryo-python-ai:b5d1e91aaa4fReference image (Scott's, working):
ghcr.io/uw-escience-cloudbank/hub-image-jupyterai:latestCarl's Reference GeoAgent image for more advance things:
ghcr.io/geojupyter/jupyter-geoagent:sha-301d9b1NRP (mostly working pattern, but not yet installed on CryoCloud)
Claude (not working great yet)
~/.claude/settings.jsonfile with their per-user, short-lived token (works locally, in Claude CLI, and in the VS Code Claude extension). Not a great UX but functional.settings.json?Scott's working
~/.claude/settings.jsonexample{ "env": { "ANTHROPIC_BASE_URL": "https://cloudbank-litellm.westus2.cloudapp.azure.com", "ANTHROPIC_API_KEY": "<per-user token>", "ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-haiku-4-5", "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-5", "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-5", "ANTHROPIC_MODEL": "haiku" }, "availableModels": ["haiku", "sonnet", "opus"], "enforceAvailableModels": true, "theme": "auto" }Tasks
npm install -g @agentclientprotocol/claude-agent-acp?)~/.claude/settings.json(Scott's current approach) vs. baking config into the 2i2c hub config/image (like NRP/opencode)Open questions