[mergesort]

Hey @mattt, this is the companion to the EventSource PR, where I mentioned I'd be putting up a PR to add WASI support. As noted, my goal is to run Swift with full Foundation on Cloudflare Workers, and to be able to use AnyLanguageModel as an AI proxy in the process.

Since WASI doesn't have sockets, Foundation there doesn't have URLSession, which is the only thing preventing AnyLanguageModel from building on WASI. The good thing is that you already have support for HTTPTransport, so the changes here are very minor, and using it looks like this:

let model = AnthropicLanguageModel(apiKey: apiKey, model: "claude-sonnet-5-5", transport: FetchTransport())

(FetchTransport is a small transport in my project that calls the Worker's fetch.)

Everything is conditional on WASI, so nothing should change on any other platform.

Just a few thoughts/open questions:

• Right now if you forget a transport on WASI, you find out when the request throws rather than at compile time. If we made transport: required on WASI it would become a compile-time matter, but that would mean a WASI-specific init signature for every remote model, so I started with a smaller change. Happy to switch if you'd prefer, but I don't think it's worth a bigger change.
• Same as with the EventSource PR, I can add a WASI build job to CI if you'd like to have that here, there, or in both places.
• As mentioned in the EventSource PR, this PR is contingent on that landing and getting tagged. As a result I've opened this as a draft, but have been using the functionality on my own wasi-support branches here and here.

Thanks again, really appreciate the work you've done with AnyLanguageModel!

[mattt]

Thanks, @mergesort. A runtime error works for me. The message says exactly what to do, and a compile-time check would need a WASI-only variant of each remote model's init.

Yes, please add a WASI build job here, so that we find out when something breaks the build.

[mergesort]

Added the WASI CI target, thanks a lot!