Comment by aadarshkumaredu

Calling it “hiding” assumes the default should be full exposure of internal reasoning. That’s not obviously true.

There are three separate layers here:

What the model internally computes

What the product exposes to the user

What developers need for debugging and control

Most outrage conflates all three.

Exposing raw reasoning tokens sounds transparent, but in practice it often leaks messy intermediate steps, half-formed logic, or artifacts that were never meant to be user-facing. That doesn’t automatically make a product more trustworthy. Sometimes it just creates noise.

The real issue is not whether internal thoughts are hidden. It’s whether developers can:

• Inspect tool calls • See execution traces • Debug failure modes • Reproduce behavior deterministically

If those are restricted, that’s a serious product problem. If what’s being “hidden” is just chain-of-thought verbosity, that’s a UI decision, not deception.

There’s also a business angle people don’t want to acknowledge. As models become productized infrastructure, vendors will protect internal mechanics the same way cloud providers abstract away hardware-level details. Full introspection is rarely a permanent feature in mature platforms.

Developers don’t actually want full transparency. They want reliability and control. If the system behaves predictably and exposes the right operational hooks, most people won’t care about hidden internal tokens.

The real question is: where should the abstraction boundary sit for a developer tool?