My experimentation with Claude Cowork

Weekend tryst with Claude Cowork — a very positive experience and surprisingly productive.
This article shares my hands-on experiment using Claude Cowork to build an end-to-end automated workflow for daily wind measurement data: extracting emailed CSV files, consolidating the data, monitoring for anomalies, and presenting the results on a dashboard. The most interesting takeaway was how quickly a recurring manual process could be turned into reusable skills, Python scripts, and a scheduled workflow.
Got a lot accomplished in just a few hours — definitely worth experimenting with.

𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝘃𝗲 𝗦𝘂𝗺𝗺𝗮𝗿𝘆

This was a very positive experience, and it feels like a genuine paradigm shift for automating routine work — not just running a task once, but writing the scripts, chaining them into a workflow, and presenting the results, all from a plain-language description of what I wanted. In about four hours, starting from nothing, I had a working application: an email-driven data pipeline with monitoring and a dashboard. All of it was built in the desktop version of Claude Cowork — I described each step of the work, and Claude wrote the corresponding skill and the Python script behind it. Cowork then executes those tasks in its own cloud container, so there was no runtime environment to set up, configure, or maintain on my end — no Python install, no dependencies, no server to keep running.

It's also strikingly cheap next to the alternative of hiring someone to build the same thing. Running the pipeline daily costs on the order of a few dollars a year in token-equivalent terms — effectively a rounding error inside a subscription that's already flat-rate. Hiring a freelance developer to write and test the equivalent scripts would run roughly $900–$1,700 up front, plus several hundred to a couple thousand dollars a year in ongoing maintenance every time the data format or requirements change. Cowork collapsed both the build cost and the run cost to nearly nothing, and folded the maintenance cost into "describe the change and ask again."

𝗪𝗵𝗮𝘁 𝗖𝗼𝘄𝗼𝗿𝗸 𝗔𝘂𝘁𝗼𝗺𝗮𝘁𝗲𝘀

Claude Cowork extends Claude from a single-conversation assistant into something closer to a background operator for knowledge work: you describe an outcome, step away, and come back to finished work. Sessions run on Anthropic's cloud servers, so a task keeps running after the laptop is closed, and progress is reachable from desktop, web, or mobile.

I get wind measurement data from a LIDAR every day. Each day's file contains 144 rows — one row per 10-minute interval — with average wind speed, wind direction, and several other weather parameters for that interval. The data arrives by email as a zipped CSV, and the point of this experiment was to stop pulling it down and merging it by hand every day. The pipeline I built does four tasks that are repeated daily:

• Connect to an email inbox and find a message from a specific sender carrying a zip attachment with a CSV file.

• Download the attachment file; unzip the file and extract the CSV file.

• Append the contents of the CSV into a consolidated file that holds all data collected to date.

• Monitor the data by running predefined checks on the new data; log any anomalies.

𝗧𝘂𝗿𝗻𝗶𝗻𝗴 𝗮 𝗧𝗮𝘀𝗸 𝗶𝗻𝘁𝗼 𝗮 𝗦𝗸𝗶𝗹𝗹

A Cowork skill is a packaged set of instructions in plain English — a short file plus, optionally, bundled scripts and reference material. Skills use a three-level structure: a short name and description so Claude knows when to reach for the skill; the full instructions, which load only once the skill is triggered; and any bundled scripts or reference docs, which load only if the instructions actually call for them. This means having hundreds of skills installed costs almost nothing until one of them is actually used.

𝗛𝗼𝘄 𝗮 𝗦𝗸𝗶𝗹𝗹 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗚𝗲𝘁𝘀 𝗖𝗿𝗲𝗮𝘁𝗲𝗱

In practice, creating a skill was conversational, not a form to fill out. I described the task I wanted automated — in plain language, the way I'd describe it to a person — and asked Cowork to turn it into a skill. Claude then wrote the instructions and, where the task needed one, the Python script behind it. An example: unzip the email attachment, check that it's a CSV, count the lines, and compute the average of a column.

The one instruction that mattered most, and that I had to state explicitly rather than assume: tell Claude to save any script it writes and reuse it on future runs. Left unsaid, Claude will happily solve the task well the first time and then re-derive the code from scratch the next time it runs — which works, but burns tokens re-writing logic that already exists and didn't need to change. Asking for the script to be saved and referenced from the skill (rather than regenerated) is what makes a skill cheap to run repeatedly instead of just cheap to run once.

For the email-to-consolidated-file pipeline, I split the work into three separate skills rather than one monolithic one:

• Email extraction — connect to the inbox, find the qualifying message, download and unzip the attachment.

• Consolidation — read the extracted CSV, compare it against the consolidated file, and append only the new rows.

• Monitoring — scan the newly appended rows for known problem patterns and log anything worth flagging.

Keeping these separate meant each one could be tested and fixed independently, and it made the eventual scheduled workflow easier to reason about — a sequence of named steps rather than one large opaque prompt. I didn't hand-write any of these files, either: the instructions and the Python scripts they reference were themselves generated by Cowork. Iterating on the pipeline meant asking Claude to revise those files, not editing raw code by hand.

𝗦𝗰𝗿𝗶𝗽𝘁𝘀 𝗜𝗻𝘀𝘁𝗲𝗮𝗱 𝗼𝗳 𝗥𝗲-𝗥𝗲𝗮𝘀𝗼𝗻𝗶𝗻𝗴 𝗘𝘃𝗲𝗿𝘆 𝗧𝗶𝗺𝗲

The instinctive way to build this with an LLM is to hand it the task in plain language every single run: "check the inbox, find the zip, unzip it, read the CSV, append what's new." That works, but it means Claude re-derives the same logic on every single invocation. That's slower, it's less predictable, and it burns tokens on repeated reasoning that doesn't need to happen twice.

Instead, for each skill, I asked Claude to write a Python script that does the actual work, and treated the LLM's job as writing and maintaining that script rather than performing the task itself each time. Once the script existed, a run consisted of Claude executing it and reading back the output — a much smaller, more deterministic unit of work than reasoning through the whole task fresh. A script executes the same way every time, and only its output — not its code — has to enter the conversation. The LLM is still doing something valuable — writing the script, fixing it when the input format shifts, deciding what counts as an anomaly — but it's doing that work once, up front, instead of re-solving it on every run.

𝗦𝗰𝗵𝗲𝗱𝘂𝗹𝗶𝗻𝗴 𝘁𝗵𝗲 𝗪𝗵𝗼𝗹𝗲 𝗪𝗼𝗿𝗸𝗳𝗹𝗼𝘄

With three skills built, the next step was chaining them into a single sequence and running that sequence on a schedule instead of triggering it by hand. Cowork's scheduled tasks save a prompt and a cadence, then execute that prompt automatically — daily, weekly, hourly, or on a custom schedule — without needing the computer to be on, since the run happens remotely.

A few practical points from setting this up:

• Each scheduled run is independent — it starts fresh, so any state the workflow needs has to live in a file the scripts check, not in conversation memory.

• Ordering matters: consolidation depends on extraction having already unzipped the latest file, and monitoring depends on consolidation having already appended the new rows.

• Scheduled runs can be reviewed after the fact — each run's history stays available, which makes it easy to tell a run that quietly failed to find a new email from one that ran and found nothing new by design.

• A real friction point: unattended access to the laptop. This pipeline's data lives in a local, connected folder, not purely in the cloud, so a scheduled run that touches it needs access to the laptop the folder lives on. Claude will ask for that access — sometimes at the level of full device/folder permission — the same way it would if a person were sitting there approving each step. On a schedule, there's no one sitting there to click "approve."

𝗪𝗮𝘁𝗰𝗵𝗶𝗻𝗴 𝘁𝗵𝗲 𝗗𝗮𝘁𝗮: 𝗔 𝗗𝗮𝘀𝗵𝗯𝗼𝗮𝗿𝗱

Appending rows and logging findings is only useful if there's an easy way to see the state of the data without opening the raw file. I built a lightweight dashboard on top of the consolidated data and the monitoring log — a simple view showing the latest ingestion date, row counts over time, and any flagged issues surfaced at the top rather than buried in a log file. Its job is to answer three questions at a glance: did the pipeline run recently, did it add data, and did monitoring flag anything. Anything more elaborate is a nice-to-have layered on once the basic pipeline is trusted to run unattended.

𝗪𝗵𝗮𝘁 𝗧𝗵𝗶𝘀 𝗖𝗼𝘀𝘁𝘀 𝘁𝗼 𝗥𝘂𝗻

Cowork itself is billed as a flat monthly subscription, not metered per token. What follows is an estimate — translating the pipeline's actual token usage into what it would cost at Anthropic's published API rates — to give the automation a concrete dollar scale.

A full daily run chains three skills and several tool calls, but because the scripts do the actual data handling, the CSV's contents mostly never enter the model's context — only short summaries like "12 new rows appended" do. After trimming the skills down to lean, targeted instructions, a full daily run comes in under 10,000 tokens. At Claude Sonnet's published pricing ($2 per million input tokens, $10 per million output tokens), that's roughly $6–12 a year in token-equivalent value. Since this is mostly fixed-step execution rather than open-ended reasoning, it's also a reasonable candidate for Claude Haiku, priced at roughly half of Sonnet — bringing it down to roughly $3–6 a year.

Cowork itself ships inside the standard subscription plans — Claude Pro (roughly $200–240/year) or Max (over $1,200/year) — flat, regardless of how many scheduled tasks run under it. At under 10,000 tokens a day, this one pipeline is a rounding error against either plan.

𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆𝘀

The overall shape of this experiment — skill per step, script per skill, sequence scheduled end to end, dashboard on top to observe the result — is a reasonable template for turning any recurring, multi-step data task into something that runs itself. The most useful shift in mindset was treating the LLM as the author of the automation rather than the automation itself: writing a script once and running it repeatedly is more reliable and cheaper than asking an LLM to re-derive the same steps on every occurrence.