Motivation

I come from the video game industry, where I believe Bazel could be a great fit — complex builds, cross-compilation, custom tooling for shaders and assets. But game dev is a Windows-first ecosystem; even cross-compiling for consoles is done from Windows. Improving that story is a big part of what motivated this project. There's also no standard build system in the industry: Unreal Engine uses Unreal Build Tool, Unity uses Bee, Godot uses SCons — and those are just the public ones; I'm aware of more I can't discuss here. Each reinvented the wheel because no ready solution existed. Today I believe Bazel's core is capable enough to satisfy the same needs — and with solid Windows support, the barrier to entry for new players would be lower: no need to develop your own build system.

The Bazel ecosystem also lacks a Windows toolchain that fully unlocks what makes Bazel great — and I believe that's a friction point for adoption. Bazel adoption isn't limited by how hard it is to use, but by how much configuration it takes to make it work with your ecosystem. Bzlmod addresses that by enabling ready-made solutions for mainstream languages and platforms — but Windows is missing one. A Bzlmod module where you can git clone && bazel build, up and running in seconds with no extra setup, lowers the bar for people evaluating Bazel on Windows and serves as a modern reference for those who need to customize it for their own ecosystem. At least, I wished it existed — so I set out to build one.

Design Goals

Going in, I had four goals:

• Native to the Windows ecosystem: MSVC ABI, fully compatible with the standard Windows developer experience.

• Idiomatic Bazel: modern rules-based architecture, platform constraints, build settings, and preferring Bazel's feature mechanism over raw flags.

• Full Bazel capabilities without compromise: hermetic through Bzlmod-based installation, reproducible builds (enabling a shared build cache), and remote execution support.

• Customizable: choose your compiler frontend (cl.exe, clang-cl.exe, or clang.exe) and linker (link.exe or lld-link.exe), customize flags per compilation mode (dbg, fastbuild, opt), with defaults matching Visual Studio settings.

Fetching a Proprietary Tool: MSVC

Targeting the MSVC ABI requires more than a compiler. Even when using Clang, you still need MSVC headers, libraries, and the Windows SDK — the equivalent of a sysroot for Windows. This dependency is mandatory.

MSVC is not open source. It is distributed by Microsoft under a license that prohibits repackaging and redistribution. Any Bzlmod module integrating MSVC must therefore acquire it through official Microsoft channels.

The license also explicitly states:

you may not: work around any technical limitations in the software;

Beyond the legal reading, there is a practical principle here: the Microsoft installer has always required the user to acknowledge the license before installation. A tool that automates this process should not silently bypass that step — users need to be aware of what they are agreeing to.

toolchains_msvc addresses this as follows:

• It fetches Visual Studio Build Tools from the official Microsoft distribution channel.

• It programmatically filters packages to ensure only those belonging to Visual Studio Build Tools can be installed.

• It refuses to proceed unless the user has explicitly agreed to the license. That agreement is made by setting a specific environment variable to the value documented in the module; if they have not, it prints the license URL and the variable name so they can do so deliberately.

The check only triggers when Bazel actually fetches MSVC. A project that lists toolchains_msvc as a dependency but does not run any build action using MSVC will never fetch it and will never be prompted to agree to the license.

This approach was inspired by portablemsvc and PortableBuildTools.

Toolchain Definition

Toolchains are defined via a toolchain set. A toolchain set produces a set of toolchains from the cross-product of: host platform, target platform, MSVC version, Windows SDK version, LLVM version, and compiler frontend.

Per toolchain set, you can configure default flags and features, as well as flags and features specific to each compilation mode (dbg, fastbuild, opt). You can define as many toolchain sets as needed.

All toolchains from all toolchain sets are declared in @msvc_toolchains//BUILD.bazel and registered with register_toolchains("@msvc_toolchains//:all"). Bazel selects the right toolchain using its standard selection mechanism based on platform constraints and config_setting constraints.

The active toolchain can be controlled with the following build settings:

• @msvc_toolchains//msvc=<version>

• @msvc_toolchains//winsdk=<version>

• @msvc_toolchains//llvm=<version>

• @msvc_toolchains//compiler=[msvc-cl|clang-cl|clang]

• @msvc_toolchains//toolchain_set=<toolchain_set_name>

All settings have defaults, so bazel build //my_target works with no extra configuration.

Fine-grained Customization

A toolchain that works out of the box is valuable only if it can also be customized without forking.

You can select any officially available version of MSVC and Windows SDK, and any version of LLVM that has a published SHA-256 digest.

You customize the toolchain by supplying default compile and link flag lists (per compiler and per compilation mode: dbg, fastbuild, opt). You can replace the built-in defaults entirely or layer additions on top of them.

A few behaviors are not “free-form flags” in those lists: they are implemented as standard Bazel features so cc_library, cc_binary, and feature toggles stay consistent and work out of the box — for example generate_debug_symbols, treat_warnings_as_errors, static_runtime, debug_runtime, and LTO (thinlto, fulllto). For those, you enable or disable the feature (per target or globally), rather than duplicating the same MSVC switches in toolchain defaults. Everything else you care to pass — typical examples include /Od, /O2, /W3, /Zc:__cplusplus — remains ordinary toolchain flag customization.

Reproducibility and Hermeticity

Reproducibility unlocks shared build caches — eliminating "works on my machine" and making every build verifiable. It requires two things: hermetic toolchain acquisition and deterministic compiler output.

For hermetic acquisition, toolchains_msvc fetches MSVC, Windows SDK, and optionally LLVM from their official distribution channels via Bzlmod repository rules. As an optional hardening step, you can record the SHA-256 of each package in a lock file; the repository rule will then fail if the downloaded package does not match.

For deterministic output, the toolchain passes flags to remove timestamps and absolute paths from build outputs.

Reproducibility is validated in GitHub Actions: a project and its copy are built independently, then the hashes of all source inputs and build outputs are compared to confirm they are identical.

For a concrete example, see toolchains_msvc_example: a small DirectX 12 GUI application built with toolchains_msvc. The repo includes sha256_manifest.py, which prints SHA-256 digests for build artifacts such as .obj, .lib, .pdb, and .exe. Run it after a local build and compare the output to the same step in GitHub Actions to confirm your artifacts match.

One caveat: link.exe cannot produce deterministic PDB files — its internal stream IDs are not stable across executions. lld-link.exe (from LLVM) does not have this limitation. By default, cl.exe-based toolchains use link.exe, while clang-cl.exe- and clang.exe-based toolchains use lld-link.exe. You can force cl.exe-based toolchains to use lld-link.exe via the cl_with_lld_version option in your toolchain set definition — at the cost of requiring LLVM to be fetched even when compiling with cl.exe.

600MB Saved with On-demand System Libraries

In a typical toolchain, system libraries are listed as dependencies of the cc_tool definition for the linker. On Windows, MSVC and Windows SDK libraries together weigh around 600 MB — compared to roughly 60 MB for executables and 120 MB for headers. For remote execution, this means 75% of what gets uploaded is system libraries, even though most targets only need two or three of them (e.g. kernel32.lib, user32.lib).

In toolchains_msvc, system libraries are not dependencies of cc_tool. They are regular cc_import rules. To use kernel32.lib, you declare a dependency on @msvc_toolchains//lib:kernel32.lib, which is an alias that resolves to the correct library for the Windows SDK version of the selected toolchain.

Conclusion

I built this project for myself first. It was my own evaluation of Bazel — I wanted to know if it was possible, and I am the first user of the result. I did this on my personal time, with the goal of building enough knowledge and confidence to invest in Bazel professionally. That goal is now confirmed: I will start transitioning my work projects to Bazel, which involves making it work with game consoles. That part will likely stay private.

The toolchain has not been used in production yet. Some design decisions are probably naive, and I expect bugs to surface once real projects start using it. The CI covers what it can, but automated tests cannot replace real-world usage. I will maintain and improve it as issues emerge — but that work depends on user feedback.

I am curious to see if this resonates. It could eventually become a BCR module. This is a modest contribution, and mostly a way to find out whether I am the only one with this need, or whether it can create traction and opportunity from there.

I am not attached to this repository as the final artifact. If the right outcome is a rename, a rearchitecture, or a different canonical module that learns from this one, I am fine with that. What I care about is that hermetic MSVC toolchains for Bazel exist and improve in the ecosystem — not that this particular project stays the one.

The natural next step would be rules_visualstudio. On Windows, the default debugger is Visual Studio, and a tight debugging workflow matters for adoption. Using Bazel's aspect mechanism, it should be possible to generate .sln and .vcxproj files that delegate the actual build to Bazel — a pattern already proven by Unreal Engine 5 with UnrealBuildTool. Not a big problem technically, but still some work.

This project started with a simple question: “Does Claude Code load CLAUDE.md as a system prompt or a user prompt?” Online answers hinted it was added as a user prompt, but I wanted proof—not assumptions.

With agent-based coding tools, context really matters. The system prompt, supplemental context, and the way the application wraps messages can significantly affect how the model behaves. Understanding how an app structures requests is one of the most reliable ways to diagnose odd behavior or improve prompt design.

The most practical way to inspect those requests is to sit between the app and the LLM provider. A proxy lets you log both requests and responses in a controlled way.

This article explains how I built such a proxy and how you can use it to observe the request structure used by Claude Code and Cursor.

Requirements for the Proxy

Claude Code allows configuring a custom endpoint via ANTHROPIC_BASE_URL and ANTHROPIC_API_KEY. The endpoint must implement the Anthropic Messages API.

Cursor works in a similar way: you can set an OpenAI API key and override the Base URL. However, it only supports the OpenAI Chat Completions API and does not allow localhost endpoints—requests must go through Cursor’s servers and point to a public URL.

So the proxy needs to meet three requirements:

• Support the Anthropic Messages API

• Support the OpenAI Chat Completions API

• Be hosted online (not local)

LiteLLM was an ideal fit. It supports multiple providers and exposes both API formats with minimal configuration.

For hosting, I chose Railway because it is easy to deploy for such simple stateless services. And their free tier is good enough for such a small experiment.

As for the backend LLM provider, I used OpenRouter because it supports many models through a single interface—though LiteLLM can work with practically any provider.

Building and Deploying the Proxy

If you only want to run the proxy, you can find the repository with deployment instructions here: https://github.com/Dragnalith/llm-proxy-logger.

The implementation consists of three files:

• config.yaml

• logger.py

• run_proxy.py

Configuration File: config.yaml

Before the proxy can forward requests, LiteLLM needs to know which incoming model names map to which real model providers. The config.yaml file defines that routing, the API credentials, and the callback used to log requests.

model_list:
  - model_name: claude-sonnet-4-5-20250929 # For Claude Code
    litellm_params:
      model: openrouter/anthropic/claude-sonnet-4.5
      api_key: os.environ/OPENAI_API_KEY
      base_url: https://openrouter.ai/api/v1
  - model_name: cls-s45 # For Cursor
    litellm_params:
      model: openrouter/anthropic/claude-sonnet-4.5
      api_key: os.environ/OPENAI_API_KEY
      base_url: https://openrouter.ai/api/v1

litellm_settings:
  success_callback: ["logger.log_request"]

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

The most important part of this configuration is the model_list. Each entry represents a model name that external tools (Claude CLI or Cursor) will reference. LiteLLM uses this name to determine which real LLM and provider URL to call. The value in model_name must exactly match what the client application will send — otherwise requests will fail silently.

Claude Code requires using the timestamped model identifier (e.g., claude-sonnet-4-5-20250929) rather than a generic alias like claude-sonnet-4-5. Cursor, meanwhile, needs a custom model entry that mirrors the name defined in its settings. During testing, model names containing "claude" caused Cursor to switch its protocol behavior, so a neutral name such as cld-s45 is safer.

Next, the success_callback points to the function in logger.py that receives metadata about each successful LLM request. This is what enables logging.

Finally, master_key defines authentication for the proxy. Without it, anyone with the URL could send requests and consume your upstream API quota. Even though this setup is experimental, enabling authentication prevents accidental exposure of valid credentials.

Logging Requests: logger.py

Once the proxy can forward requests, the next step is capturing what those requests look like. The logger.py file defines the callback function referenced in the configuration. LiteLLM invokes this function after each successful request, passing details such as the input messages, the model response, and timing metadata.

async def log_request(kwargs, response_obj, start_time, end_time):
    with open('llm-proxy-logger.log', 'a') as f:
            log_entry = {
                'timestamp': datetime.now().isoformat(),
                'messages': kwargs.get('input')
            }
            f.write(json.dumps(log_entry, indent=2) + ',\n')

The callback determines what gets written to the log. I chose a JSON format because it's readable and easy to parse later, but you can tailor the structure to your needs.

Running the Server: run_proxy.py

With configuration and logging in place, the final step is running the proxy. LiteLLM already provides a command-line interface to launch a proxy directly from a configuration file, and in many cases that would be sufficient. However, creating a custom runner offers additional flexibility—for example, exposing helper endpoints or controlling initialization behavior.

import uvicorn
import asyncio
from litellm.proxy.proxy_server import app, initialize

@app.get("/logs")
def serve_logs():
    return FileResponse('llm-proxy-logger.log')

async def startup_event():
    await initialize(config='config.yaml')

if __name__ == "__main__":
    asyncio.run(startup_event())
    uvicorn.run(app, host="0.0.0.0", port=4000, lifespan="on")

In this version, the custom runner adds a /logs endpoint that serves the log file via HTTP. This is particularly useful when deploying to platforms like Railway, where filesystem access is not exposed and log files cannot be retrieved through the UI.

The script initializes LiteLLM using the shared configuration file, then starts a lightweight FastAPI server powered by Uvicorn. Because the proxy is stateless, this setup scales easily and remains inexpensive to run.

Deploy to Railway

Once the proxy files are ready, you can deploy them to Railway. Create a Railway service, set the required environment variables (OPENAI_API_KEY, LITELLM_MASTER_KEY and PORT=4000), then deploy.

railway login
railway init
railway add
railway domain
railway up

The railway domain command assigns a public URL similar to https://<your-service-name>.up.railway.app which becomes your proxy endpoint.

Connecting Claude Code to the Proxy

Before using Claude Code, set the following environment variables:

ANTHROPIC_BASE_URL=https://<your-service-name>.up.railway.app
ANTHROPIC_API_KEY=<your-proxy-master-key>

After that, every Claude request will flow through your proxy.

Connecting Cursor to the Proxy

In the Models section of Cursor settings:

1. Enable OpenAI API Key and paste your proxy master key.

2. Enable Override OpenAI Base URL and set: https://<your-service-name>.up.railway.app.

3. Add a new custom model name matching one from your config.yaml. (Example: cld-s45)

Cursor will now send requests through the proxy when you select your custom model.

Insights from the Logged Requests

Once connected, you can inspect traffic by visiting: https://<your-service-name>.up.railway.app/logs

After logging requests from Claude Code and Cursor, I confirmed:

• CLAUDE.md is added to the first message of the conversation and not the system prompt.

• Cursor injects rules content in the first message using <rules></rules> tags.

• The user prompt appears in a second message wrapped in <user_query></user_query>.

• Before that prompt, in the second message, Cursor often includes <additional_data></additional_data> describing recent file state or edits.

• Contrary to what I thought, Cursor agent modes like Plan or Ask mode are implemented using a <system_reminder></system_reminder> block that modifies instructions after the user query. And not in the system.

• System prompts differ only slightly between modes—mostly in tool guidance or small behavioral nudges.