Is there a way to change the separator used for Enums? Right now it’s set to “or,” and it seems to be controlled on the Rust side. I will build a custom output format myself if needed, but it would be helpful to switch it to a comma. In my use case, we’re testing language performance and want to remove all English words.

yep!

"BAML renders it as property: string or null as we have observed some LLMs have trouble identifying what property: string | null means (and are better with plain english)." just curious if this is still a potential issue. And if yes can I define or_splitter at run time?

string | null

worked well, if you're steering the model away from english then

|

probably makes sense! I don't remember exactly what led us to that decision, but it was ad-hoc testing on a small sample set done before 4o had even come out

makes sense, I was thinking about , or using language native "or". Will use |

The

|

vs

or

thing only really showed up in more complex cases, and in those cases it's always super tricky to tell exactly what tokens will steer the model in one direction or another

that's an interesting point. I had to switch from having json fields in english to using translations. Aliases are so handy 😄 I would recon all punctuation is biased towards english

mm- can you describe your use case more? that’s not really a thing we support, since it usually means that your schema is too strict (you may want to optional-ify some fields) you can use the collector api to grab raw responses if you want

So we have some smaller models that still fail after retries because they miss certain fields. It isn’t entirely clear why that happens. In practice, we’re running a survey, and the model may: • skip a question, • omit the reasoning field, or • make a typo in a key (surprisingly very common—I’ll work around this with numeric keys and description). We would still like to capture that response so we can examine it and/or impute any missing data. Instead, the response fails outright (even though I can still view it in the Studio).

can you relax your schema and mark your currently required fields as optional?

We use validation errors for retries, but I doubt that will solve the issue of misnaming fields and alias juggling. We could probably use Pydantic to surface errors after BAML parsing, and then maybe use edit distance to correct typos. Thank you for explaining! I just wanted to check whether there was a solution for something like this.