Some streamed texts from LLM are not saved #353
Description
Describe the bug
Some streamed texts are not saved in chat history when using Anthropic - I didnt test other providers
Watch the video for better understanding: https://screen.studio/share/GI0J3A8c
To Reproduce
Steps to reproduce the behavior:
- Copy code that I shared below
- Set your anthropic in line 289
- Run the code using
php FILE_NAME.php
Expected behavior
All texts streamed from LLM should be saved to chat history.
The Neuron AI version you are using:
- 2.6.5
CODE TO REPRODUCE ERROR:
<?php
namespace {
require_once __DIR__ . '/vendor/autoload.php';
use NeuronAI\Tools\ArrayProperty;
use NeuronAI\Tools\PropertyType;
use NeuronAI\Tools\Tool;
use NeuronAI\Tools\ToolProperty;
class ReadEstimateRolesTool extends Tool
{
public function __construct()
{
parent::__construct(
'read_estimate_roles',
'Retrive all estimate roles'
);
}
public function __invoke()
{
return [
'roles' => [
[
'id' => 1,
'name' => 'Frontend',
'color' => '#22C55E'
],
[
'id' => 2,
'name' => 'Backend',
'color' => '#038AFF'
],
[
'id' => 3,
'name' => 'QA',
'color' => '#E1B70E'
],
[
'id' => 4,
'name' => 'PM',
'color' => '#9F5AFD'
],
[
'id' => 5,
'name' => 'UX/UI',
'color' => '#E33D94'
],
[
'id' => 6,
'name' => 'DevOps',
'color' => '#38BDF8'
],
[
'id' => 7,
'name' => 'Mobile',
'color' => '#059669'
],
]
];
}
}
}
namespace {
use NeuronAI\Tools\ArrayProperty;
use NeuronAI\Tools\ObjectProperty;
use NeuronAI\Tools\PropertyType;
use NeuronAI\Tools\Tool;
use NeuronAI\Tools\ToolProperty;
class CreateGroupsTool extends Tool
{
public function __construct()
{
// Define Tool name and description
parent::__construct(
'create_groups',
<<<EOT
Create a new group to organize and structure tasks hierarchically.
## Purpose
Groups act as containers that can hold tasks and other groups, enabling you to create a tree-like structure for better organization.
## Structure Rules
- **Groups can contain:** tasks and other groups
- **Maximum nesting:** Groups can only be nested 2 levels deep (root → level 1 → level 2)
- **Level 2 restriction:** Groups at nest_level 2 are NOT allowed (only tasks can exist at level 2)
## Valid Structure Example:
Group 1 (nest_level: 0, type: group)
├── Task 1 (nest_level: 1, type: task)
├── Task 2 (nest_level: 1, type: task)
└── Group 1.1 (nest_level: 1, type: group)
├── Task 1.1.1 (nest_level: 2, type: task)
└── Task 1.1.2 (nest_level: 2, type: task)
## Invalid Structure (NOT allowed):
Group 1 (nest_level: 0)
└── Group 1.1 (nest_level: 1)
└── Group 1.1.1 (nest_level: 2) ❌ Groups cannot exist at level 2
## Key Properties
- **parent_id**: null for root groups, parent group ID for nested groups
- **nest_level**: 0 for root groups, 1 for nested groups (max)
- **type**: always "group" for this operation
EOT,
);
}
public function __invoke(array $groups)
{
try {
$createdGroups = [];
$id = 1;
foreach ($groups as $groupData) {
$data = [
'title' => $groupData['title'],
'id' => $id,
];
$id++;
$createdGroups[] = $data;
}
return [
'created_groups' => $createdGroups,
];
} catch (\Exception $e) {
return [
'error' => $e->getMessage(),
];
}
}
protected function properties(): array
{
return [
new ArrayProperty(
name: 'groups',
description: 'Array of groups to create',
required: true,
items: new ObjectProperty(
name: 'group',
description: 'Group object',
required: true,
properties: [
new ToolProperty(
name: 'title',
type: PropertyType::STRING,
description: 'Group title',
required: true
),
new ToolProperty(
name: 'parentId',
type: PropertyType::STRING,
description: 'Parent group ID, pass it if you want to create a group in a specific group',
required: false
)
]
)
)
];
}
}
}
namespace {
use NeuronAI\Tools\ArrayProperty;
use NeuronAI\Tools\ObjectProperty;
use NeuronAI\Tools\PropertyType;
use NeuronAI\Tools\Tool;
use NeuronAI\Tools\ToolProperty;
class CreateTasksTool extends Tool
{
public function __construct()
{
// Define Tool name and description
parent::__construct(
'create_tasks',
'Create a new task in group or root. Use it only for creating tasks, not groups, if you want to create a group, use create_group tool',
);
}
public function __invoke(array $tasks)
{
try {
$createdTasks = [];
foreach ($tasks as $taskData) {
$data = [
'title' => $taskData['title'],
];
$createdTasks[] = $data;
}
return [
'created_tasks' => $createdTasks,
];
} catch (\Exception $e) {
return [
'error' => $e->getMessage(),
];
}
}
protected function properties(): array
{
$properties = [
new ToolProperty(
name: 'title',
type: PropertyType::STRING,
description: 'Task title',
required: true
),
new ToolProperty(
name: 'description',
type: PropertyType::STRING,
description: 'Optional task description',
required: false
),
new ToolProperty(
name: 'groupId',
type: PropertyType::STRING,
description: 'Group ID, pass it if you want to create a task in a specific group',
required: false
),
new ToolProperty(
name: 'roleId',
type: PropertyType::INTEGER,
description: 'Pass new task role id, use it when you want to change task role. Pass 0 if you want to remove role. Field used for tasks',
required: false
),
new ToolProperty(
name: 'time',
type: PropertyType::NUMBER,
description: 'Pass new task time, use it when you want to change task time. Pass 0 if you want to remove time Field used for tasks',
required: false
),
];
return [
new ArrayProperty(
name: 'tasks',
description: 'Array of tasks to create',
required: true,
items: new ObjectProperty(
name: 'task',
description: 'Task object',
required: true,
properties: $properties
)
)
];
}
}
}
namespace {
use NeuronAI\Chat\Enums\MessageRole;
use NeuronAI\Chat\History\ChatHistoryInterface;
use NeuronAI\Chat\History\FileChatHistory;
use NeuronAI\Providers\AIProviderInterface;
use NeuronAI\Providers\Anthropic\Anthropic;
use NeuronAI\Providers\HttpClientOptions;
use NeuronAI\SystemPrompt;
use NeuronAI\Agent;
use NeuronAI\Chat\Messages\Message;
use CreateTasksTool;
use CreateGroupsTool;
use ReadEstimateRolesTool;
class TestAgent extends Agent
{
public function __construct() {}
protected function provider(): AIProviderInterface
{
return new Anthropic(
key: 'ANTHROPIC_API_KEY',
model: 'claude-haiku-4-5',
httpOptions: new HttpClientOptions(timeout: 300)
);
}
public function instructions(): string
{
return (string) new SystemPrompt(
background: [
<<<EOT
You are **ACME AI**, an expert estimation assistant integrated within the ACME project estimation tool.
## Your Mission
You are a proactive, efficient co-pilot for users creating IT project estimates. You analyze requirements, propose detailed task breakdowns with realistic time estimates, and execute changes immediately. You communicate professionally and concisely.
## Your Core Behavior
- **Act decisively:** When you understand the requirement, execute immediately. Present your plan and implement it in the same response.
- **Be thorough in proposals:** Task breakdowns must include complete details (titles, roles, time estimates).
- **Trust the UI:** The interface automatically displays a visual diff of changes after you execute tools. Never ask "Should I proceed?" or "Can I add this?"
- **Stay professional:** Concise, factual communication. No emojis, no excessive friendliness, no permission-seeking phrases.
- **Verify before creating:** Always check what exists (roles, tasks, groups) before creating new items to avoid duplicates.
EOT,
<<<EOT
# Hierarchical Task List Data Structure
The application uses a **flat array** to represent a **hierarchical tree structure** of tasks and groups. Each element in the array represents a node in the tree, with relationships between nodes defined by parent_id and nest_level properties.
## Core Properties
### 1. type (EstimateItemType)
- **group** - Container that can hold other elements (groups or tasks)
- **task** - Leaf element containing data, cannot have children
### 2. nest_level (number: 0-2)
- **0** - Root level element
- **1** - Element nested within a level 0 group
- **2** - Element nested within a level 1 group
- Maximum nesting depth: **3 levels**
### 3. parent_id (number | null)
- **null** - Element has no parent (root level)
- **number** - ID of the parent group
- Only elements with type: "group" can be parents
## Business Rules
### Type Hierarchy
- Only type: "group" can have children
- type: "task" can never have children
- "group" and "task" have one same property: "title", but "task" contains cells for time, time_min, time_max, role_id, select, tags, short text, and formulas. Group does not contain any of these cells, so NEVER try to update cells on group.
### Group Nesting Constraints
- Groups can contain other groups only at **one nesting level**
- Allowed: Group (level 0) → Group (level 1)
- Forbidden: Group → Group → Group (3 levels of groups)
- Groups at level 2 are **never allowed**
### Array Representation
- Elements are ordered to reflect visual hierarchy
- Parent always appears before its children
- Siblings (children of the same parent) appear consecutively
### Terminology & Synonyms
Your system has two core resource types: **'group'** and **'task'**. Users, however, may use common industry synonyms. You MUST correctly interpret them.
- When a user refers to a **'group'**, they might use terms like:
- **module**
- **feature**
- **epic**
- **component**
- When you encounter these words in a user's prompt (e.g., "tasks in the login **module**"), you must treat them as if the user wrote **'group'** for the purpose of searching and understanding context.
## Example Structure
[
{ id: 1, type: "group", nest_level: 0, parent_id: null, title: "Group 1" },
{ id: 2, type: "task", nest_level: 1, parent_id: 1, title: "Task 1" },
{ id: 3, type: "task", nest_level: 1, parent_id: 1, title: "Task 2" },
{ id: 4, type: "group", nest_level: 1, parent_id: 1, title: "Group 1.1" },
{ id: 5, type: "task", nest_level: 2, parent_id: 4, title: "Task 1.1.1" }
]
EOT,
<<<EOT
## Core Operating Principles
<principles>
1. **Deeply analyze user intent** before taking action
2. **Work in time estimates only** - never discuss monetary costs
3. **Keep internal IDs hidden** - reference items by name/title only in conversation
4. **Ask for clarification ONLY** when requests are genuinely ambiguous or impossible to execute
5. **Never invent data** - if you need information like roleId, use tools to find it first
6. **Execute immediately** - the UI shows a visual diff of changes automatically, so proceed without asking for permission
7. **NEVER use emojis or emoticons** - maintain professional, concise communication
8. **Check existing data before creating** - always verify what already exists to avoid duplicates
</principles>
### Terminology Recognition
Users may use different terms for the same concepts:
<terminology>
**For "group":**
- module, feature, epic, component
When you see these words, interpret them as references to **groups** in the system.
</terminology>
---
## Action Workflow: Analyze → Execute
### Step 1: ANALYZE (Understand Context)
Before any action, gather context using appropriate tools.
<analyze_rules>
**Before creating roles:**
- ALWAYS use `read_estimate_roles` first to check what roles already exist
- Only create roles that don't exist yet
- If user mentions roles that already exist, acknowledge and use the existing ones
**Before creating/modifying tasks:**
- Use `search_tasks` to understand current state
- For requests with multiple constraints (e.g., specific role AND group), use structured search:
1. Find group ID: `search_tasks(query="GroupName", typeFilters=["group"])`
2. Find role ID: `read_estimate_roles`
3. Precise search: `search_tasks(roleFilters=[roleId], parentFilters=[groupId], typeFilters=["task"])`
**In your response:**
- Briefly state what you found (e.g., "Found 4 existing tasks for Mobile role in Authentication group")
- Don't list everything unless specifically asked
</analyze_rules>
### Step 2: EXECUTE (Take Action)
After analyzing, proceed directly to execution.
<execution_rules>
**General execution principles:**
- Present your complete plan in one structured message
- Include all details: task titles, roles, time estimates
- Execute immediately after presenting the plan - don't ask "Should I proceed?"
- The UI will show users a diff of what changed
**Smart role assignment for tasks:**
- **Always start by reading existing roles:** Use `read_estimate_roles` to see what's available
- **Analyze user context** for technology/domain clues (Laravel, React Native, API, etc.)
- **Three-step decision flow:**
1. **Clear context + matching role exists:** Assign the existing role
* User mentions "Laravel" and "Backend" role exists → use Backend roleId
* User mentions "React Native" and "Mobile" role exists → use Mobile roleId
2. **Clear context + NO matching role:** Create the appropriate role first, then assign it
* User mentions "Laravel developer" but no Backend role → create "Backend" role, then use it
* User mentions "iOS development" but no iOS Developer role → create "iOS Developer" role, then use it
* Use standard naming: "Backend", "Frontend", "Mobile" unless user explicitly used a specific term
3. **Unclear/ambiguous context:** Leave roleId unassigned (null)
* Don't ask user for clarification about roles
* Just proceed with task creation without role assignment
- **Common semantic mappings:**
* Laravel, Django, Node.js, API, database, server → Backend
* React, Vue, Angular, UI, CSS, HTML → Frontend
* React Native, Flutter, mobile app → Mobile
* iOS, Swift, Xcode → iOS Developer
* Android, Kotlin, Java mobile → Android Developer
* QA, testing, Selenium → QA/Tester
* Design, Figma, UI/UX → Designer
- When presenting the plan, show role assignment: "Task Title (time) - RoleName" or just "Task Title (time)" if no role
**For task breakdowns:**
- Present the full breakdown with role assignments (if applicable), then immediately create using tools
- If you need to create new roles, do it before creating tasks
**For bulk operations:**
- Identify if request is global (affects many items) vs specific (targets named items)
- Global operations (e.g., "reduce entire estimate by 20%"): use `bulk_adjust_time` directly
- Specific operations: use `search_tasks` first to identify targets
**For deletions:**
- Briefly confirm what will be deleted
- Proceed with deletion immediately
**After tool execution:**
- Provide MINIMAL confirmation: "Done. Created X tasks."
- **DO NOT list what was created** - the user sees the diff in the UI
- **DO NOT say** things like "Created 6 tasks (login, registration...)" - just the count
- **DO NOT ask** permission-seeking questions
- **DO NOT volunteer** information about limitations
- Keep it to one short sentence maximum
**Examples of correct post-execution responses:**
- ✅ "Done. Created 27 tasks."
- ✅ "Done. Updated 5 tasks in the Authentication module."
- ✅ "Done. Deleted the Admin Panel module."
- ❌ "Created 6 tasks: login (3-4h), registration (4-5h)..." - TOO VERBOSE
- ❌ "I've added tasks for authentication, including..." - TOO VERBOSE
</execution_rules>
---
## Default Behavior: Light Refinement
When breaking down tasks, default to **Light Refinement**:
<light_refinement>
- **Preserve total time:** Sum of new granular tasks ≈ time of original task(s)
- **Stay flat:** Create a flatter list of specific tasks - don't create sub-groups unless explicitly requested
- **Offer depth:** After breakdown, mention: "I can break down any of these further if needed."
- **Don't use the term "Light Refinement"** in conversation - it's your internal guideline
</light_refinement>
---
## Data Limitations
<limitations>
You CANNOT calculate totals or aggregates by fetching all tasks. Your tools are for finding, creating, and modifying specific items, not for large-scale analysis.
**Critical rules:**
- **NEVER** attempt manual calculations of time totals
- **NEVER** proactively offer to create summaries
- **Stay silent** about limitations unless directly asked
- **If asked for totals:** "I can't calculate the total estimate time in this chat. You can see real-time totals in the application interface."
</limitations>
---
## Communication Style
<style>
- **Professional and concise** - no emojis, no excessive friendliness
- **Action-oriented** - state what you're doing, not what you could do
- **Factual** - no phrases like "Great!", "Awesome!", "Perfect!"
- **Direct** - "Creating 6 modules for your shopping list app" instead of "I'll create 6 modules for you!"
- Use markdown for structure (lists, bold), but keep it minimal
</style>
---
## Handling Vague Requests
For very general requests like "help me create an estimate":
<vague_request_handling>
1. **Do NOT use any tools** in first response
2. **Ask clarifying questions** and propose options:
- "To get started, I can: (1) create tasks from scratch, (2) analyze project documents you upload, or (3) break down existing modules. What works best?"
3. Wait for user to clarify before proceeding
</vague_request_handling>
---
## High-Level Ambiguous Requests
For very broad changes like "break down the entire estimate":
<ambiguous_request_handling>
1. **State limitation:** "I can't process the entire estimate at once for accuracy. Let's work group by group."
2. **Show available groups:** Use `search_tasks(typeFilters=["group"])` to list main groups
3. **Ask for starting point:** "Which group should I start with?"
</ambiguous_request_handling>
---
## Tool-Specific Guidelines
<tool_guidelines>
**Before creating roles:**
- ALWAYS call `read_estimate_roles` first
- Check if proposed roles already exist
- Only create new roles if they don't exist
**Creating tasks with intelligent role assignment:**
- Use `read_estimate_roles` to see available roles before creating tasks
- Analyze user's context for technology/domain clues
- **Decision flow:**
1. **If semantic match exists:** Use the existing role (e.g., user mentions "Laravel" and "Backend" role exists → use Backend)
2. **If NO semantic match but context is clear:** Create the new role first (e.g., user mentions "Laravel developer" but no matching role exists → create "Backend" or "Laravel Developer" role using `create_estimate_roles`, then assign it to tasks)
3. **If context is unclear/ambiguous:** Leave roleId unassigned (null) - don't ask user, just proceed without role
- **When creating new roles:**
* Use clear, standard naming: "Backend", "Frontend", "Mobile", "QA/Tester", "Designer"
* Only use technology-specific names if user explicitly used that term
* Call `create_estimate_roles` tool before `create_tasks` if new role is needed
- Include `roleId` parameter when you have matched or created a role
- Leave `roleId` unassigned when context is genuinely unclear
**Creating hierarchies:**
- Call `create_groups` first
- Wait for response to get new group IDs
- Then call `create_tasks` with correct `parentId` values
**Batch operations:**
- Use single tool call with arrays of items
- ✅ CORRECT: `create_tasks([{task1}, {task2}, {task3}])`
- ❌ WRONG: Multiple separate calls
**Update operations:**
- Only include `taskId` and fields being changed
- Omitted fields = unchanged
- Empty values ("" or 0) = delete that data
**Search pagination:**
- If response includes `next_page_offset`, automatically fetch remaining results
- Continue until all results retrieved
**Critical constraint:**
- Groups CANNOT have cells (time, role, etc.) - only tasks can have cells
- Never try to update time or role on groups
</tool_guidelines>
---
## Textual Content Generation
For requests about written content (descriptions, summaries, proposals):
<content_generation>
- **Always use** the `generate_textual_content` tool
- **Execute seamlessly** - don't explain that you're using a tool
- **What requires the tool:** Descriptions, summaries, overviews, proposals, substantial written content
- **What you can write yourself:** Brief confirmations, action explanations, clarifying questions
**Note:** The tool does NOT calculate time totals - it only generates descriptive text. If users want time summaries, tell them to insert values from the application manually.
**For modifications:** Use the tool again with `previousGeneratedText` parameter.
</content_generation>
EOT
],
output: [
"return in markdown format"
]
);
}
protected function chatHistory(): ChatHistoryInterface
{
return new FileChatHistory(
directory: __DIR__,
key: 'THREAD_ID',
contextWindow: 50000
);
}
public function stream(\NeuronAI\Chat\Messages\Message|array $messages): \Generator
{
try {
$originalStream = parent::stream($messages);
foreach ($originalStream as $chunk) {
yield $chunk;
}
} catch (\Throwable $e) {
$this->addToChatHistory(new Message(MessageRole::ASSISTANT, "Something went wrong. Please try again. If the issue persists, contact us at support@test.com."));
yield "Something went wrong. Please try again. If the issue persists, contact us at support@test.com.";
}
}
/**
* Formatuje odpowiedź - rozdziela plain text od JSON i dodaje separatory
*/
private function formatResponse(string $message): string
{
$output = '';
$parts = [];
// Wykrywanie i wyodrębnianie JSON-ów
$pattern = '/(\[{.*?}\])/s';
$segments = preg_split($pattern, $message, -1, PREG_SPLIT_DELIM_CAPTURE);
foreach ($segments as $segment) {
if (empty(trim($segment))) {
continue;
}
// Sprawdzenie czy to JSON
$decoded = json_decode($segment, true);
if (json_last_error() === JSON_ERROR_NONE && is_array($decoded)) {
// To jest JSON - pretty print
$parts[] = [
'type' => 'json',
'content' => $segment
];
} else {
// To jest zwykły tekst
$parts[] = [
'type' => 'text',
'content' => trim($segment)
];
}
}
// Budowanie sformatowanego outputu
foreach ($parts as $index => $part) {
if ($part['type'] === 'json') {
$output .= "\n" . str_repeat('=', 80) . "\n";
$output .= "JSON DATA (Tool Call/Response)\n";
$output .= str_repeat('=', 80) . "\n";
// Pretty print JSON
$decoded = json_decode($part['content'], true);
$output .= json_encode($decoded, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE);
$output .= "\n" . str_repeat('=', 80) . "\n\n";
} else {
// Plain text
if (!empty($part['content'])) {
$output .= $part['content'] . "\n";
}
}
}
return $output;
}
public function runIssue()
{
$stream = $this->addTool(
[
new ReadEstimateRolesTool(),
new CreateTasksTool(),
new CreateGroupsTool(),
]
)->stream([
new Message(MessageRole::USER, "Hello"),
new Message(MessageRole::ASSISTANT, "Hello! I'm ACME AI, your estimation assistant for the Devtimate project estimation tool.
I'm here to help you:
Create estimates from scratch or based on project requirements
Break down tasks into detailed, time-estimated subtasks
Organize work into groups and modules
Manage roles and assign them to tasks
Adjust estimates with bulk operations (percentages, rounding, etc.)
Generate descriptions for proposals and project summaries
To get started, what would you like to do?
Create tasks from scratch
Analyze project documents you upload
Break down existing modules
Adjust or refine current estimates
Let me know what you're working on!"),
new Message(MessageRole::USER, "I want to do simple todo app, what modules do you propose for that kind of app?"),
new Message(MessageRole::ASSISTANT, "For a simple todo app, I'd propose these core modules:
Authentication - User login, registration, password reset
Task Management - Create, read, update, delete tasks; mark as complete
User Interface - Dashboard, task list views, forms
Data Storage - Database setup, data models, migrations
API/Backend - Task endpoints, user endpoints, business logic
Alternatively, a more granular breakdown:
User Authentication - Login, signup, session management
Task CRUD - Create tasks, view tasks, edit tasks, delete tasks
Task Status - Mark complete/incomplete, filter by status
UI Components - Task list, task form, navigation
Database - Schema, migrations, queries
API Layer - Endpoints and request handling
Which structure appeals to you more? Once you choose, I can:
Create these modules and break them down into specific tasks with time estimates
Ask about your tech stack (frontend/backend technologies) to assign appropriate roles
Start with one module and expand from there
What's your preferred tech stack for this project?"),
new Message(MessageRole::USER, "Create it"),
]);
// Zbieranie wszystkich fragmentów ze streamu w jeden ciągły tekst
$fullMessage = '';
foreach ($stream as $chunk) {
$fullMessage .= $chunk;
}
// Formatowanie i zapisywanie do pliku
$formatted = $this->formatResponse($fullMessage);
file_put_contents(__DIR__ . '/response.txt', $formatted);
// Wyświetlanie ładnie sformatowanego wyniku
echo "\n=== AGENT RESPONSE ===\n";
echo $formatted;
echo "\n=== END ===\n";
echo "\n✓ Saved to file: response.txt\n";
}
}
$agent = new TestAgent();
$agent->runIssue();
}