CLAUDE LABJP
MODEL — Claude Fable 5.1 and Claude Mythos 5.1 landed on September 1. They are the same underlying model; only the strength of the safeguards differsPRICING — Per-token rates hold at $10/$50 per MTok. What changed is cache reads, cut 75% to $0.25 per MTokCOST — How much that saves depends on your workload: roughly 25% for typical use, up to about 45% for context-heavy agentic work. Worth measuring your own split before quoting a numberBENCH — Terminal-Bench-Science 0.1 climbs from 24.7% on Fable 5 to 52.6%. Anthropic also states a standard error of 3.5-4.5 points, which is worth remembering before reading small gaps as realSAFEGUARDS — Sharper cyber safeguards cut interventions in Claude Code sessions by roughly 60% on average. Finding vulnerabilities is now allowed; developing exploits still is notAPI — New API accounts created from today can no longer edit prior context while preserving Claude's thinking transcript. It is an anti-distillation measure, and existing accounts are unaffected for nowMODEL — Claude Fable 5.1 and Claude Mythos 5.1 landed on September 1. They are the same underlying model; only the strength of the safeguards differsPRICING — Per-token rates hold at $10/$50 per MTok. What changed is cache reads, cut 75% to $0.25 per MTokCOST — How much that saves depends on your workload: roughly 25% for typical use, up to about 45% for context-heavy agentic work. Worth measuring your own split before quoting a numberBENCH — Terminal-Bench-Science 0.1 climbs from 24.7% on Fable 5 to 52.6%. Anthropic also states a standard error of 3.5-4.5 points, which is worth remembering before reading small gaps as realSAFEGUARDS — Sharper cyber safeguards cut interventions in Claude Code sessions by roughly 60% on average. Finding vulnerabilities is now allowed; developing exploits still is notAPI — New API accounts created from today can no longer edit prior context while preserving Claude's thinking transcript. It is an anti-distillation measure, and existing accounts are unaffected for now
Articles/Cowork
Cowork/2026-05-03Intermediate

Honest 6-Month Review of Claude Cowork — What Actually Worked for an Indie Developer

A candid 6-month review of Claude Cowork from an indie developer's perspective. Covers scheduled tasks, skills, and the memory system — what exceeded expectations, what was genuinely painful, and the hard-won lessons that changed how I use AI automation.

Cowork36Scheduled Tasks10Skills7ReviewIndie Dev22Automation44

Let me be upfront: I'm a dedicated Claude Cowork user. But precisely because I rely on it daily, I want to be honest about the parts that were genuinely frustrating — not just the highlights.

Over the past six months, I've used Cowork to run four AI tech blog sites almost entirely on autopilot. Article generation, SEO data collection, update logging — all of it. Here's what I actually learned.

What Met Expectations — Scheduled Task Reliability

Before I started, my biggest worry was simple: will it actually keep running every day?

The answer surprised me. Scheduled task reliability has been better than I expected. I run tasks every four hours across four sites, and missed executions are essentially zero. The 3 AM posts that I'd definitely forget to do manually? Cowork just handles them without complaint.

What's particularly impressive is how it handles errors. When a git rebase fails, the next scheduled run often self-recovers. That "try to recover, not just fail" design has saved me more times than I can count. If you've ever burned out maintaining hand-written cron scripts, you'll understand how meaningful this is.

What Exceeded Expectations — The Memory System as a Living Knowledge Base

Honestly, I underestimated the memory feature at first. I assumed it was just "remembering the last conversation."

Six months later, my Cowork memory holds over 60 entries. Rules like "never use language prefixes in internal MDX links," "when adding a category, update 6–8 hardcoded label files," and dozens of other lessons learned from real failures. Every new session starts with that accumulated knowledge already loaded.

This isn't a notepad — it's a shared knowledge base that grows with you. I don't avoid repeating mistakes because I have a good memory. I avoid them because Cowork remembers for me.

What Was Genuinely Hard — Skill Design Is Harder Than It Looks

The pitch of "write a SKILL.md and your AI runs autonomously" is compelling. It's what drew me in. The reality is more nuanced.

Making a skill that actually runs reliably takes significant iteration. For example: it took me several weeks to realize that using Read/Write/Edit tools inside a scheduled task triggers a permission dialog and halts execution. Finding the workaround — using bash's cat and sed instead — cost me a lot of failed runs.

This isn't a bug in Cowork, exactly. It's that the design patterns for "safe autonomous AI execution" are still being figured out as an industry.

One lesson I can share directly: explicitly state in every skill file that no user confirmation is needed and that AskUserQuestion is prohibited. That single change dramatically improved my task completion rate.

What Was Genuinely Hard — VM Disk Management

This gets technical, but it matters. The Linux VM Cowork uses has limited disk space.

Early on, I had skills that ran npm install on each execution. This caused the VM to stop completely — node_modules alone takes around 500MB. The fix was realizing that npm install is entirely unnecessary for posting articles. The workflow is just: git clone → write MDX → git push. Cloudflare's CI handles the rest during its build step.

Learning this lesson cost me several broken VM states. If you're running Cowork with heavy scheduled tasks, understanding VM resource constraints isn't optional — it's essential design knowledge.

An Unexpected Win — Pushing via GitHub REST API

After repeated pain with git operations, I made a somewhat radical decision: stop using git commands entirely for pushes.

The GitHub REST API approach — blobs → trees → commits → refs — pushes directly to the main branch without touching index.lock or running into permission issues. It eliminated an entire class of problems I'd been fighting for weeks. This isn't really a Cowork-specific insight, but it's become my go-to pattern for any AI agent that needs to interact with a git repository.

How My View of Cowork Has Changed After Six Months

When I started, I thought of Cowork as a magic tool. "Write a SKILL.md and automate anything."

Now I think of it as something you grow. Skills, memory entries, failure logs — built up patiently over time, they become something genuinely useful: an AI team that knows your specific project, your specific constraints, and your specific mistakes.

My Cowork setup today took six months to become what it is. Yours will too, and that's okay.

Where to Start

If you're new to Cowork, my suggestion: create exactly one scheduled task and let it run for two weeks. Don't try to build a complete system from day one. Stabilize one small automation first.

Six months from now, your memory will hold a record of your own failures and discoveries. That's the real asset — not the tool itself, but what you build with it over time.

Share

Thank You for Reading

Claude Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $15 for lifetime access
View Membership →

If you found this article helpful, a small tip ($1.50) would mean a lot to us. Your support helps keep this site ad-free and covers server and hosting costs.

Related Articles

Cowork2026-07-02
How Many Tasks Fire in the Same Minute — Flattening Cowork Scheduled-Task Collisions from Cron
When Cowork scheduled tasks bunch up at the same time and fight over shared resources, you can expand every cron expression into fire times, count collisions and true concurrency, and shave the peak with a greedy offset that never moves your premium slots. With working code and measured before/after numbers.
Cowork2026-07-01
Let the Downstream Task Verify the Upstream Actually Ran Today: A Completion Ledger and Dependency Barrier for Unattended Schedulers
Unattended schedulers have no notion of dependencies, so when a morning data-refresh task fails silently, the noon generation task keeps running on yesterday's leftovers. This is a design for recording upstream completion atomically and having downstream assert its preconditions before running, with working TypeScript and lessons from my own operations.
Cowork2026-06-29
Failing Loud on Stale Inputs: A Freshness Contract for Unattended Pipelines
How to stop a scheduled, unattended pipeline from silently shipping degraded work when its upstream data is empty or stale. We implement a freshness contract in bash that asserts recency, non-emptiness, and provenance, plus two real pitfalls I hit running Cowork scheduled tasks.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →