colab-jupyter possibility

[trungleduc]

Hi team,

I’m exploring workflows that mix Colab’s managed kernels with local Jupyter-based interfaces. Since colab-vscode already provides a bridge between Colab and VS Code, I’m wondering about the feasibility of something similar for Jupyter—essentially a “colab-jupyter” integration.

The idea would be:

• Use the browser-based Jupyter UI (JupyterLab or classic) locally
• Connect its kernel operations to a running Colab backend
• Preserve the Colab environment, GPU/TPU access, and files
• Keep the Jupyter UX and extensions (notebook editor, terminals, file browser, etc.)

A few questions:

• Would the existing Colab APIs support such a connection, or does colab-vscode rely on VS Code–specific capabilities?
• Is there any documented or unofficial protocol that Jupyter clients could implement?
• Are there technical blockers that make a Jupyter integration impractical?

If this isn’t planned, would you be open to external contributions or experimentation?

Thanks for the great work on colab-vscode. I'm curious to hear your thoughts on whether this could be extended to Jupyter.

[kevineger]

Hey @trungleduc - thanks for reaching out!

I’m wondering about the feasibility of something similar for Jupyter

Highly feasible 🙂

Would the existing Colab APIs support such a connection, or does colab-vscode rely on VS Code–specific capabilities?

They would (support such a connection). While naturally some of this project does rely on VS Code APIs (registering commands, binding to the UI, etc.), the bits for establishing the connection (provisioning a Colab server, keeping it alive, etc.) are highly portable. In fact, I suspect a lot of folks who've already forked this repo are doing it just to snag the client.ts. To be frank, the Colab APIs aren't quite as clean as they could be, but the client written here for this project should abstract away the majority of those complexities.

Is there any documented or unofficial protocol that Jupyter clients could implement?

client.ts is the most immediate thing I'd point to. Each of the public methods (and tracing back references from them) should paint the overall picture of how to provision a server, keep it alive and use it.

Are there technical blockers that make a Jupyter integration impractical?

Admittedly, I've not tried extending Jupyter before. But I can't think of any potential hard blockers.

---

If this isn’t planned, would you be open to external contributions or experimentation?

While I wasn't going to start working on this over the next month or two, we are very interested in trying to put this together. If you're interested in contributing/collaborating, we'd certainly be open 👍 . May just be a question of timing and logistics on our end. If interested, please feel free to reach out directly and we can discuss possibilities!

CC'ing a couple Colab folks that I know would be interested in this @metrizable @EvanWiederspan @wh1ter4bb1t-js.

[kevineger]

Just noting here - mostly so I remember to look into it, there may be some additional work to do as it pertains to OAuth.

[davidpham87]

Would it be possible to make a API definition agnostic to the language and editor?

I mostly work in emacs, and I have been dreaming of connecting my script to colab since it was introduced (I tried to ssh into colab, etc). It would be awesome to be able to connect a jupyter console to a collab server, by using the %connect_info magic command.

I am sure other Googlers would also be interested.

[kevineger]

While it's an idea we've been kicking around internally, at this time I can't make any commitments regarding a fully supported public API.