Add NRP + Claude AI credential support to CryoCloud config

[tsnow03]

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 opencode in 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:b5d1e91aaa4f
Reference image (Scott's, working): ghcr.io/uw-escience-cloudbank/hub-image-jupyterai:latest
Carl's Reference GeoAgent image for more advance things: ghcr.io/geojupyter/jupyter-geoagent:sha-301d9b1

NRP (mostly working pattern, but not yet installed on CryoCloud)

• opencode is mounted/configured to point at NRP via hub-deploy/hubs/demo/config.yaml (L257–299)
• opencode env var wiring (apiKey match in deployment): hub-deploy/hubs/demo/config.yaml (L229)
• opencode install (one-liner): hub-deploy/images/user/install-opencode.sh (L6)
• Needs our NRP alias + key added to that config
• No process yet for rotating that key regularly

Claude (not working great yet)

• Logging into Claude via terminal needs to connect it to Jupyter-AI
• Workshop will need per-user CloudBank keys for Claude
• @scottyhq approach: each user manually drops a ~/.claude/settings.json file 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.
• Question for the group: is there a way to do this more like the NRP setup (baked into the 2i2c config / image) rather than each user manually creating settings.json?

Scott's working ~/.claude/settings.json example

{
  "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

• Add NRP integration + API key for OpenCode config
• Define a key rotation process for the NRP key (owner, cadence, where it's stored/updated)
• Make sure terminal Claude login (and any other new LLM) link to Jupyter-AI - what is this mechanism (via npm install -g @agentclientprotocol/claude-agent-acp?)
• Decide on workshop credential-delivery approach for Claude: per-user manual ~/.claude/settings.json (Scott's current approach) vs. baking config into the 2i2c hub config/image (like NRP/opencode)
• Decide on security approach for dealing with Claude credentials saving when people use their own credentials - Claude workshop approach will not be used for the rest of users after the workshop, they will use their own credentials
• If going the config route: design how per-user CloudBank keys get injected (env var per user? templated settings.json at spawn time?)
• Prototype Claude + Jupyter-AI integration using Scott's demo token / image as reference for how it should look at the end
• Ensure we have a way of keeping user AI from having write priveleges in the shared directories
• Document final setup for workshop users

Open questions

• How do we add MCP, skills, etc. on the fly AND via the image?
• Can CloudBank key provisioning per user be automated the same way NRP's key is being added centrally, or does it inherently need to be per-user/short-lived (and therefore harder to bake into a shared image)?

[tsnow03]

@agoose77 @cboettig

[tsnow03]

@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

[mfisher87]

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-official

Or make your own skills, by creating them in ~/.config/opencode/skills or ~/.claude/skills. Then you can let the LLM decide when to use them or invoke them manually with slash commands like /skill:my-skill in Opencode or /my-skill in 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.

[cboettig]

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.

[lsetiawan]

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.

[agoose77]

@tsnow03 can you share more about the Claude usage — will users bring their own Claude accounts?

[agoose77]

@mfisher87 I think one could set CLAUDE_CONFIG_DIR to point to an image-controlled path, and then symlink subpaths there into $HOME to ensure that some user data is persisted.

[choldgraf]

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:

1. 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.
2. 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.