The product is an AI diary application. The pain points are rigid configuration for a 'footprint' ink effect, requiring recompilation for modification, and a hardcoded 'max_tokens' parameter that causes API incompatibility with newer OpenAI GPT-5 models.

**1. The "footprint" ink experiment is on by default with no way to turn it off**

While writing, the diary stamps little decorative footprints beside the live ink (draw_faded_footstep / should_stamp_footstep in main.rs, called from the pen-draw paths ~L267 and ~L309; the comment at ~L172 calls it an experiment). On the page they read as stray blots/prints scattered around your handwriting, which looks odd if you don't know it's intentional.

Because it's compiled in (and inlined under lto = true), there's no way to disable it short of editing the source and rebuilding — no env var or setting. (unless I'm an idiot and missed a setting, which is compeltely possible)

Suggestion: gate it behind a flag — either default it off, or expose it in settings.schema.json / an env toggle like RIDDLE_FOOTPRINTS=0. Locally I just made should_stamp_footstep return false.

**2. Hardcoded max_tokens breaks OpenAI GPT‑5 models (e.g. gpt-5.4-mini)**

The HTTP oracle sends "max_tokens" in the chat-completions body (oracle.rs, ~L285). OpenAI's newer models (GPT‑5 series, o‑series) reject it:

`Unsupported parameter: 'max_tokens' is not supported with this model. Use 'max_completion_tokens' instead.`

So setting RIDDLE_OPENAI_MODEL=gpt-5.4-mini in oracle.env looks like a config-only change but actually 400s on every turn — ironic, since the code's own pi backend already uses gpt-5.4-mini.

Suggestion: send max_completion_tokens instead — it's accepted by gpt-4o* and the GPT‑5 models alike — or pic...