Are call_function calls serialized in the Ruby FFI runtime? I'm using BAML 0.90.2 (Ruby gem) to call EnrichSingleIssueGroq — a Groq Compound endpoint — 76 times in parallel using Ruby Thread.new. Each call takes ~20-30s (web search + inference). threads = issues.map do |issue| Thread.new(issue) do |iss| result = Baml.Client.EnrichSingleIssueGroq( issue: iss, zip_code: "94110", property_type: "Single Family", second_language: "" ) end end results = threads.map(&:value) All 76 threads are spawned instantly, but on the Groq dashboard I'm only seeing 10-15 API calls per minute arriving, not 76 at once. The Groq paid plan allows 200 RPM so it's not their rate limit. My suspicion is that @runtime.call_function in the Rust FFI layer holds a lock/mutex, so even though Ruby creates all threads immediately, the actual HTTP calls are serialized through the runtime. Questions: 1. Does the BAML Rust runtime serialize call_function calls, or can they run concurrently from multiple Ruby threads? 2. If serialized, is there a way to make truly parallel calls? e.g., using Baml.HttpRequest.build_request to render the prompt/schema, then making raw HTTP calls myself and parsing the response back through BAML? 3. Any plans for an async API in the Ruby client? Running on Linux, Ruby 3.3.7, baml gem 0.90.2.

hmm we are updating ruby to our latest version soon so that may fix the issue, but it may take until early april to do so

Ok. I'll just move this part to FastAPI. Thanks!

sweet