https://www.boundaryml.com logo
Powered by
I've recently been trying to replace the
# general
v
I've recently been trying to replace the JS runtime of Codex's code mode with the BAML 1.0 runtime, and I've completed the document design so far.
a
wow, we have many many bugfixes on the way by the way! Landing this wednesday (or on the nightly channel)
let me know how it ends up working!
i added you to #1502444974229426246
v
I've realized the advantages of BAML's runtime over Codex JS's runtime. Many standard library capabilities actually need to be exposed to the agent, such as built-in file reading, but QuickJS does not support this. Code mode combined with BAML 1.0's visual workflow is also very good, as it reduces a lot of generative UI integration and gives users more transparency.
a
oh intresting, codex uses quickjs? they probably use quickjs to sandbox things no?
v
I found one concrete area where BAML seems to have an advantage over a QuickJS-based Code Mode runtime. QuickJS upstream does not support ECMA-402 / Intl, so APIs like Intl.DateTimeFormat cannot be relied on inside a QuickJS sandbox. In practice, this means agent-generated code that assumes Node/browser-style Intl support can fail or behave unexpectedly unless the host provides a custom polyfill or bridge. BAML’s canary runtime appears to have a much stronger time model built into the language/runtime layer. I found baml.time types such as Instant, PlainDate, PlainTime, PlainDateTime, TimeZoneOffset, and ZonedDateTime. The native runtime also appears to resolve system timezone and IANA timezone offsets through the host, using Rust-side timezone support. For Code Mode, this is important because agents often need to handle current time, timestamps, user timezone, scheduling, deadlines, and DST-sensitive conversions. Having typed, compiler-visible time APIs in BAML seems safer than relying on an embedded JavaScript runtime where Intl may not exist.
a
Ooo thats interesting, are you still in analysis phase?
v
I'm doing parallel validation — both the QuickJS code mode and the BAML native code mode have projects in development. The BAML part should be finished by Thursday or Friday. Once it's ready, I'll put up a repository."
a
niice
v
The core issue we are trying to avoid is a mental model mismatch between what the model thinks the runtime is and what the runtime actually supports. For example, in a QuickJS-based Code Mode, the model sees “JavaScript” and naturally assumes Node.js, browser APIs, TypeScript syntax, module imports, Intl, timers, SDKs, etc. But the actual runtime may only support a restricted JavaScript function body plus a small set of host-provided tools. That mismatch leads to hallucinated code.
A BAML-native Code Mode can significantly reduce this class of problems because the model is no longer writing JavaScript. It is writing BAML source, and the BAML compiler defines the language boundary. The advantages we see are: - The BAML compiler owns the syntax boundary, so the model is much less likely to mix in TypeScript, Node.js APIs, browser APIs, or module-system assumptions. - Available tools can be exposed as typed BAML stubs instead of relying on global JavaScript objects and prompt-only conventions. - Tools that are not enabled for the current session can simply be omitted from the generated BAML source context, so invalid calls fail at compile time or at a clear runtime boundary. - Schema mismatches can be caught earlier through BAML’s typed input/output contracts. - A 
main()
function or BAML function call gives the runtime a clearer execution boundary than a raw JavaScript script, making it easier to guarantee that the main execution body is fully awaited. So the larger design principle is: The model-visible programming surface should be generated from the actual runtime capabilities, and the same capability set should be used for prompting, compilation, execution, and audit. BAML does not automatically solve every Code Mode protocol problem, such as output-control semantics, terminal latches, background tasks, or host permission policy. But it gives us a much better foundation for keeping the model’s mental model aligned with the real runtime.
There's a bit of an issue here—Codex uses V8, not the QuickJS runtime
a
yeah i wouldve imagined they use something beefier than quickjs
v
a
Ooo would love to see a video of this
2 Views
PreviousNext
Powered by