OxCaml Labs
We're exploring systems applications for Oxidised OCaml (or 'OxCaml' for short). The language extension itself is primarily developed by Jane Street, and our research group here focusses on building high-performance systems in OxCaml that are competitive with other "systems" languages such as Rust, as well as exploring new trends such as the impact of AI-assisted development. We've been working on mainline OCaml for a long time, and so we also help with stewardship activities around the wonderful OCaml community as well and maintaining tools and code we've released over the years.
This is all a highly collaborative effort across the group. The team is a merry band of postdoctoral associates and PhD students, including myself (Anil), Jon Ludlam, Mark Elvers, Patrick Ferris Ryan Gibb, David Allsopp (departed to Jane Street at the start of 2026), Sadiq Jaffer and Michael Dales. Everything below is joint work not only within our group, but also across close collaborators such as Tarides, the FP Launchpad, Jane Streeters, and the wider community.
Here follows a review of roughly our first year of activity of OxCaml Labs, from around February 2025 to March 2026.
1 OCaml Community Stewardship
The first topic is something of a continuation of OCaml Labs, and helps to motivate our interest in OxCaml. We maintain and improve the shared tooling and infrastructure that the upstream open-source OCaml ecosystem depends on.
1.1 Documentation, Tutorials and Lectures
A healthy programming language needs documentation, accessible teaching materials, and a welcoming community. We've been organising OCaml's participation in Outreachy since its inception. This scheme provides paid internships in open source for people underrepresented in tech. In the June 2025 round, we mentored two interns: one built Claudius, a fantasy-console graphics library, and another extended dune to discover system information. In the December 2025 round, three interns worked on Raven dashboards for ML experiments, better errors for YOCaml, and writing TIFF files in pure OCaml — the last of which feeds directly into our geospatial stack that we'll come to later!
1.1.1 odoc
odoc 3 is a major overhaul of OCaml's documentation generator, adding rendered source code navigation, type-based search via sherlodoc, cross-package linking into a web of interconnected docs across packages, a global sidebar, and media support to mvoe beyond just text.
We drove it into production use on large codebases (such as Jane Street's) with fixes for complex features such as module-type-of. After this, we rolled out package documentation on ocaml.org for all of opam in July 2025 with the ocaml-docs-ci scaling to 20k+ packages.
Once this was deployed, the rest of the year was spent getting it into full production use with odoc bug fixes, sherlodoc search integration, and support for OxCaml modes and layouts (more on that later!).
1.1.2 PPX syntax extensions
OCaml's PPX system allows developers to extend the language with custom syntax transformations and code generation (similar in spirit to Rust's procedural macros, working at the AST level). That's the good news; the bad news is that every single compiler release changes the AST, requiring updating almost all of the syntax extensions.
The community unified around ppxlib as the single framework for writing these extensions as a central place to perform these AST upgrades, and we help maintain it by bumping the ppxlib AST each time a new compiler version changes the parse tree, and then sending patches to downstream PPX authors.
1.1.3 Undergraduate teaching with notebooks
While I was on sabbatical in 2025-2026, Jon Ludlam covered the Cambridge 1A FoCS course and built interactive OCaml lecture slides using Slipshow combined with x-ocaml, a web component that compiles and runs OCaml code directly in the browser via js_of_ocaml. The lecturer can now modify and execute code snippets live during lectures, with type-on-hover and programmatic highlighting of the OCaml code (very useful for the notorious 'giving change' algorithm in the middle of the course).
The same technique is now one we're investigating to power interactive TESSERA notebooks that let users draw regions on a map, fetch embeddings, place training labels and run classifications all client-side in OCaml compiled to JavaScript. Separately, we built a transpiler from OCaml to Hazel (paper), bootstrapping a corpus of ill-typed OCaml programs for the Hazel live programming environment as well.
1.1.4 Reflections and experiments
We wrote an extensive Irmin retrospective to look back at a project that's been going for over a decade now. Monthly OCaml Roundups and quarterly summaries also helped to keep the community informed, alongside writeups with more detail on coding agents and fixes to the OCaml runtime.
Fun experiments also abound: we've been running multicore OCaml 5 on a Raspberry Pi Pico 2 microcontroller, building eInk display drivers on a Raspberry Pi, writing a complete ray tracer in OCaml using TSDL, OCaml 5 Domains, and Atomics (with performance work on reducing heap allocations), and getting into FPGA programming with HardCaml.
One issue we're facing now is the number of communications channels available, so blogging has been a good way to keep up with our individual progress while also keeping each other informed!
1.2 Package management
Every OCaml project depends on a toolchain of compilers, package management, build systems, and continuous integration to turn source code into useful software. We maintain significant parts of this infrastructure and are also researching how to make it better in the future.
1.2.1 Continuous Integration
OCaml-CI is the shared continuous integration service that automatically tests every package submitted to the opam repository across multiple OS and architecture combinations before it can be merged. We run and maintain the underlying cluster of build workers (spanning Linux x86/ARM64/PPC64/s390x/RISC-V, macOS, Windows and FreeBSD). This involves quite a bit of infrastructure shuffling last year as our Scaleway and ARM sponsorships both expired, so we spent time moving the cluster to Cambridge, issuing Docker base images for new compiler releases, adding Windows builds, FreeBSD, ARM64 workers, and 32-bit backends. We also documente how to distribute OCaml via Homebrew for macOS users.
On the build side, we replaced the flaky Windows/containerd stack with OBuilder on Windows HCS and compared BuildKit against OCurrent for image building. I suspect that OCaml's use of Windows containers might be one of the largest such uses in the world, given the large number of bugs we've run into.
1.2.2 opam and dune
opam is OCaml's package manager, and dune is the build system that compiles OCaml projects. Together they form basis of the OCaml Platform of default developer tooling. We help maintain the opam package repository and contribute to both tools.
The opam repository is a community-maintained collection of package metadata, via a large Git repository where every OCaml library has a file describing its dependencies, build commands, and compatibility constraints with other packages. When someone runs opam install, a constraint solver finds a compatible set of packages. We help review and merge submissions, and maintain tooling around the repository itself.
Day-to-day maintenance included retiring legacy compiler versions from the CI matrix to keep the size of tests under control, migrating to opam 2.5, improving dependency solving and solver caching, and the perennial question of whether semantic versioning makes sense for OCaml (spoiler: no). The Day10 bulk testing tool can rebuild the entire package database in half an hour on a single multicore machine, and we use it to compare builds across compiler variants to, for example, catch packages that break when switching from OCaml 5.4 to 5.5 or from mainline to OxCaml or if we remove ocamldoc from the computer distribution.
1.2.3 Researching new formalisms
On the research end, we're developing formal models for dependency resolution that give insights into how to evolve systems like opam and Docker. This started with using hypergraphs for resolutions and then "Package Managers à la Carte: A Formal Model of Dependency Resolution", formalising dependency resolution across ecosystems. We built the Pac tool, got opam-nix integration merged upstream, and presented three talks at FOSDEM 2026: package management formalised, Eilean, and Opam's Nix mechanism.
Shelter is a data provenance system/shell built with OCaml and Eio that uses eBPF tracing to track how data is flowing through an interactive system. It support imports for modularity and sessions with full lineage tracking, and we've been working on running the Mapping LIFE on Earth biodiversity pipeline through it to get end-to-end data provenance.
1.3 Core compiler development
There's also the nitty gritty of working on the main OCaml compiler project.
1.3.1 OCaml Relocatable OCaml
Together these make it possible to ship self-contained OCaml installations without absolute paths. This might sound pedestrian, but it's critical for fast opam switch cloning, Docker images, and cross-compilation that all need custom toolchains in specific locations (and can now just move binaries around rather than spend minutes compiling from source).
We then backported all this to OCaml 4.13+ and cleaned up compiler packaging in opam. We also reviewed thread-safe POSIX functions, Unix.unsetenv), Domain.count and FlexDLL updates for 5.5.
1.3.2 OCaml 5.4 and 5.5 and beyond
Back in OCaml 5.4, we contributed string conversion functions for the C API, frame table linker fixes, frame pointer maintenance, cloexec fixes for Windows CRT descriptors, native symlinks on Windows, Windows target triplet validation, and BUILD_PATH_PREFIX_MAP support for .cmt files. We reviewed the runtime events timestamp addition, making Gc.control globals atomic, and a Unix.getgroups fix for musl. Many of these are aimed towards winning on Windows (an effort that started back in 2018!) while others improve the robustness and observability of multicore.
Beyond upstream, we explored using effects in the compiler itself and rethinking file descriptor abstractions for ocaml-uring, as well as how static linking works and OCaml 5.4 native ARM32 (out-of-tree, as 32-bit native output is being deprecated upstream).
2 OxCaml for High-Performance Systems
We're also trying to push on the frontiers of OCaml performance through the extensions available in OxCaml. We're doing this by building our research systems to exploit zero-allocation, unboxed types, modes, and SIMD, usually in networked infrastructure such as TESSERA and planetary dashboards.
2.1 Getting familiar with OxCaml
It was a little daunting getting started with OxCaml since it's got a high development velocity within the walls of Jane Street. While helping with the open source release last summer, we built OxCaml base images and an opam-repository for OxCaml, and documented the experience of trying OxCaml and discovering its internals.
After that, we helped to run an OxCaml tutorial at ICFP 2025 covering modes, locals, and performance engineering (also using Slipshow as the FoCS notebooks did). We also published a fun and direct OCaml vs OxCaml Pi Day comparison to demonstrate performance tradeoffs. Our ICFP reflections covered data race freedom and the multicore saga, and there were trip reports from multiple group members about the rest of ICFP.
2.2 High-performance OxCaml systems
After this, it was time to get our research infrstructure going. We built httpz, a zero-allocation HTTP/1.1 server using unboxed types and local allocations that now runs this website. We ported compression libraries (Brotli, Zstd, Snappy) to OxCaml in a monorepo to experiment with SIMD, built an ONNX inference engine using OxCaml SIMD intrinsics, and benchmarked GPU vs CPU inference. We're using all these pieces to help train and infer TESSERA embeddings. For fun, we also optimized an MP3 codec comparing OCaml and OxCaml performance.
2.2.1 Planetary Computing with TESSERA and LIFE
A major application of our OxCaml work is deploying the TESSERA, a pixelwise geospatial foundation model geospatial model, which involves manipulating petabytes of satellite data. We've been building the data infrastructure for earth observation, biodiversity monitoring, and geospatial analysis in a combination of Python, OxCaml and of course...shell scripts. Most of the ecosystem for geospatial analysis is currently in other languages, so this involves grassroots library work from many directions: either from scratch, or FFI bindings, or a combination.
We built an end-to-end TESSERA inference pipeline in OCaml using ONNX bindings, progressing through early Zarr v2 support and STAC tile serving. The OxCaml-Zarr transcoding pipeline went from prototype to browser-based streaming via wasm/WebGPU, and the full Zarr v3 conventions are now documented. On the application side, we demonstrated finding solar farms with a 42k-parameter model using TESSERA embeddings, and built OpenStreetMap protobuf and DuckDB bindings in OxCaml for combining vector data with pixel embeddings.
The Yirgacheffe declarative geospatial library was presented at PROPL and published. It's designed for processing rasters at planetary scale (the LIFE biodiversity pipeline works with 80-terapixel habitat maps) and recent work on area-per-pixel maps eliminated an entire pre-computed raster by calculating pixel area on demand from the map projection. We also worked on Parquet file optimization for geospatial data formats.
2.2.2 GeoCaml
In parallel, we're assembling geocaml, a suite of pure OCaml geospatial libraries that can eventually replace C dependencies like GDAL for our use cases. The centrepiece is ocaml-tiff, a pure OCaml TIFF reader and writer. Our Outreachy intern delivered LZW decompression speedups and added write support. Around it we maintain OCaml bindings to PROJ4 for coordinate reference system projections, a WKT codec for well-known text format, an R-Tree spatial index adopted from old friend Marius Eriksen, and ocaml-geojson. The goal is to reach a critical mass where these libraries reinforce each other, and we're getting there with early success porting geotessera to OCaml using ocaml-tiff for landmasks and Nx for array operations.
More broadly, we co-chaired the Programming for the Planet workshop at ICFP, gathering enthusiastic functional programmers interested in planet-positive action! PROPL will return in 2026 in PLDI...stay tuned.
3 AI-Assisted OCaml Development
Claude Code appeared just as we started OxCaml Labs, and has completely turned software development on its head. We've spent a good chunk of time figuring out how OCaml and LLMs can work well together: improving training data, building tooling, benchmarking, and developing practices for agentic coding.
We presented "Three steps for OCaml to crest the AI humps" at the OCaml Workshop, benchmarking OCaml's representation in foundation models. We curated an opam archive dataset for LLM training, evaluated 19 local LLMs on OCaml, and built GC debugging benchmarks for agents to make sure OCaml was represented in frontier model evaluations.
On the tooling side, we built an OCaml MCP server and integrated ocaml-lsp via MCP for AI coding, Cresting the OCaml AI humps surveyed the broader ecosystem, and we published a prebuilt devcontainer for OCaml/OxCaml with Claude Code and explored adversarial approaches to teaching OxCaml to agents. To keep up with the firehose of activity across OCaml's GitHub repositories, we also built Ruminant, a tool that syncs thousands of issues, PRs and discussions and uses Claude to generate condensed weekly digests — published regularly on thicket.dev so anyone can follow what's happening across the ecosystem without drowning in notifications.
3.1 The Advent of Agentic Humps
In order to really push the limits, we also did a December Advent of Agentic Humps in which we built 25 O(x)Caml libraries in 25 days with Claude Code to stress-test agentic coding for OCaml. At a high-level, it all worked surprisingly well given the lack of training data for a relatively low-resource language like OCaml (and especially OxCaml). Several other patterns emerged:
3.1.1 Specifications as source code
Feeding agents formal specs like RFCs or WHATWG standards produced surprisingly good results, especially when combined with external test suites. We built HTTP cookie, punycode and public-suffix libraries from the RFC text alone, a pure OCaml Yaml 1.2 parser that passes 20% more tests than the C libyaml bindings (and is 20% faster), and TOML 1.1 codecs reaching 100% of the toml-test suite. The key was having a comprehensive expect test suite which could be used to guide the code generation.
3.1.2 Error messages guide agents
Well-designed libraries with precise error messages (particularly jsont and its typed codecs) let agents self-correct in a loop. This proved useful when debugging against live APIs and when reverse-engineering protocols from multiple language SDKs. The bidirectional codec pattern from jsont generalised really well across other formats such as Yaml, TOML, and INI formats as well.
3.1.3 Source code context across languages often beat documentation
Providing agents with working implementations to study (cookbooks, previous codebases, and even reference implementations in other languages) consistently outperformed relying on docs alone. For a HTTP client, we aggregated best practices from 50 implementations across 10 languages to synthesise a unified specification for the OCaml version. For Eio-based libraries, cloning the source repo and pointing the agent at the README was effective enough to produce fairly robust code.
In general, agentic coding improves when all relevant code is locally available. We built monopam for assembling monorepos with unified sources, and unpac for branch-based package management where each dependency becomes a git branch rather than a submodule. This enabled agents to spawn parallel worktrees for independent porting tasks, a feature now natively supported by Claude Code.
3.1.4 Self-healing and recursive testing
When external test suites don't exist, we found that building tools which test themselves works surprisingly well: for example, a Zulip bot that exercises its own API, and a feed aggregator that patches its own parsing code when it encounters format quirks. The Postel "be liberal in what you accept" principle can be implemented through automatic code evolution.
OCaml's type system is a natural guardrail here, as it enforces strong typing provided a feedback loop that improved agentic coding quality compared to our earlier Python experiments. Agents can also handle verbose combinator-based boilerplate well, removing the need for PPX-based code generation in many cases. But the code produced is "unoriginal"; good for parsing and utility libraries, but not a substitute for creative library design. We treat all agent output as "slop by default" until human-reviewed, and some of us are switching our agents to use separate Git identities to keep it all separate.
Outside the Advent, we tried agentic bug hunting, experimented with Claude completing format specs and agentic OCaml, and used Claude for dune odoc rules as a first foray into upstreaming with an agent.
On the community side, there's been a real rollercoaster of conflicting incentives with AI slop encroaching on our more traditional repositories. We wrote up Vibecoding Etiquette guidelines to help navigate this. Much more thought, empathy and discussion will be needed this year to figure out what to do about the incoming AI code flood.
3.2 Evolutionary Redecentralisation
Our passion is also in operating self-hosted infrastructure, federated services, and distributed systems using MirageOS and modern OCaml.
We built Eilean, a self-hosted digital islands platform using MirageOS unikernels, and Eon, an effects-based OCaml DNS nameserver using Eio and MirageOS's pure DNS library. Our Bifrost preprint introduces a programming model using bigraphs for spatial networking, enabling policies scoped by physical boundaries and location-based device naming. Tangled code hosting and adding support to dune for it made mlgpx the first Tangled-hosted opam package; one small step to reducing our reliance on GitHub.
If none of the above is mad enough for you, we put all of the above into a mixing pot in our Ecology of/for the Internet paper, which argues for applying ecological resilience principles to the Internet. We prototype digital immune systems, mutualistic communication, and self-mutating code, using coding models and types and sandboxing to see what the world might look like if every host (out of the trillion or so connected to the Internet by 2030) might all be a bit different from each other. OxCaml may surprisingly be an important part of making this sort of evolutionary coding robust, since the extra type/kind information helps to constrain the runtime characteristics of AI-generated outputs.