Cursor shipped Grok 4.6 at two dollars in and six out, Anthropic replaced its Slack chatbot with Claude Tag, and cloud agents will review a pull request from a one line comment. All good tools. None of them knows which account your service runs in, what depends on it, or what changed last week, so every session starts with the same discovery work. This is about that work, where it costs you the most, and why live infrastructure state belongs in a database rather than in a skills file or a vendor's memory.
Why your agent doesn’t know where anything runs
Ask an agent to change a service and it does a decent job on the code. Ask it where that service actually runs, which account it sits in, what depends on it, what changed last week, and it has nothing.
That is not a model problem. Cloud agents and CI reviewers run in isolation. They see the code, but they have no idea how that code is applied to the real infrastructure or where it is going to be running. A Slack bot knows what people typed in the channel, not what is deployed. And harness memory is worse than nothing sometimes, because it happily hands you back how things looked when the agent last touched that file.
So you pay twice. Once at the start of every session, while the agent runs around figuring out where things are. And once per change, because a reviewer that cannot see the infrastructure cannot tell you what your pull request is going to break, and nobody can call a security alert a false positive until something has actually checked whether the thing is exposed.
Orientation: the work your agent redoes every session
Does more tool access solve this?
No. You get access and a pile of tools, and the agent still starts from zero every time.
What we often hear is: what’s the point, I already have the AWS Agent Toolkit with MCP and everything. And yeah, yeah, you do. That is a real thing and it is worth having. You plug it in, you get AWS access plus some tools. But you still have to do the work each time a session starts, pulling on that interface to get the data and calculate the thing you were actually looking for.
Credit where it is due, the Agent Toolkit for AWS is better built than the objection assumes: a managed MCP server, full API coverage behind IAM, live docs, sandboxed script execution, and skills the agent loads on demand so they “do not consume unnecessary context.” Fine. It still shows up knowing nothing about your estate, and it does not claim otherwise. Which account, which service, what depends on it, what changed. That is archaeology, and your agent does it from cold every time.
Through a context layer you send one query instead: I’m working with this service. Because it is a temporal graph, what comes back is the shape of the thing. This is what it is, here is where it lives, these are the dependencies, this is how much it changed over time. Then you start working.
Now make it multi-cloud and the arithmetic gets ugly. Something on Google Cloud, something on AWS, Cloudflare in front of it. You would need to connect an MCP server for every single data source, and every one of those comes with a bunch of tools that eat into your context. That is the tool-layer cost we measured back in episode #2, and Anthropic’s own write-up on code execution with MCP says the same thing: load every tool definition upfront, route intermediate results through the window, and things get slower and more expensive as you connect more servers.
With B.O.R.I.S we are very conscious about the number of tools, and we constantly try to reduce them, not add. Protect the context, keep the interface unified. You can try to cram everything into one agent instead, but then you are doing the orientation work anyway, with much less window left for the actual session.
Two more things matter, and they are the ones people skip. Pre-calculated is not enough on its own, it has to be updated automatically, otherwise you are serving old information as if it were current. And there should be real-time validation on top: the agent asks about one specific resource and something goes and checks it, rather than handing over a snapshot from whenever. That is the difference between a cache and a source. There is also the case nobody plans for, which is a company with more than one AWS organization, where you have to map identities and topology across both. That is a confusion. Whatever handles it, the interface should stay the same as you plug more systems in.
Claude Tag is nice, and it only knows Slack
The tax is easiest to see where people ask questions in plain language all day, which is Slack.
Is a Slack agent enough context on its own?
No. Its memory is attached to the channel, so it knows what the team said, not what the team runs.
You used to have Claude in Slack as a chatbot, flat rate as far as we could tell, chat as much as you like. Claude Tag supersedes it and is a different class of thing: API-billed, you pick the model, you can customize it a lot, load skills, wire up connectors. Much better offering. The docs fill in the parts that matter for a budget conversation: no per-seat charge, channel work draws on a usage balance somebody funds with a spend limit on top, admins extend it through connections and plugins and skills per channel or workspace or org, each task runs in a sandbox that gets thrown away when the conversation goes idle, and the memory is attached to the channel and shared with everyone in it.
Good product. But it is still a bot running inside Slack, which means it has no recollection of stuff that is outside of it. Ask it where a service lives, what depends on it, which account it went into, and all it has is whatever a human typed in that channel plus whatever a connector can reach.
This is where a context layer is genuinely helpful, and it is what we have been doing with several customers: connect B.O.R.I.S to Claude Tag over OAuth 2.0 machine credentials, and now the bot can query the state of the infrastructure. It finds where things are quickly, it answers the questions developers ask a dozen times a week, and it has something real to ground its reasoning in instead of guessing. Because the graph is temporal it can also explain how the infrastructure evolved over time.
If you are going to build that yourself, two documents matter and they are not the same document. The MCP authorization spec is the core: a protected MCP server acts as an OAuth 2.1 resource server, tokens bound to an audience, scoped access. But that flow assumes a human sitting at a browser clicking approve, which a headless integration does not have. The machine-to-machine case lives in a separate, optional client credentials extension: client ID and secret, or a signed JWT, for background services and CI. Being an extension has a practical consequence, which is that both ends have to support it. Check that before you plan a project around it.
One budget note, since Claude Tag is consumption-billed. Every discovery task now spends from that funded balance. Working out where a service lives was always expensive, it just used to be invoiced to your engineers instead.
Your code reviewer can’t see where the code runs
In Slack a blind answer costs you a question. In CI it costs you a merge.
What should a CI reviewer actually be answering?
What this pull request is going to break, and what to keep an eye on after the release. That needs dependencies, not just the diff.
Run Claude Code or Codex in GitHub Actions, or use Cursor’s cloud agents, and those are running in isolation. They see the code and they have no idea how it is applied to the real infrastructure, where it will run, what the constraints are, how it evolved, what depends on it. And then the specific one that catches everybody: if your Terraform is in a separate repository from your source code, the code reviewer has nothing to go by.
Split repos are a perfectly normal layout, so this is a configuration problem, not a law of nature. Cursor’s cloud agents support multi-repository environments for exactly this, tasks that span frontend, backend, infrastructure, shared libraries. Someone has to set that up on purpose though. The default is the blind version.
Picture the scale-up rhythm, because that is where it bites: you change one tiny feature, you ship every week, everything is green, and then your users find out that some other thing is broken. With the dependency map the reviewer can hand you something better than an approval, which is a short list of what to watch after deploy. Honestly, a human reviewer with three tabs open usually cannot produce that either, which is part of why nobody does it.
It works in CI/CD, in code review, in any chatbot you can plug it into, and in agents you build yourself or buy. Buy some ITSM or DevOps agent and you can plug the context layer in there too and it will be helpful there. Same argument Vladimir made in episode #16: plug in the context before you reach for anything clever.
Security triage: proof instead of guessing
Review is where missing context wastes time. Triage is where it wastes attention, which is scarcer.
How do you tell a real vulnerability report from noise?
You check it against the live configuration and the dependencies until you can defend the answer. False positive, or real but not reachable from the internet.
Security scanning tools throw alerts at you constantly, and usually they see a narrow slice, basically just the code, so they cannot tell you whether the finding is a real thing you should worry about. The question that lands on an engineer is always the same one: I have this alert, how do I know if this is actually a threat to me or not?
Giving the agent the code already helps a lot. What changes the answer is letting it go and look at the live configuration, and track dependencies, sometimes into a different repository, until you can actually conclude something. Hey, this is a false positive. Or, this is there, but we don’t need to worry, because it is not exposed to the internet. The point is not the analysis. The point is that you get to spend your attention on the things that matter and not on the noise.
Then there is the harder version, which is running a bug bounty program. In the AI era those reports come in at machine speed, in volume, and triage cannot match it. Something on the validation side has to go inside all the systems, AWS and the codebase and everywhere, and check whether the thing is real, and decide whether a human should double-check it. The category that burns the most time is the report that is not a security issue at all: software not behaving as it is supposed to behave, which looks like a vulnerability and isn’t one.
The published numbers are blunter than our anecdotes. HackerOne says the whole industry saw report volume more than double after the capable models landed in early 2026, and they are explicit that it hit programs unevenly, public ones harder than private, open-source repos hardest of all thanks to duplicate AI-generated scans. Their answer was part policy, part tooling: a Code of Conduct update for AI-assisted research, detection and enforcement, smart routing to get reports to the right analyst, plus their own agents for deduplication and escalation.
Elastic published the closest thing to this in production, an AI triage pipeline for their own HackerOne program, built after 1,390-plus reports in the first half of 2026, which is more than 2024 and 2025 combined. Two details are worth stealing. Their rules encode which things are features rather than vulnerabilities, which is organizational context, not model capability. And a human still makes the final call on every report, as a rule in the pipeline rather than a hope about the model.
Skills for judgment, a database for state
Those three surfaces are the case for context. The next two questions are where it should live and who should own it.
Should infrastructure state live in a skills file?
No. Skills are for how-to instructions and business judgment. Ephemeral stuff like the state of your infrastructure needs a proper database.
There is still space for skills, and a context layer does not replace them. In your skills files you want how-to instructions, how you run your business, the business context that is not scrapeable from any engineering system. The decisions people made, the reasons, the do-things-this-way-not-that-way that otherwise only exists in somebody’s head. That belongs in skills.
What you don’t want to put in skills is ephemeral information, such as the state of your infrastructure. And there is a real case where a text file is completely fine, which is what makes this worth saying: a hobby project, home automation, one account, maybe two, VPC networking that never changes. A skill covers it, and you can have something like OpenClaw refresh those notes on a daily job. But as the number of accounts and systems and moving parts grows, that becomes a real problem you have to manage. The file has to be maintained as reality drifts. And a text file gives you no historical perspective, because the moment you add one it gets too big to load. It is just not the right medium.
In physical datacenters people had exactly the same problem. All those servers, you need to keep track of what is where, so you keep a configuration management database: the ITIL thing that stores configuration items and, more importantly, the relationships between them, with change history for audit. This is the configuration database of the agentic era.
The rhyme cuts both ways, and we should say it out loud: CMDB projects have a long history of going stale, precisely when they depend on humans to update them. So continuous ingestion is the claim that has to hold up. If you are evaluating anything in this space, including ours, that is the thing to test.
Own your context, because egress is slow
If state belongs in a database, the next question is whose database, and what happens when you want to switch tools.
Why own the context instead of leaning on vendor memory?
Because memories don’t come with you when you jump between tools, and getting your data back out of a vendor is documented as slow.
You can probably tell from how we talk about these tools that we hold multiple subscriptions: Claude, Codex, Cursor. All of them have their own memory, and you can’t take the memories with you when you jump between them. With a separate context layer, jumping from Claude to Codex you get the same picture either way.
We go further than that, and it connects to episode #7 and episode #12: we try to disable harness memory wherever we can. Not on principle. The reason is that a context layer gives you the recently scraped state plus tools to look up the live state, while memory gets written whenever the agent happens to touch something. So it records how things looked at that moment and then serves it to you as current. Memory like that can be actively misguiding in a coding agent. Same goes for hand-written skills files that document where things are. Somebody has to keep them true, and that somebody is you.
Then portability turns into a lock-in question, which is the part most people are not thinking about yet. You will run multiple providers whether you planned to or not: Claude Code locally, maybe Bedrock as the provider in CI, plus some agent you bought that runs its own models. So owning the context and being able to plug it into a different system is what makes leaving a vendor survivable.
You don’t have to take our word for the friction, it is on their own help pages. OpenAI says a ChatGPT export can take up to seven days, with a download link that expires 24 hours later. Anthropic documents self-service export on individual plans with a wait while it is generated, and notes the export cannot be imported into another personal Claude account. Two honest caveats: slow is not proof of intent, and Anthropic does now publish an import and export path for Claude’s memory specifically. But the real limitation survives both. A ZIP of chat history was never portable engineering context, and no export button turns it into one.
The practical split is configuration versus context. Configuration is cheap to move now. You can genuinely ask an AI to move your Codex configuration over to Cursor and it will do it. Context is not like that, and that is the part worth putting a tool behind.
The model market, and why it matters here
That is the gap, the surfaces, and the two decisions. The reason all of this is getting urgent rather than theoretical is what is happening to model prices, so here is the news that started the conversation.
Grok 4.6 inside Cursor
Is Grok 4.6 cheap for what it scores?
On list price, yes. Two dollars per million input tokens, six per million output, for frontier-tier benchmark numbers. Fast mode costs double.
The first thing that caught the eye was not a benchmark, it was the name. When the model was announced it was not SpaceX or SpaceXAI, it was Cursor Grok 4.6. And Grok 4.5 was Cursor Grok 4.5 before it. So these are the first generations of models released around the acquisition of Cursor by SpaceX, combining the compute SpaceX had with the engineering priorities and the coding data on the other side. You can see it in their own surfaces: Cursor’s launch post presents the model as a joint release, and the models and pricing docs put “Cursor Grok 4.6” in the first-party Cursor Models pool next to Grok 4.5 and Composer 2.5.
Worth getting the sequence right, because the deal and the models overlapped. Cursor’s own announcement says the deal closed on 14 August 2026, after a partnership announced back in April, and describes Grok 4.6, out the Wednesday before, as “an early look at what we can now build together.” So 4.5 and 4.6 were built and shipped during the process, not after it. Either way the point stands: the release cadence is high and the compute story behind it is now explicit. Suddenly Elon is back in the game.
The pricing is the interesting bit. Two and six is very competitive. Compare it properly: Sonnet 5’s promotional pricing was $2 and $10, and Anthropic had said the real rate would be $3 and $15 from September 1. Days before we recorded, they cancelled that. Sonnet 5’s page now says the introductory pricing is permanent and the $3/$15 rate “no longer applies.” Was that because of Grok? No idea, and nobody outside those two companies knows either. But there is your data point. There is a meme going around about which model is best right now and it turns over to the next company every month, and for us as consumers that is good: competitive market, and the price is supposed to go a bit lower than it is now. Right now what they charge is frankly ridiculous, especially on API rates if you are a heavy user.
On the intelligence claims, apply the usual discount, if you are to believe benchmarks at all, because you can have your opinions about benchmarks and about companies gaming the system and training models to score well on them. For the record, SpaceXAI’s announcement puts Grok 4.6 at 61 on the Artificial Analysis Intelligence Index, level with GPT-5.6 Sol in Max mode, with Fable 5 Max one point ahead at 62. So frontier-tier scores at a discount, with the parity landing on the OpenAI model rather than Anthropic’s, which still edges the composite.
And then speed, which is underrated. People don’t talk enough about it. If you spend your days with Opus, Fable and GPT-5.6 you know those take time to think: you send something in, it comes back in a minute or two. That is why fast mode matters, and why a 50% discount matters, because the discount is what makes fast mode affordable. If you have the budget, go with fast mode instead of sitting there for hours waiting for the models to spin their wheels. The trade is at least priced openly, since the launch post puts the fast variant at double the standard rate.
One number belongs next to all this cheap-intelligence talk. SpaceXAI’s release notes list $2 / $0.50 / $6 per million tokens for input, cached input and output, and then a higher band of $4 / $1 / $12 above 200k. That band is on SpaceXAI’s own API; Cursor does not publish the same threshold for requests routed through its pool. So a session that lets its context sprawl does not just get slower and dumber, on that price sheet it crosses into a band that doubles your rate. Which is a fairly direct argument for the context discipline this whole post is about.
If you gave up on Cursor a while back, the in-house model then was Composer, okay-ish, sonnet-level rather than frontier. With a frontier model in the first-party pool it becomes tempting to try it again.
What actually decides the bill
Do cloud agents and CI runs come out of your subscription?
Not as a flat rate. Cursor’s cloud agents bill at the selected model’s API pricing against your plan-included usage, then spill into on-demand once the allowance is gone.
The narrower question, and the one anyone running agents in CI should be asking: does the included pool reach the CLI? Cursor was struggling for a while because they charged API rates for everything. They had Composer 2.5 more or less unlimited in auto mode on the subscription, but that was not the smartest model. Now there is a frontier model in auto mode too. So, do they let you use auto mode in CI? Because if you are not paying API rates when you run the Cursor CLI in GitHub Actions, you can run code reviews on your subscription, and that becomes very interesting. If they fix the CLI, they might really be back in the game.
Half of that is documented now. There is a guide to running Cursor CLI in GitHub Actions, authenticating with an API key from the dashboard, and the CLI does support Auto model selection. What the page does not settle is the half that decides the bill: whether CI usage comes out of plan-included allowances or bills as on-demand once they are spent. Mechanism documented, economics not. So price a pilot instead of assuming.
The pricing docs do answer the model side. Grok 4.6 is in the Cursor Models pool included with paid individual plans, Auto bills at the list price of whatever it routes to, and third-party models carry an extra Cursor Token Rate of $0.25 per million on Teams and Enterprise plans, with first-party models, Grok and Composer, exempt. That exemption only applies on the business tiers, but it is exactly the kind of asymmetry that makes a first-party frontier model strategically interesting.
Here is the loop that makes this concrete, and it is worth copying. The pull request pipeline is an automated skill: it opens the PR, does some fancy things, and then posts two comments, one asking Codex to review, one asking Cursor. Cursor documents that trigger directly, since a comment @cursor on a GitHub PR or issue, or a Bitbucket PR, is enough for a cloud agent to pick it up. Then wait two or three minutes for the reviews to land and fix whatever findings appear. That is the loop now.
One correction on the economics, because it is easy to get this wrong: it feels like you are paying whatever is inside the subscription since it runs inside their cloud, but execution location does not determine billing. Cursor’s cloud agent docs say cloud agents are charged at API pricing for the selected model. So the reviews draw down plan-included usage at model pricing and then spill into on-demand, which is why the docs want you to set a spend limit first. The subscription is a budget, not a flat rate. And there is the other concern, worth naming rather than selling past: can you run this in their cloud or not? For code only it is sometimes a bit more flexible. Sending a repo into someone else’s sandbox is a decision with a security review attached, and it is easier to justify for source code than for anything holding production credentials.
Key numbers
| Stat | Source |
|---|---|
| Grok 4.6 at $2 per million input tokens and $6 per million output, fast variant at double the rate | Cursor launch post, SpaceXAI announcement |
| Sonnet 5’s introductory $2/$10 made permanent; the $3/$15 rate scheduled for September 1 “no longer applies” | Claude Sonnet 5 (Anthropic) |
| Bug bounty report volume more than doubled industry-wide after the early 2026 model releases, unevenly by program | AI-driven report volume (HackerOne) |
| 1,390-plus reports to Elastic’s program in the first half of 2026, more than 2024 and 2025 combined | AI vulnerability triage (Elastic Security Labs) |
What this means for your team
The message is really about trust. We want to move fast, that is the whole reason to adopt agents. But if they start giving you wrong information, then it is worse than going slow and doing the thing properly.
That is what makes it possible to trust changes more, and then to build automations you can actually rely on, the triage loops and the security workflows included, because their conclusions can be checked instead of believed.
Four things you can do this week:
- Check what your CI reviewer can actually see. If application code and Terraform sit in separate repositories, the agent reviewing either one is blind on the other unless somebody configured cross-repository context. Cheapest place to notice that context is missing.
- Ask the release question, not the style question. What is this pull request going to break, and what should we watch after deploy. That is a better test of a review tool than whether it catches a naming nit.
- Price the subscription-versus-on-demand question before you scale review automation. Cloud agents bill at the model’s API pricing against plan-included usage and then go on-demand, so set a spend limit and pilot the CLI-in-CI pattern rather than assuming it is covered. And watch the long-context bands: on SpaceXAI’s API, prompts above 200k move to $4 / $1 / $12, a threshold Cursor does not document for its own pool.
- Keep judgment in skills and state in a database. How-to instructions, decisions and conventions belong in skills files. Live topology does not, and a text file gives you no history without becoming unloadable.
For what it is worth, on this one there was a before and after for us. Going back to running agents without a context layer is not something we look forward to. But the market is still maturing, so plenty of teams have not felt the pain hard enough yet to go looking for the fix. Every new agent surface, a Slack bot, a cloud reviewer, a CI job, inherits the same blind spot the moment it has to reason about infrastructure it cannot see, and no amount of extra tool access fills that in.
FAQ
Why doesn’t my coding agent know what’s running in production?
Because it runs somewhere your infrastructure isn’t. Cloud agents and CI reviewers execute in isolation and see the diff, not the estate it lands on. A Slack bot’s memory is attached to the channel, so it holds what people typed rather than what is deployed. Giving the agent cloud credentials helps, but it does not remove the work: it still has to discover which account, which service and what depends on it every time a session starts.
How do I stop my coding agent guessing which AWS account a service runs in?
Give it something to query instead of something to infer. Credentials alone do not fix it, because the agent still has to go and find out where things are before it can act, and it starts from cold every session. What removes the guessing is a pre-calculated, continuously updated picture of the estate that the agent asks one question of at the start: this is the service, this is the account, these are the dependencies, this is what changed. Then it also needs a way to check the live state when the answer has to be exact. Keep your skills files for judgment and how-we-do-things, and keep infrastructure state out of them, because state that changes daily goes stale in a text file between one session and the next.
Does Claude Tag know what’s running in my AWS account?
Not on its own. Its memory is attached to the Slack channel, so it has whatever a human typed there plus whatever a connector can reach. Ask it where a service lives, what depends on it, or which account it went into, and it has no recollection of anything outside Slack. Connecting a context layer over OAuth 2.0 machine credentials is what lets it query the current state of the infrastructure directly.
Can AI code review catch infrastructure problems?
Only if the reviewer can see the infrastructure. Cloud agents and CI reviewers run in isolation and see the diff without knowing how the code is applied or where it runs. If your Terraform is in a separate repository from your source code, the review has nothing to go by unless somebody configured cross-repository context on purpose. Cursor’s cloud agents support multi-repository environments, for example, but the default is the blind version.
How do teams triage AI-generated bug bounty reports?
By validating the claim against live configuration and the codebase instead of just reading the report. HackerOne recorded industry-wide report volume more than doubling after the early 2026 model releases, and Elastic built a triage pipeline after taking 1,390-plus reports in six months. Two design choices carry it: rules that encode which behaviors are features rather than vulnerabilities, and a human making the final call on every report.
Do I still need a context layer if my agent already has AWS access?
Access is not orientation. The Agent Toolkit for AWS gives an agent authenticated API coverage behind IAM, live docs, sandboxed scripts and on-demand skills, and it still arrives knowing nothing about your estate. Which account, which service, what depends on it, what changed: that is work it does from cold every session. Connecting a separate MCP server per data source also eats your context window as the tool count grows.
How much does Grok 4.6 cost?
$2 per million input tokens and $6 per million output, with fast mode at double. On SpaceXAI’s API the release notes list $2 / $0.50 / $6 for input, cached input and output, plus a higher band of $4 / $1 / $12 above 200k. Cursor does not publish that threshold for its own routed pool, where Grok 4.6 sits in the first-party Cursor Models pool included with paid individual plans.
Can I export my data from ChatGPT or Claude?
Yes, with friction, and it is documented. OpenAI says a ChatGPT export can take up to seven days and the download link expires after 24 hours. Anthropic offers self-service export on individual plans with a wait while it generates, and says the export cannot be imported into another personal Claude account. The deeper problem is that a chat archive was never portable engineering context anyway.
Related episodes
- #12 - Semantic Layers, Context Layers, and Agents That Stop Guessing - the long version of the context-layer argument this post applies to Slack bots and CI reviewers.
- #7 - When Agent Memory Helps and When It Hurts - why we turn harness memory off rather than trust it.
- #2 - The Tool Layer - where we measured what every extra MCP server costs your context window.
- #16 - How DevOps Makes AI Safe to Scale - the trust and evidence conversation behind the closing argument here.
- #6 - The Big AI Squeeze - the token economics episode behind the expectation that a competitive market pushes prices down.
Resources
- The Grok 4.6 launch, the price war around it, and the branding timeline: Cursor’s announcement and SpaceXAI’s announcement are the primary sources for the $2/$6 headline rate, the fast variant at double the price, and the benchmark claim that deserves a discount - 61 on the Artificial Analysis Intelligence Index, level with GPT-5.6 Sol in Max mode, with Fable 5 Max a point ahead at 62. SpaceXAI’s release notes add the caveat that matters most for context-heavy sessions, scoped to SpaceXAI’s own API: $2 / $0.50 / $6 per million tokens standard, and $4 / $1 / $12 above 200k, a band Cursor does not document for its routed pool. Read alongside Claude Sonnet 5’s page, which confirms the introductory $2/$10 is now permanent and the $3/$15 rate scheduled for September 1 “no longer applies”, and Cursor is joining SpaceX, which gets the sequencing right: an April partnership, a deal that closed on 14 August 2026, and Grok 4.5 and 4.6 released during that process rather than after it.
- Cursor’s own docs, for the economics behind review automation: Models and pricing confirms that Cursor Grok 4.6 sits in the first-party included pool with Grok 4.5 and Composer 2.5, that all Auto modes bill at the routed model’s list price, and that the $0.25 per million Cursor Token Rate on third-party models applies on Teams and Enterprise plans with first-party models exempt. Cloud agents documents the review loop - comment
@cursoron a GitHub or Bitbucket PR and an agent picks it up - plus the multi-repository environments that let a reviewer see infrastructure and application code together. Cloud agents billing is the correction to the “it’s in their cloud so it’s on the subscription” intuition: charged at API pricing for the selected model, drawing on plan-included usage and then on-demand, which is why a spend limit is the first thing the docs ask for. Cursor CLI in GitHub Actions covers the mechanism, authenticating with an API key; what none of these pages settles is whether that CI usage lands inside plan allowances or outside them. - Introducing Claude Tag (Anthropic) and the Claude Tag docs - what replaced the old Claude in Slack app, and the details that matter: no per-seat charge but consumption-billed channel work against a funded balance with a spend limit, extensibility through connections, plugins and skills, an ephemeral sandbox per task, and memory attached to the channel rather than to your infrastructure. Pair with the MCP authorization specification for the core OAuth 2.1 resource-server model, and the optional OAuth Client Credentials extension for the headless case - client ID and secret or a signed JWT assertion, with both client and server needing to support the extension, since extensions are opt-in and off by default.
- AI vulnerability triage: bug bounty reports at $2 each (Elastic Security Labs) and AI-driven report volume (HackerOne) - the measured version of the triage problem. HackerOne describes an industry-wide surge of more than 100% in report volume and is explicit that the impact varied by program, hitting public and open-source programs hardest. Elastic’s pipeline, built after 1,390+ reports in six months, is the closest published implementation, and two of its design choices are the argument in production form: organization-specific rules encoding which things are features rather than vulnerabilities, and a human making the final call on every report.
- What is the Agent Toolkit for AWS? and Code execution with MCP (Anthropic) - read these together to see exactly where the “AWS access is enough” objection bites. The toolkit gives agents authenticated AWS API access, live docs, and on-demand skills specifically designed not to consume unnecessary context; it still doesn’t arrive knowing your estate, which is the per-session orientation cost. Anthropic’s post is the mechanism behind the multi-provider math: every additional connected server’s definitions and intermediate results compete with the work for window space.
- What is a configuration management database (CMDB)? (Red Hat) - background for the configuration database of the agentic era. Useful for the relationship-tracking and change-history parts that map cleanly onto a context layer, and useful as a warning: the classic failure mode of a CMDB is going stale, which is precisely the property continuous ingestion has to prove.
- Export reality check: exporting your ChatGPT history and data (OpenAI) - up to seven days to arrive, download link expiring after 24 hours - and export your Claude data (Anthropic), which notes an export can’t be imported into another personal Claude account. These document the friction without proving intent, and they make the deeper point on their own: a chat archive was never portable engineering context.
- Prior episodes this one builds on: #12 - Semantic Layers, Context Layers, and Agents That Stop Guessing is the full version of the context-layer argument applied here to Slack bots and CI reviewers; #7 - Agent Memory is why we disable harness memory rather than trusting it; #2 - The Tool Layer is where the MCP-per-data-source context cost was first measured on this show; #16 - How DevOps Makes AI Safe to Scale is the trust-and-evidence discussion behind the closing argument; and #6 - The Big AI Squeeze is the token-economics episode behind the expectation that a competitive market pushes prices down.