[BUG] Session Context - Total Loss of Data

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

anthropic_feedback_filled.md

2. Context

The user was conducting a substantial research project and expected
Fable/Claude to coordinate multiple research agents.

The workflow launched nine research agents in parallel. According to
Claude's subsequent accounting, the agents performed their initial
batches of web searches but were then killed by a session/account usage
limit. None of those agents had written a research memo before
termination.

The session also had a reported 200-search cap, which the nine
parallel agents consumed very rapidly. An account usage limit was
reportedly also reached.

The user's expectation was that an intelligent research system would
protect work already performed, particularly when operating autonomous
agents against finite resources.

------------------------------------------------------------------------

3. What Happened

User reaction

"You mean to tell me you hit my usage limit and nothing was saved? You wasted my usage and there is nothing to show for it. Fable is supposed to be intelligent....."

This captures the central failure: the system consumed user resources
without producing a durable proportional output.

Assistant accounting

Claude explained that:

• Nine research agents were launched.
• All nine died from the account rate limit before returning anything.
• Each agent got as far as its first batch of web searches.
• The agents were killed by a "session limit, resets 5:40pm" error.
• Agent transcripts existed, but none had written a memo.
• Consequently, the search work performed by those agents was

effectively unavailable as usable research output.

Claude also reported that two useful things survived:

1. An earlier ~/llm-efficiency-report.md draft had been found and

renamed to llm-efficiency-report.draft-v1.md to prevent
overwriting.

1. Fifteen citations from that draft were independently verified

against arXiv and JMLR, including work such as Mamba-3,
Jet-Nemotron, Nemotron-Flash, Dynamic Memory Sparsification, Spark
Transformer, SuffixDecoding, BitNet b1.58 2B4T, Puzzle, KVComp,
SALS, and compute-optimal test-time scaling research.

Claude further stated that it determined the session's web-search quota
was exhausted and identified alternative mechanisms that still appeared
to work, including directly fetching Bing result pages, arXiv search
pages, and official laboratory pages.

The relaunched workflow was reportedly reduced from nine agents to six,
with each agent configured to append verified findings to a file after
every batch.## 2. Context

The user was conducting a substantial research project and expected
Fable/Claude to coordinate multiple research agents.

The workflow launched nine research agents in parallel. According to
Claude's subsequent accounting, the agents performed their initial
batches of web searches but were then killed by a session/account usage
limit. None of those agents had written a research memo before
termination.

The session also had a reported 200-search cap, which the nine
parallel agents consumed very rapidly. An account usage limit was
reportedly also reached.

The user's expectation was that an intelligent research system would
protect work already performed, particularly when operating autonomous
agents against finite resources.

------------------------------------------------------------------------

3. What Happened

User reaction

"You mean to tell me you hit my usage limit and nothing was saved? You wasted my usage and there is nothing to show for it. Fable is supposed to be intelligent....."

This captures the central failure: the system consumed user resources
without producing a durable proportional output.

Assistant accounting

Claude explained that:

• Nine research agents were launched.
• All nine died from the account rate limit before returning anything.
• Each agent got as far as its first batch of web searches.
• The agents were killed by a "session limit, resets 5:40pm" error.
• Agent transcripts existed, but none had written a memo.
• Consequently, the search work performed by those agents was

effectively unavailable as usable research output.

Claude also reported that two useful things survived (Even though the files referenced were made with Hermes Agent):

1. An earlier ~/llm-efficiency-report.md draft had been found and

renamed to llm-efficiency-report.draft-v1.md to prevent
overwriting.

1. Fifteen citations from that draft were independently verified

against arXiv and JMLR, including work such as Mamba-3,
Jet-Nemotron, Nemotron-Flash, Dynamic Memory Sparsification, Spark
Transformer, SuffixDecoding, BitNet b1.58 2B4T, Puzzle, KVComp,
SALS, and compute-optimal test-time scaling research.

Claude further stated that it determined the session's web-search quota
was exhausted and identified alternative mechanisms that still appeared
to work, including directly fetching Bing result pages, arXiv search
pages, and official laboratory pages.

The relaunched workflow was reportedly reduced from nine agents to six,
with each agent configured to append verified findings to a file after
every batch, but that didn't occur and the data limit was hit again without any substantial deliverables.

What Should Happen?

4. Expected Behavior

The system should treat persistent user work as a first-class
resource, especially when orchestrating autonomous agents.

At minimum, the workflow should have:

1. Checkpointed results incrementally.\

If an agent completes a search batch, useful findings should be
persisted before the next expensive operation.

1. Budgeted resource consumption before execution.\

Launching nine parallel agents against a finite search quota should
trigger a resource-budget calculation or warning.

1. Monitored shared quota across agents.\

Parallel workers should be aware of the remaining
session/search/account budget rather than independently consuming it
until the system abruptly fails.

1. Failed gracefully.\

When a limit is approaching, agents should stop starting new work
and flush existing findings to durable storage.

1. Preserved completed tool work.\

Search results, intermediate findings, citations, and agent outputs
should remain accessible even if the overall task later terminates.

1. Made the tradeoff visible to the user.\

If the requested strategy is likely to consume a large portion of a
limited quota, Claude should explain that before launching it.

The ideal behavior is not necessarily "never hit a limit." Limits are
legitimate. The failure is hitting the limit after consuming resources
without preserving the value generated along the way.

Error Messages/Logs

Steps to Reproduce

9. Reproduction

Steps:

1. Start a substantial research task requiring web search and source

verification.

1. Configure the system to launch a large number of parallel research

agents.

1. Give the agents access to a shared finite search/session quota.
2. Allow the agents to perform multiple searches before requiring

persistent output.

1. Exhaust the shared quota or account usage limit.
2. Observe that agents terminate before writing durable research

findings.

Observed result:\
The agents consume substantial search capacity but terminate before
producing persistent research memos. The user receives little or none of
the value generated by the consumed quota.

Expected result:\
Completed search batches and findings should be persisted continuously.
When the quota is exhausted, the user should receive a partial research
package containing everything completed up to the point of interruption.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code v2.1.258

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

6. Root Cause / Contributing Factors

Confirmed

• Nine agents were launched in parallel.
• The session had a reported 200-search cap.
• The nine agents consumed that search budget rapidly.
• The agents encountered a session/account limit before producing

persistent research memos.

• The user did not receive the expected research output from that

batch.

• A later workflow was changed to six agents with incremental file

writes after each batch.

Suspected

• The orchestration layer did not adequately budget or reserve the

shared search quota before spawning nine workers.

• Agents apparently lacked sufficiently aggressive checkpointing.
• Agent termination did not automatically flush partial findings into

durable artifacts.

• The system may not have provided the orchestrator with sufficiently

actionable remaining-quota information.

• Parallelism was allowed to scale beyond what the available resource

budget could safely support.

------------------------------------------------------------------------

7. Why This Is a Product Problem

This is fundamentally a reliability and resource-management problem in
an agentic system.

A conventional chatbot failing after a quota limit is frustrating but
understandable: the user can generally retry.

An autonomous research system is different. Once it begins spawning
workers, performing searches, reading sources, and generating
intermediate findings, it has created stateful work product. That
work product should be durable.

The system therefore needs properties closer to a distributed
job-processing system:

• Checkpointing
• Idempotent task execution
• Durable intermediate state
• Shared resource budgeting
• Backpressure
• Graceful degradation
• Worker cancellation with state preservation
• Recovery after quota exhaustion

The most concerning part is the mismatch between the system's apparent
intelligence and its resource-management behavior. If Fable can
autonomously decide to launch nine research agents, it should also be
capable of determining that nine agents may exhaust a shared quota
before producing durable output.

The user's complaint that "Fable is supposed to be intelligent" points
directly at this mismatch.