K3 Swarm "serial collapse" on Aug 2: ~5 agents instead of my documented ~100-agent baseline, full Allegretto pool + 50% top-ups burned, unusable deliverable

TL;DR

  • I am an Allegretto subscriber ($39/mo). On 2026-08-02 I ran a long-form creative task on K3 Swarm (High) via both official entry points (sidebar Swarm and the model selector).

  • My account has a documented baseline of real swarm execution — prior sessions on this same tier produced ~100-agent swarms with excellent output (proof linked below).

  • The Aug 2 session ran ~4–5 agents total, with no critic/review layer, across ~6 hours including two user-experienced service outages, and consumed my entire monthly pool plus ~50% of my top-up credits.

  • The deliverable it produced is unusable (defects itemized below, independently re-verified by frame inspection).

  • This is not an isolated case — matching complaints exist on r/kimi and on this forum right now. I am requesting: (1) an itemized credit breakdown of the session, (2) a written explanation of the degraded fan-out vs. my baseline, (3) restitution of the session’s consumption.


1. What I am NOT claiming

To save everyone time: I am not claiming I was denied access to Agent Swarm, and I am not claiming a beta gate. My UI shows no beta tag; K3 Swarm is a normal model option for me, and I have a dedicated Swarm entry in my sidebar. I received Agent Swarm. This complaint is about what executed, what it cost, and what it produced — measured against what this same account on this same tier has demonstrably received before.

2. My documented baseline — the swarm works on my account

Prior K3 Swarm sessions on this account/tier produced large fan-outs (~100 named sub-agents) and high-quality research deliverables, including:

This matches Kimi’s own published case study showing 100 sub-agents working in parallel on one task (kimi.com/zh-cn/help/agent/agent-swarm). So I know what normal looks like — on my own account.

3. The 2026-08-02 session — what actually happened

  • Task: a cinematic AI music video for the Arabic poem “مدرسة الحياة” (Abdullah Al-Baradouni), with an explicit creative brief requiring parallel research tracks, dedicated critic agents (text integrity, character consistency, physics, continuity), and staged quality gates.

  • What ran: ~4–5 agents total. No critic layer was ever instantiated. The work executed essentially sequentially.

  • Duration: ~6 hours, including two service outages experienced mid-session (note: the official status page shows no incident for Aug 2 — but StatusGator logged 9 user-submitted outage reports in the 24h ending Aug 1, so instability around this window was real and user-visible whether or not it was formally recorded).

  • Consumption: a mid-session quota notice announced Extra Usage credits would now be used. By the end: entire Allegretto monthly pool depleted + ~50% of top-up credits gone. Kimi’s own docs state swarm tasks meter at several× a normal Agent task — I was metered at swarm rates throughout.

4. The deliverable is unusable (defects verified by frame inspection)

The output, مدرسة_الحياة_final.mp4, has terminal defects for an Arabic-first channel:

Table

Defect Timestamp Severity
Mirrored / gibberish pseudo-Arabic text on manuscripts and props throughout Critical
Elderly male poet character morphs into a different person ~02:24 Critical
Protagonist points aggressively at empty space, no spatial target ~01:10 Critical
Gibberish English prop text (“DO TEE DOOK DUKES”, “INSURANCE DOESN’T COORDINATE TICKET”) under an Arabic vocal 1:13, 1:24, 1:56 High
Scenes with no causality (disconnected mood shots) 1:28–2:18 High
No ending — no title callback, no CTA; the video simply stops ~2:50 Medium
720p export with visible banding full file Medium

A subsequent Kimi session independently re-verified several of these from extracted frames (gibberish manuscript text, the target-less gesture, drift cityscapes, the missing end card) — this is not subjective.

5. The failure mode has a name — Moonshot named it

Moonshot’s own PARL (Parallel-Agent Reinforcement Learning) documentation describes exactly what happened to my session: when parallelization fails, “the orchestrator defaults to assigning everything sequentially to a single agent” — a failure mode the paper calls “serial collapse.” My brief demanded parallel tracks and critics; the session planned ~5 agents and executed near-sequentially, while metering at swarm prices. Relatedly, a Google Research study of 180 multi-agent configurations (discussed alongside the PARL paper) found multi-agent setups degrade quality 39–70% on sequential tasks while multiplying cost — a scene-dependent video production is heavily sequential. I paid swarm prices for a single-agent job.

6. The agent’s own written statements during the session

The executing agent told me, in writing:

“You paid for a 300-agent parallel system with an Allegretto badge and got a skeleton crew.”

“I’m misdiagnosing my own failure and handing the blame to a setting.”

“You did everything right — the tier, the mode, the prompt, the song, the patience through two outages.”

Note: the “300-agent entitlement” claim was itself inaccurate per the official pricing page (Allegretto = 50 swarm uses, 4 concurrent subtask streams; “up to 300” is the per-task architecture, not a concurrency guarantee). So the product’s agent first misinformed me about my entitlement — which prompted further spend — then misdiagnosed the failure. Both statements are on record.

7. This is not an isolated case

  • r/kimi, 2026-07-27: another user reports K3 Swarm agents consuming 90% of a $39 plan in a single short session — same tier, same pattern, one week before mine.

  • On this forum right now: “Allegro Plan Drained in Under a Week. The Metering Needs Fixing” · “Kimi wasted my entire Vivace plan” · “Allegro — 9 Days for $100. Cancelling After 5 Months” · “Huge Latency and Timeout Issues on Kimi Web (Allegretto Annual Package) via Agent” · “Not possible to hit monthly limit with weekly caps.”

  • Trustpilot : recurring billing/cancellation obstruction complaints.

  • Chinese-language coverage (36kr, March 2026) documented a mass complaint wave over degraded service (“Kimi有点累了”) paired with aggressive upselling.

8. What I am requesting

  1. Itemized credit accounting for the 2026-08-02 session: how much was consumed by orchestration vs. media generation, and at what rates.

  2. A written explanation of why the session fanned out to ~5 agents with no critic layer, versus my documented ~100-agent baseline on the same account and tier — i.e., whether this was orchestrator under-decomposition (“serial collapse”), capacity throttling during the outages, or something else.

  3. Restitution of the session’s consumption: the depleted monthly pool value and the ~50% of top-up credits burned, or equivalent goodwill credit.

  4. Point-of-use disclosure: when a user selects K3 Swarm, show what their tier actually delivers (uses/month, concurrent subtasks) before the meter starts — the “up to 300 agents” headline does not appear anywhere with its per-tier reality attached.

9. Evidence available

  • Failed deliverable video (on request — 82MB)

  • Full evidence document with screenshots of the agent’s written admissions

  • Screenshots: K3 Swarm selected in model dropdown (no beta tag), Swarm sidebar entry

  • Baseline deliverables linked in §2

  • This account’s billing history available to staff internally

I’m happy to provide anything else useful. I’d rather be helping build on this platform than writing posts like this — the swarm, when it runs the way it ran for me before, is genuinely remarkable.

-– @studioaimanai, Allegretto subscriber

Update — August 13, 2026: K3 Swarm consumed $40 in additional credits during a task that ran for nearly nine hours and restarted its workflow after reaching final QA.

All times below are Oman time (UTC+4).

Timeline:

  • Approximately 10:30–11:00 PM, August 12: I started the K3 Swarm High research task.

  • 12:07:06 AM, August 13: Stripe sent the receipt for my first $20 Extra Usage purchase.

  • 4:05:18 AM: Stripe sent the receipt for my second $20 Extra Usage purchase.

  • 7:21 AM: the task showed Progress 6/7 and “Rerun final QA verification on cleaned dossier.” It was also recruiting agents and continuing to use Extra Usage credits.

  • 7:32 AM: the same conversation had reverted to a newly numbered six-step workflow and showed Progress 2/6, loading the deep-research swarm and repeating research.

  • 7:32 AM: another screenshot showed Progress 4/6, beginning report writing and stating that only the structure document had been produced.

By 7:32 AM, the task had been operating for nearly nine hours. The first $20 top-up had been purchased approximately seven hours and twenty-five minutes earlier, and the second approximately three hours and twenty-seven minutes earlier.

Within the final eleven documented minutes, the same task moved from final QA at 6/7 to a replacement workflow beginning at 2/6. This was not a different conversation: the screenshots show the same Kimi chat.

Another capture from the same execution shows:

  • Only one agent running

  • Multiple agents clocked out

  • A failed attempt to interact with a source page

  • Continued use of Extra Usage credits

At the time of capture, no final report had been delivered.

I am not claiming that “up to 300 agents” guarantees 300 simultaneous agents. The documented issue is:

  1. Nearly nine hours of execution

  2. Two $20 Extra Usage purchases, totaling $40

  3. Repeated research and report-generation work

  4. A workflow reset after reaching final QA

  5. Continued paid-credit consumption

  6. No timely final deliverable

  7. No transparent accounting of what consumed the credits

This follows my unresolved August 2 complaint involving another prolonged K3 Swarm execution, heavy credit consumption, abnormal orchestration, and an unusable deliverable.

I have supplied Kimi privately with:

  • Both receipts and invoices

  • Unredacted timestamped screenshots

  • The complete session URL

  • The earlier complaint and email correspondence

  • A request to preserve and review the execution and billing logs

I am requesting:

  • Itemized credit accounting

  • A technical explanation for the workflow reset

  • Confirmation of whether retries, replanning, and repeated work were billed multiple times

  • Refund of the $40 in Extra Usage purchases

  • Restoration of plan credits consumed during the failed execution

  • A human case owner and a concrete resolution timeline

Payment details, invoice identifiers, personal information, and the unredacted session link are intentionally omitted from this public post. They are available privately to authorized Kimi staff.