WordPress has released an important update to address a serious security issue. The release of WordPress 7.1.2 fixes a critical unauthenticated path traversal vulnerability which is tracked as s CVE-2026-87902 and has a CVSS v4.0 score of 9.2 (Critical). Left unpatched, the flaw could allow an attacker to access a PHP file which could ultimately lead to complete site compromise. The description of the vulnerability is as follows: “An unauthenticated attacker can make get_page_template() page-template resolution include a chosen readable local .php file outside the active theme directories. If relevant pre-conditions for both the server environment and the active theme… [Continue Reading]

Ask most engineers what MCP is and you’ll get the same answer: a way to plug tools into an LLM. Fair enough, as far as it goes. But that description treats MCP like plumbing, and after months building MCP-based integrations for large enterprise platforms, I don’t think plumbing is the right metaphor. Plumbing moves water through pipes you already designed. MCP changes who’s holding the wrench. Once you’ve felt that shift in a real production system, the “just another API standard” framing stops making sense.

This piece is the long version of that argument. It walks through what MCP’s primitives actually are and why they’re the right primitives, where the standard genuinely collapses integration work that used to be duplicated per framework, where the abstraction leaks in ways that only show up once you’re past the demo, and what the protocol’s own 2026 evolution tells you about where the real pain has been. Nearly everything worth knowing about building on MCP falls out of understanding these pieces and how they interact.

What MCP actually standardizes

Strip away the framing and MCP is a JSON-RPC-based protocol that lets a client (the thing driving an LLM) talk to a server that exposes capabilities, over a small, fixed set of primitives:

Tools are callable functions. Each one has a name, a description, and a JSON Schema describing its inputs. This is the primitive most people mean when they say “MCP,” and it’s the one doing the heavy lifting in most production deployments: “look up an order,” “run a query,” “create a ticket,” etc.

Resources are readable context, addressed by URI, that a client can pull in without the model having to call a function to get it: a file, a record, or a document, for instance. Think of this as the read side of the interface, separate from the “do something” side that tools represent.

Prompts are reusable templates a server offers to the client, so common workflows don’t have to be respecified from scratch every time.

On top of those three, the spec defines capabilities that flow the other direction, from server back to client: Sampling lets a server ask the client’s model to generate text on its behalf; elicitation, added in the 2025-06-18 revision, lets a server pause and ask the human for more input mid-task; and roots let a server learn which directories or URIs it’s actually allowed to touch.

None of these primitives are individually novel. What’s novel is that they’re the same five primitives regardless of which model, which framework, or which vendor is on the client side. That’s the entire value proposition in one sentence, and it’s also the source of everything that goes right and everything that goes wrong when you build on top of it.

Where the old model breaks down

Before MCP, wiring an LLM into an enterprise system meant writing tool-calling code for that specific model, that specific framework, that specific integration. Every agent framework had its own function-calling convention: its own way of describing a schema, its own way of parsing a model’s intent to call something, and its own error-handling contract. Every system you wanted to expose needed its own adapter written to whichever dialect that framework spoke. Add a second framework to your stack and you don’t get twice the work. You get a second, incompatible copy of the same logic, maintained by whoever drew the short straw.

MCP replaces that with one contract, written once, usable by any compliant client regardless of which model sits behind it. That’s the part every MCP explainer gets right, and it’s a real, measurable win. I’ve watched it collapse from a maintenance burden that used to scale with the number of frameworks a team happened to be supporting that quarter down to something that scales with the number of systems, full stop.

But the more consequential change is where the integration decision gets made. A traditional API integration is an agreement two systems make in advance. You negotiate a contract: endpoints, payloads, auth, versioning, and both sides build to it, because a project plan said this integration should exist. The plan predates the code.

An MCP server doesn’t get that luxury. It has no idea which agent will call it, in what sequence, alongside which other servers, in service of what goal a human typed into a chat box 30 seconds ago. The plan doesn’t exist as a concrete thing until the agent composes one, at runtime, out of whatever tools happen to be available to it. That’s not a stylistic difference from the old model. It’s a different category of integration problem, because the party doing the composing isn’t your code anymore. It’s a model, reasoning over natural-language descriptions you wrote weeks or months earlier, with no idea what context it would eventually be reasoning inside of.

The description is the interface now

A tool’s JSON Schema tells the agent what parameters it takes and what shape they need to be. That part is mechanical, and MCP handles it well. The tool’s name and description tell the agent when to use it at all, and whether to prefer it over some other tool that does something adjacent. Those are two different jobs, and only one of them is solved by a well-formed schema.

Picture two versions of the same tool description. The first is technically correct and nothing more:

{
  "name": "get_status",
  "description": "Returns the current status of a record given its ID."
}

An agent reading that has no idea when this is the right tool versus three other tools that also return some kind of status, no idea what “record” means in this system, and no idea whether IDs are case-sensitive, numeric, or prefixed. The second version spells out the domain the tool operates in, gives the ID format explicitly, states what the returned status values mean, and flags the one adjacent tool this one is commonly confused with and why they’re different:

{
  "name": "get_status",
  "description": "Returns the current fulfillment status for an order record. 
IDs are numeric order numbers (e.g. 48213), not SKUs or customer IDs. Status 
values are one of: pending, processing, shipped, delivered, cancelled. Use this 
instead of get_shipment_status, which returns carrier tracking events rather 
than the order's internal state."
}

That’s a longer description, and it will feel like overexplaining to the engineer writing it, because the engineer already knows all of this. The agent doesn’t. It’s encountering the tool for the first time, with a handful of tokens to decide whether it’s the right call, and no colleague to ask.

I’ve watched teams ship a technically correct MCP server that agents used badly, or avoided entirely in favor of a worse but better-described alternative, purely because of this gap. The failure mode isn’t a stack trace. It’s an agent confidently calling the wrong tool, or the right tool with an assumption baked in that happened to be wrong for this case, and nobody notices until the output looks slightly off downstream. Writing tool descriptions well is closer to technical writing and product design than it is to backend engineering, and it’s not a skill most integration teams (mine included, early on) walked in the door with.

Composition is emergent, and that cuts both ways

The entire appeal of MCP is that an agent can combine tools from servers that never agreed to work together, in combinations their respective authors never planned for. That’s also the risk, and it’s structural, not a bug you fix with better testing.

In a traditional integration, the sequencing logic (call A, then check its result, then decide whether to call B or C) lives in a script that a human wrote and a reviewer read. You can unit test it. In an MCP-based agent, that same sequencing logic lives in the model’s runtime reasoning, generated fresh for each task based on the goal it was given and whatever tools happen to be available in that session. You can’t unit test a decision that doesn’t exist until the moment it’s made.

A tool that behaves correctly in isolation, with the exact inputs its author tested against, can still produce a bad outcome the first time an agent calls it third instead of first in a chain, or passes it a value that came from a different server’s output rather than a human’s direct input. This is qualitatively different from a normal integration bug, because it doesn’t show up in code review, and it won’t show up in testing unless your test suite happens to exercise that specific, unplanned chain of calls. It shows up in production, once, when a particular combination finally occurs. That’s exactly the kind of failure mode that’s cheap to dismiss as an edge case until it happens to the wrong customer.

The protocol is catching up to its own success, in specific and telling ways

To be fair to MCP, it isn’t standing still, and the shape of its evolution tells you a lot about where the real production pain has been. The July 28, 2026 specification is the largest revision since the protocol’s November 2024 launch, and every major change in it traces back to something that broke, or nearly broke, at scale.

The protocol core is now stateless. The original design tracked sessions with an MCP-Session-Id header, workable for a single server instance but painful the moment you’re running behind a normal horizontally scaled fleet and discover that “any instance can answer any request” and “sticky session state” don’t coexist. Removing protocol-level sessions means the same request can be served by any instance behind ordinary load-balancing infrastructure, which sounds unglamorous right up until you’re the one who has to explain in an incident review why a routine deploy dropped a chunk of in-flight sessions.

Tasks formalize long-running work. A lot of real enterprise work (document processing, multistep approvals, anything involving a human in the loop) doesn’t complete inside a single request/response cycle. Before this extension existed, teams hand-rolled this with polling loops and webhook callbacks, each implementation slightly different, each one a source of its own edge cases. Tasks turn that into a first-class protocol concept.

MCP Apps let a server return interactive UI, not just structured data. That matters the moment a “tool” is something a human needs to actually look at and approve before it fires, which in any environment with real consequences attached is often.

Authorization was hardened to align with OAuth 2.1 and OpenID Connect. This one isn’t novel so much as overdue, and the gap it closes was a real one; see the governance section below.

A formal deprecation policy now governs the legacy HTTP+SSE transport, with a 12-month offramp. That’s the kind of unglamorous governance maturity a protocol only earns after it’s been run in production long enough for someone to need it.

None of this is exciting reading. All of it is the sound of a two-year-old protocol absorbing genuine operational scar tissue, which is a far better signal about its trajectory than raw adoption numbers. And the adoption numbers are themselves striking: The official registry tracks close to 10,000 distinct servers, Tier 1 SDK downloads run into the tens of millions monthly, and both the TypeScript and Python SDKs have individually crossed a billion total downloads. Competitors of the protocol’s original author adopted it within months. That combination, real scale plus a spec that keeps changing in response to real production failure modes, is a much stronger signal of durability than either fact alone.

Governance hasn’t caught up

Here’s what I’d want any team to weigh before connecting MCP to anything that matters. Independent security research through 2026 paints a specific, and specifically uncomfortable, picture of the current ecosystem.

Scans across thousands of publicly registered servers have found the large majority carrying file-operation patterns prone to path traversal. A meaningful share of tested servers are vulnerable to command injection or server-side request forgery, and there are documented, disclosed cases of tool description poisoning, where the attack lives in the text a model reads to decide what to do rather than in the code the tool actually executes. A closely related failure mode, configuration poisoning, targets the server’s operational baseline directly: stealthy permission changes or altered defaults that persist across sessions and are hard to catch in a normal code review because the malicious logic lives in configuration state, not application code. Multiple high-severity vulnerabilities, including at least one missing-authentication flaw in a major vendor’s own production package, have already been disclosed and patched.

None of that is a reason to avoid MCP. It’s a reason to treat it the way you’d treat any protocol that hands an autonomous caller real privileges inside your systems: skeptically, and with the controls in place before the agent gets access rather than after an incident teaches you why you needed them. In practice that means an explicit, enforced allowlist of vetted tools per agent rather than open discovery of whatever happens to be reachable; authentication on every remote endpoint with no quiet exception carved out for “internal” traffic; centralized, immutable audit logging of every tool call an agent makes; and secrets pulled dynamically from a real secrets manager rather than sitting in a server’s local config where a configuration-poisoning attack can find them. None of this is exotic. It’s the same discipline any experienced integration team already applies to systems with real privileges, applied here to a caller that can now improvise its own sequence of actions.

Here’s what I’d tell a team starting today.

Treat the tool description as reviewed engineering output, not documentation you write last and skim once. Test it against how an agent actually behaves when given it, not just against whether a human reviewer nods along.

Assume composition you didn’t plan for will eventually happen, and design tools to fail safely and legibly when it does, rather than assuming a chain of calls you never tested simply won’t occur.

Put governance in front of capability, not after it. The allowlist, the auth, the audit log, and the secrets manager are the entry price given where the current vulnerability data sits, not optional hardening for later.

And build against the current specification baseline, not whichever example repository you copied six months ago. The stateless core and the authorization changes in the July 2026 spec aren’t cosmetic; targeting an older baseline today is technical debt you’re taking on knowingly, on day one.

MCP earned the “not just another API standard” framing honestly. It didn’t get there by being a cleaner REST, or a nicer SDK, or a better-documented function-calling convention: all real, all incremental. It got there by changing who, or what, is actually doing the integration work at runtime. The parts of that job the protocol doesn’t standardize (how well you describe a capability, how safely your tools behave when composed in ways you never anticipated, and how seriously you take governance before you grant an agent real privileges) are exactly the parts worth taking seriously before you bet production traffic on it.

---

Is cybersecurity part of your job in any way? If so, we’d like to know what you think for a report we’re writing. Just answer these quick 11 questions. Thanks in advance! Take the survey >

Ryan chats with the GM of Slack, Rob Seaman, about how their new Code Channels feature is bringing multiplayer AI to your team chats.

Topics covered in this episode:

• Tachyon: A sampling profiler ships in Python 3.15's stdlib
• Python Workers are now generally available on Cloudflare
• Flet 1.0 - build cross-platform apps in Python
• marimo-book: Build static books from marimo notebooks
• Extras
• Joke

Watch on YouTube

Sponsored by Logfire from Pydantic: pythonbytes.fm/logfire Connect with the hosts

• Michael: Mastodon / BlueSky / X / LinkedIn
• Calvin: Mastodon / BlueSky / X / LinkedIn
• Show: Mastodon / BlueSky / X

Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesday at 7am PT. Older video versions available there too.

Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it.

Michael #1: Tachyon: A sampling profiler ships in Python 3.15's stdlib

• Python 3.15 adds the profiling package per PEP 799: profiling.tracing (where cProfile moved) and profiling.sampling, the new sampler called Tachyon
• py-spy and Austin exist but copy raw interpreter bytes with no API, so every CPython release risks breaking them; one in the stdlib is a contract to stop breaking profilers
• Defaults: 1 kHz, main thread, wall clock, and a -live top-like view for poking at a slow server
• Output is flexible: pstats, -flamegraph, -diff-flamegraph against a baseline, -heatmap on source lines, -opcodes for specialized bytecode, -gecko for Firefox Profiler with GIL and GC markers
• Profiling modes: wall, cpu, gil (which function is starving my other threads?), and exception, plus -async-aware to see the task graph instead of just select(), -all-threads, and -subprocesses forking a profiler per child
• Near-zero overhead for production; guidance is 10-30 second windows on representative load, and free-threaded builds divide the rate by thread count
• Attach to a running PID, same minor version only; ptrace permissions are the main friction. A 3.14 backport already exists on GitHub
• Caveat: it only sees Python frames, so 90% in calculate() hides NumPy underneath. For native stacks there's Cronon from HRT, 200k samples/sec over DWARF, not yet open source

Calvin #2: Python Workers are now generally available on Cloudflare

• Python Workers are out of beta - now GA, "first-class" language on Cloudflare's Developer Platform
• No more manual JS interop: bindings (queues, R2, D1, Durable Objects) now work natively in Python, e.g. self.env.QUEUE.send({...})
• Runs on Pyodide (WASM-compiled Python), with real TCP socket support for DB connectivity
• Frameworks supported: FastAPI, Django, Flask; AI libs like OpenAI SDK, LangChain, MCP
• Underlying platform work formalized as PEP 783 (PyEmscripten), after a year of discussion
• Bottom line: write real Python on Cloudflare's edge, no JS glue code required

Calvin #3: Flet 1.0 - build cross-platform apps in Python

• Flet hits 1.0 - build Flutter-backed apps from pure Python, no frontend experience needed
• One codebase targets six platforms: iOS, Android, Windows, macOS, Linux, web
• 150+ built-in UI controls, plus support for custom controls / wrapping Flutter packages
• Mobile now supports real Python packages: NumPy, pandas, Pillow, cryptography
• Comes with pytest-based UI testing and an MCP integration for AI coding assistants
• Milestone lands 4+ years after its first PyPI release (Sept 2022) - signals "production ready," not experimental

Michael #4: marimo-book: Build static books from marimo notebooks

marimo-book is a Jupyter-Book-style static site generator built specifically for marimo .py notebooks. It ships polished multi-page sites with Material for MkDocs theming, full-text search, dark mode, and code copy, plus a content-hashed incremental build cache that drops rebuilds from 100+ seconds to roughly 3 seconds on real books. Standout extras include anywidget rendering without a kernel, static reactivity for discrete sliders via pre-rendered lookup tables, an opt-in WASM/Pyodide mode per chapter, and per-chapter launch buttons.

• If you've wanted to publish a marimo notebook as a real book or course site without hosting a kernel, marimo-book gives you the static, searchable, fast-loading output you'd expect from Jupyter Book.
• Alpha (0.1.x), but in production: pin marimo-book>=0.1.5,<0.2; the book.yml schema is stable for v0.1, and dartbrains.org is a real-world user.
• Two-stage build by design: a marimo-aware preprocessor emits plain Markdown + inline HTML, then mkdocs (Material today, zensical tomorrow) renders it. Not a mkdocs plugin, so the shell stays swappable.
• Interactive widgets without a kernel: anywidget Canvas/Three.js/Plotly mounts render statically, and mo.ui.slider with explicit steps gets pre-computed as a static lookup table.
• WASM escape hatch per chapter: set mode: wasm and the chapter routes through marimo's MarimoIslandGenerator, shipping the marimo runtime + Pyodide bundle for full reactivity where you need it.
• Per-chapter launch buttons and extras: readers can jump to molab, GitHub, or a downloaded .py; optional [social], [linkcheck], and [pdf] extras cover OG cards, htmlproofer, and WeasyPrint PDF export.
• Sandboxed notebooks: the sandbox mode reads PEP 723 inline metadata and provisions per-notebook envs via uv for portable builds, at the cost of slower first runs.

Extras

Calvin:

• Great overview of a new feature in Python 3.15 - frozendict

Michael:

• Microsoft Plugs Nearly 1,000 Security Holes in Windows
• I’ll be speaking at PyBay 2026
• PyCon NL on October 15 in Utrecht
  • Heading to Europe in October? PyCon NL is October 15th in Utrecht. One day, three tracks, about 350 people. It's an hour by train from Schiphol. There's also a session just for community organizers from groups like PyLadies, PyData, and Django. And the location fits. The Netherlands is where Python itself was born.

Joke: You have homework (no really ;) )

Watch Interview with Big Data engineer in 2026 by Kai Lentit

Download audio: https://pythonbytes.fm/episodes/download/497/faster-than-light-profiling.mp3

---

When I wrote about GPT-6 Astra in Microsoft Foundry a few weeks ago, I did not yet have access. There was plenty to discuss about what the model promised, but the most interesting part was still missing: using it in my own work.

Now I can start doing that! I am writing this article with GPT-6 Astra selected in Copilot Cowork, using information I collected with Copilot as the starting material and my blog-writing skill to guide the draft. A slightly meta example: using Astra to help write about using Astra. But let’s keep the distinction clear. This is a real writing task, not yet a comparison proving that Astra is better than the other available models. The interesting question is no longer just what Astra can theoretically do. It is what changes when I put it to work.

Let’s take a closer look.

From a model announcement to a work option

For me, the biggest change is not another set of specifications. I covered those in the earlier article. It is the shorter distance between hearing about a model and using it for something I actually need to get done.

My starting point here was not an empty prompt asking for an article about GPT-6. I brought research, my previous post, a direction for the follow-up, and my own writing guidance. I also identified details that still needed checking.

That is much closer to how I want to work with AI.

Here is the context. Here is what I am trying to achieve. Help me move it forward, without pretending the missing pieces are already known.

For this article, that means separating announcements from observations, avoiding another launch recap, and leaving room for tests I have not completed yet. A polished draft that quietly invents those results would be worse than an unfinished one that shows exactly what is missing.

The writing is only part of the task. Knowing what not to include and refining the result from the AI draft is very important.

Foundry and Cowork – the model is only part of the experience

I see two different starting points here.

With Microsoft Foundry, my question is about building a solution. How should an application or agent be designed, connected, evaluated, deployed, and operated?

With Copilot Cowork, my question is about the work in front of me. What can I delegate, what context should I provide, and how much checking will the result need?

Those questions are related, but they are not interchangeable.

Selecting Astra in Cowork is not the same thing as deploying Astra in Foundry and building an application around it. The surrounding experience matters: instructions, tools, available information, permissions, and the way the work is coordinated.

That also matters when evaluating results.

If an article draft turns out well, I cannot automatically credit the model for everything. Background information provided are essential part of the setup. Likewise, a disappointing result might reveal missing context rather than a limitation in reasoning.

I want to evaluate the whole way of working, not just admire the model badge.

For my own work, Cowork is the place to start when I want help completing a substantial task in an existing work experience. Foundry becomes relevant when I need to build and operate a repeatable solution with explicit architectural and deployment choices.

This article is a starting point, not a verdict

Writing a follow-up is actually a useful first task. There is an existing argument to continue without repeating it. There are technical details with different levels of certainty. There is a personal voice to preserve. And there is a temptation to turn an enthusiastic introduction into a conclusion before the evidence exists.

For this draft, I want Astra to help with three things:

• Find the new story. What has changed enough to justify another article?
• Keep the boundaries visible. What is documented, what have I personally observed, and what remains untested?
• Produce something worth editing. Not simply more text.

That last point is important. A longer response is not automatically a better result.

If I spend more time removing repetition, checking unsupported statements, and putting my own perspective back into the draft, the apparent productivity gain can disappear quite quickly.

This is also why I find the combination of a model and a reusable writing skill interesting (yes, I have a skill in Cowork that helps me write blog posts). It provides guidance about tone, structure, and how to handle uncertainty rather than explain everything again from scratch.

Astra versus Auto – make it earn the selection

For my next tests, I want to compare Auto with explicitly selected Astra.

I am not starting with the assumption that manually choosing Astra must be better. If Auto gets me an acceptable result with less effort, that is useful too. And it often is – I will usually just use Auto for most tasks.

I would start with tasks that resemble my actual work:

• Turn research and personal notes into an article with a clear argument.
• Compare several documents and produce a recommendation that preserves disagreements and uncertainties.
• Build a workshop outline from a brief, with a coherent flow and practical exercises.

I want to keep the source material, instructions, and acceptance criteria consistent. I would also use separate tasks so that one attempt does not benefit from corrections made during the other.

Then I can look beyond which response feels more impressive at first glance. Did it follow the brief? Did it preserve important qualifications? Did it miss a source? How much rewriting was necessary? Was the deliverable usable?

Reasoning effort – what does this task deserve?

Cowork’s model guidance describes five reasoning-effort choices: Light, Medium, High, Extra High, and Max. Higher effort involves a trade-off in response time and Copilot Credits. Microsoft explains this under Set the reasoning effort level to balance quality, speed, and cost in Choose a model for Copilot Cowork.

That makes this more interesting than simply choosing a model.

My proposed comparison is to run the same substantial task at Medium, High, and Max, then record:

• Time to an initial deliverable.
• Credits consumed, where usage can be reliably attributed to the task.
• Clarification questions and correction rounds.
• Factual errors or missed requirements.
• My own review and editing time.
• Whether I accepted the result, revised it, or started again.

If I cannot measure task-level credit consumption reliably, I will say so rather than estimate it.

The question I want answered is simple: does the extra reasoning (and cost) reduce the total effort needed to get an acceptable result?

A slower run could be worthwhile if it saves substantial review. A faster one could be the better choice when the task is straightforward. And Max should have to demonstrate its value—not become my default because it sounds reassuring.

The same applies to cost. A cheaper individual run is not necessarily a cheaper completed task if it needs several retries and extensive manual correction. On the other hand, spending more does not automatically buy an improvement that matters.

I want to measure the whole journey to something I can use.

A note for us in Europe – documented, but not yet visible in my Foundry EUR Datazone

In my first Astra post, I noted that the published deployment options were Global and U.S. Data Zone. There is now an update for us in Europe.

Microsoft’s September 22 article, GPT-6 Astra, Sol and Luna: For production agents in Microsoft Foundry, explicitly includes Astra in EU Data Zone availability.

The Foundry Models region availability page also listed Astra for the EU Data Zone when I checked.

Of course, I went to look in my own Foundry. And… not yet at least for me!

On the morning of September 23, 2026, Astra was not available for me to deploy to the EU Data Zone. I could deploy it to Global Standard or U.S. Data Zone.

GPT-6 Sol, on the other hand, was already available to deploy to the EU Data Zone.

It looks to me like EUR Datazone availability for Astra may still be rolling out. Given the published availability, I expect this to happen soon.

If processing location matters for your project and customer, check the model and deployment type in your own subscription before committing to an architecture or promising availability to a customer.

One more distinction: Foundry deployment options do not establish where a Copilot Cowork task using GPT-6 Astra is processed. Those arrangements need to be checked separately. At this moment GPT-6 Astra in Cowork is a preview model and runs using OpenAI subprocessor, which doesn’t define the datazone. Now that Astra is in Foundry, this hopefully changes soon.

What did writing this article cost?

I have also been following the Copilot Credits consumed while working on this article, using /cost in Cowork.

Before adding this cost information and further updates, the total was 232 Copilot Credits. That was much less than I expected.

This is an observation from this particular writing session with GPT-6 Astra selected—not a fixed price for an article, and not a comparison with Auto or another model. It also excludes the updates made after that reading.

Still, it gives me a concrete starting point. Instead of only discussing what deeper reasoning might cost, I now have an actual usage figure from my own work.

The next question is how that consumption compares with the quality of the result and the time I spend reviewing and editing it. Credits are one part of the cost. My own time is another.

From a good answer to accepted work

I am excited that I can now include Astra in my own Cowork experiments. But I do not want the conclusion of this follow-up to be that a new model appeared and therefore everything improved. The useful conclusion will come from the work.

For this article, success means a follow-up that adds something new, keeps uncertain details visible, and takes less effort to finish without lowering the quality. For another task, the acceptance criteria will be different.

That is where I want to focus next: the cost and reliability of a completed, reviewed, accepted outcome.

Not just what the model produced but what I could actually use.

That is a more useful conversation about the future of work than choosing a favourite model and assuming it belongs in every task. We need to learn where deeper reasoning helps, where a lighter approach is enough, and where human judgement remains essential.

Now, on to the testing!