Carl Boettiger

@cboettig.bsky.social

Ecology, theory, computers. https://carlboettiger.info

how in the space of a week do both frontier labs go 'oops we forgot to unplug it from internet first' -- in violation of basic security practices, and yet this story will somehow be remembered forever history as a landmark 'advance in AI' that rendered human security experts irrelevant...

Last year was the year of teaching with frontier closed models through GitHub copilot -- opus for all! those doors are shut (and RIP GitHub Classroom). Now what? Thinking this is the year we start on OpenRouter & opencode / kilo code?

c 2023, near daily in discussion with students: pandas is causing the OOM kills. why didn't consider duckdb/ibis? (like we covered in class?) c2026, near daily discussion with the LLM (& LLMs of students): no not pandas! duckdb! 🦆🦆 (didn't you read the AGENTS.md?)

hmm, openshell looks pretty interesting: github.com/NVIDIA/OpenS... basically just runs your agent in an OCI container (like we already do) but with networking etc locked down by default and controlled from an external instance. Nice to see open innovation around hard controls instead of prompts

GitHub - NVIDIA/OpenShell: OpenShell is the safe, private runtime for autonomous AI agents.

OpenShell is the safe, private runtime for autonomous AI agents. - NVIDIA/OpenShell

github.com

...and GitHub quietly removes Claude Sonnet/Opus from the its student plan mid semester... fun. 🙃 we're just about to dive into local models in 288 anyway but this is surely disruptive. If students are going to learn to use these tools they ought to know what the frontier tools are like

folks, please don't submit LLM-generated PRs to open source projects. It makes no sense. If the maintainers want to use an LLM to fix an issue, they can use Claude or whatnot directly. They don't need you as intermediary, that's just silly. If they don't want to use LLMs, they have reasons.

Rather applaud JOSS's revised approach to deal with AI-based submissions. blog.joss.theoj.org/2026/01/prep... , particularly with 'starting open' and at least 'six months developer history'. More of scholarly pub could benefit from such policies methinks.

Preparing JOSS for a generative AI future: From code to human creativity and design | Journal of Open Source Software Blog

Blog for the Journal of Open Source Software • <a href='https://joss.theoj.org'>https://joss.theoj.org</a>

blog.joss.theoj.org

it is kinda delightful to see that the open-source Continue.dev plugin fully supports modern MCP (resources, prompts), while GitHub Copilot plugin only supports tool docstrings. Now my continue.dev makes perfect tool calls using small/dumb open source LLMs, while CoPilot fails w/ frontier LLMs 🙃

Continue - Ship faster with Continuous AI

The future of coding isn't writing more code. It's delegating the boring parts, so you can build the interesting stuff

continue.dev

Argh! @github.com announces it will start charging even for *self-hosted* runners 😥. resources.github.com/actions/2026... I have long relied on my self-hosted runners in my teaching to run automated 'reproducibility' checks. (The edu allocation is way too small for my large classes).

Pricing changes for GitHub Actions

GitHub Actions pricing update: Discover lower runner rates (up to 39% off) following a major re-architecture for faster, more reliable CI/CD.

resources.github.com

we released olmo 32b today! ☺️ 🐟our largest & best fully open model to-date 🐠right up there w similar size weights-only models from big companies on popular benchmarks 🐡but we used way less compute & all our data, ckpts, code, recipe are free & open made a nice plot of our post-trained results!✌️

Bild
Ai2@ai2.bsky.social · last yr.

Announcing OLMo 2 32B: the first fully open model to beat GPT 3.5 & GPT-4o mini on a suite of popular, multi-skill benchmarks. Comparable to best open-weight models, but a fraction of training compute. When you have a good recipe, ✨ magical things happen when you scale it up!

sad to be missing #jupytercon this week! But small win, recently made my first PR to JupyterHub fancy-profiles to add support for ARM architecture. & now I have JupyterHub running on an NVIDIA DGX Spark (via k3s). Also have CUDA/RAPIDS based image in rocker for python+R envs, rocker/cuda:arm64

The 1.4 release of @duckdb.org supports using a DuckDB database to serve vector tiles! Of course, I had to try this out in R. Check it out: all 242,000 US Census block groups dynamically served as vector tiles from a DuckDB database, displayed on a MapLibre map from R in Positron.

All 8.1 million US Census blocks. Visualized smoothly in 3D. Instant population and housing totals from a lasso selection. All running seamlessly in the browser, no traditional backend. While everyone’s talking about AI, it’s an incredible time for geospatial tech.