feat(aura-cli): display LLM reasoning output for coordinator and workers by justintime4tea · Pull Request #165 · mezmo/aura

justintime4tea · 2026-05-20T20:40:08Z

Shows "Reasoning: ..." output both at the top-level of the output, for the coordinator, and in-line with a given task for worker reasoning.

Here is an example of running against an orchestration enabled AURA config using Anthropic claude-sonnet-4-6 model.

Here is an example of running against a single-agent AURA config using Anthropic claude-sonnet-4-6 model.

Ref: GH-114

Document the new CLI reasoning output display feature from PR #165. Covers single-agent and orchestration modes, including visual examples of the streaming output format for coordinator and worker reasoning. Relates to: PR #165

promptless · 2026-05-20T20:44:23Z

Promptless prepared a documentation update related to this change.

Triggered by PR #165

Added a "Reasoning Output" section to the CLI documentation covering how LLM reasoning is displayed for both single-agent and orchestration modes, including /expand usage and server configuration requirements.

Review: Add CLI guide with one-shot output, logging, OTel, and reasoning display documentation

esatterwhite · 2026-05-28T15:41:44Z

In the commit message you can reference a github issue the same way # or GH- is legal

Ref: #114

Fixes: GH-114

both are legal / satisfy the commit linter. and still get all the deep linking benefits in all the places.

your commit message has Ref: 114 with out an github identifier - thats why I'm pointing it out.
I'd recoment using GH- just because # is also a comment char in commit messages

Shearerbeard

Mostly just questions and observations - one truncation concern we should look into pre merge. It runs absolutely amazing.

Shearerbeard · 2026-05-28T18:32:37Z

+            "parent_agent_id": "coordinator",
+            "session_id": "s1"
+        });
+        let events = vec![sse("aura.reasoning", &data.to_string()), sse("", "[DONE]")];


Thinking ahead - I wonder if we should canonicalize some of these strings as consts along with the SSE event structs

I think we might have some consts already for these event names if I recall... let me do some cleanup on this.

Shearerbeard · 2026-05-28T18:33:50Z

            |_, _| {},
            |_, _, _, _| {},
            |_, _| {},
+            |_, _, _| {},
            |_, _| {},
            |_, _| {},


Just curiosity here - would this be a candidate for a non matching _ block since it seems like were only acting on certain combos?

There's definitely room for improvement here with regards to currently requiring multiple no-op handlers to fill the function params. I could switch to using a trait that has default no-ops and then you just supply the handler you wish to override. I'll do some cleanup here.

Shearerbeard · 2026-05-28T18:34:19Z

+        content: String,
+        agent_id: String,
+        #[serde(default)]
+        fields: BTreeMap<String, serde_json::Value>,


Btreemap because your preserving order?

Yes, preserving order. With BTreeMap the /expand fields tree renders consistently and tests aren't subject to HashMap's randomized iteration. If we ever needed to preserve the original JSON field order we could switch to IndexMap, but stable sorted order is what I was going for here.

Shearerbeard · 2026-05-28T18:35:15Z

+                    // on_reasoning — no-op in oneshot mode (reasoning chunks
+                    // would interleave with the rendered response; the user
+                    // asked for the answer, not the thought process)
+                    |_content, _agent_id, _fields| {},
+                    // on_raw_event — no-op in oneshot mode


Similar question as above. Again just an observation from a shallow diff

Similar to other comment - I'll switch to using a trait that has default no-ops. I'll clean this up.

Shearerbeard · 2026-05-28T18:44:01Z

+                        let display = if text.chars().count() > 120 {
+                            let prefix: String = text.chars().take(117).collect();
+                            format!("{prefix}...")


Only concerning piece I'm seeing here - is this truncation utf8/emoji safe? We have some special handling with safe_truncation somewhere in aura that we use a lot but you approach this one a bit differently so I'm not sure if it applies.

It's UTF-8 safe because I'm using .chars().take()/.collect(), which only ever cuts on character boundaries, so it can't split a multi-byte sequence and panic.

safe_truncate solves the byte-budget case (it needs floor_char_boundary because it slices by byte index) but here I'm truncating to a visible-character count for a preview, so the character-based approach is the right unit and safe_truncate doesn't quite fit.

There is something though that neither handles and that is multi-scalar emoji (ZWJ/skin-tone/flags) being cut mid-grapheme. I didn't come up with this, Claude did when I asked it to further look into my truncation to see if it could find issues with it that I hadn't and to answer your question of "is it emoji safe". This, it turns out, is purely cosmetic - no crash, but multi-scalar emoji's aren't safe (either with this or safe_truncate). I could switch (this, not safe_truncate) to unicode-segmentation::graphemes though if we want to be sure that we not cut off mid-emoji :)

Shows "Reasoning: ..." output both at the top-level of the output, for the coordinator, and in-line with a given task for worker reasoning. Ref: GH-114

justintime4tea requested a review from a team May 20, 2026 20:40

justintime4tea force-pushed the justingross/114-no-aura-reasoning-output-in-cli branch 2 times, most recently from 6575e49 to 6c7b180 Compare May 20, 2026 20:43

justintime4tea force-pushed the justingross/114-no-aura-reasoning-output-in-cli branch from 6c7b180 to a3c7cf7 Compare May 20, 2026 21:02

Shearerbeard requested changes May 28, 2026

View reviewed changes

justintime4tea force-pushed the justingross/114-no-aura-reasoning-output-in-cli branch 2 times, most recently from 5b65663 to d35027d Compare May 29, 2026 21:11

feat(aura-cli): display LLM reasoning output for coordinator and workers

85377ba

Shows "Reasoning: ..." output both at the top-level of the output, for the coordinator, and in-line with a given task for worker reasoning. Ref: GH-114

justintime4tea force-pushed the justingross/114-no-aura-reasoning-output-in-cli branch from d35027d to 85377ba Compare May 29, 2026 22:07

Conversation

justintime4tea commented May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

promptless Bot commented May 20, 2026

Uh oh!

esatterwhite commented May 28, 2026

Uh oh!

Shearerbeard left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

justintime4tea May 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

justintime4tea commented May 20, 2026 •

edited

Loading

justintime4tea May 29, 2026 •

edited

Loading