Ronald van der Plas · Jul 30, 2026
Content Insights Tip #83 | Bulk vs Non-Bulk in Sitecore Content Hub: Choosing the right execution strategy
When creating an External Mass Action in Sitecore Content Hub, one of the configuration options you'll encounter is the Bulk toggle. It's easy to overlook. After all, it is just a single checkbox in the Selection component, surrounded by several other settings that appear equally important. Yet this checkbox has an impact that most people might not realise. It doesn't simply determine whether multiple assets can be processed together. Instead, it changes how Content Hub communicates with your external service and, more importantly, where the responsibility for processing those assets lives. At first glance, the difference seems straightforward. With Bulk disabled, Content Hub sends a single request for every selected asset. Enable Bulk, and those assets are grouped into a single request. While that's technically correct, it doesn't explain why Sitecore offers both options or when one approach is more suitable than the other. To answer that question, let's first look at what actually changes. Non-Bulk processing When Bulk is disabled, every selected asset results in its own HTTP request. If a user selects three assets, your endpoint is invoked three times. Each request contains information about a single asset, making every execution completely independent from the others. Request 1 { "TargetId": 34181, "TargetIdentifier": "xEYMBs3UTo6ZDN_Xp8ykgg", "context": {} } Request 2 { "TargetId": 34253, "TargetIdentifier": "o-SNrVDwTRWIzcHG0cu8VA", "context": {} } Request 3 { "TargetId": 34127, "TargetIdentifier": "hqFQTkdmQGeHDIJDzBnHRw", "context": {} } This execution model has an important consequence. Content Hub is invoking your service once for each selected asset. Your service doesn't know how many assets the user selected, because each request always contains a single asset. Bulk processing With Bulk enabled, the interaction changes. Rather than invoking your endpoint once per asset, Content Hub does a single request that contains all selected assets. { "targets": [ { "TargetId": 34181, "TargetIdentifier": "xEYMBs3UTo6ZDN_Xp8ykgg", "context": {} }, { "TargetId": 34253, "TargetIdentifier": "o-SNrVDwTRWIzcHG0cu8VA", "context": {} }, { "TargetId": 34127, "TargetIdentifier": "hqFQTkdmQGeHDIJDzBnHRw", "context": {} } ] } Notice that not only the number of HTTP requests changes, also the JSON contract itself changes. Instead of receiving a single asset, your service receives a collection of assets and becomes responsible for processing them. That distinction may appear subtle, but architecturally it is significant. An execution strategy, not a performance setting One misconception I regularly encounter is that Bulk should simply be enabled for better performance. While it often reduces the number of HTTP requests, that's not the reason why the option exists. The real question is much simpler: Where should the iteration happen? Should Content Hub invoke your service once for every asset, or should your service receive a collection of assets and decide how to process them? That decision has consequences far beyond the transport layer. It affects how you design your queues, how you prioritise work, how you handle failures, and ultimately how your application scales. Consider an AI enrichment service that supports both scheduled processing and urgent requests. Every night, editors submit hundreds of assets for transcription or metadata generation. Those requests are ideal candidates for Bulk processing because the service can optimise throughput and process the work whenever capacity becomes available. Now imagine an editor who needs a single asset enriched immediately before publishing. That request shouldn't wait behind hundreds of scheduled jobs. Instead, it can use a separate Non-Bulk action that places the work directly into a priority lane. Although both actions call the same service, they represent two completely different execution strategies. This is why the choice between Bulk and Non-Bulk should always be driven by functional requirements rather than performance alone. When Content Hub is the caller There's another architectural principle worth mentioning. It can be tempting to assume that because Content Hub initiates the request, the data it sends is always ready to process. In practice, your service should never rely on that assumption. Your endpoint should validate whether an asset is still available, whether it is in the correct lifecycle state, and whether processing it actually makes sense. Likewise, if processing the same asset twice would cause problems, your implementation should be resilient enough to handle duplicate requests gracefully. These responsibilities belong to the service, not to Content Hub. The platform is responsible for invoking your endpoint. Your responsibility is to build an endpoint that behaves correctly under all circumstances. Conclusion The Bulk toggle may be one of the smallest configuration options in Sitecore Content Hub, but it represents an important architectural decision. It determines who is responsible for iterating over assets, influences how your application handles prioritisation and scalability, and shapes the overall execution model of your integration. The next time you create an External Mass Action, don't ask yourself whether Bulk is faster. Instead, ask a different question: Where should the iteration happen? More often than not, the answer to that question will also tell you which option to choose.
Read post →Ronald van der Plas · Jul 30, 2026
Content Insights Tip #82 | Monitor your GitHub Copilot AI credit usage
GitHub Copilot has become an important part of our development workflow in Visual Studio Code. What started as inline code completion has developed into a capable coding agent that can analyse repositories, edit multiple files and execute increasingly complex development tasks. Like many digital services, AI tools were initially priced aggressively to encourage rapid adoption. Now that developers and organisations are becoming increasingly dependent on them, prices and usage limits are gradually increasing. Running these models remains expensive, so it is unlikely that AI usage will become cheaper or less restricted in the near future. That makes it more important than ever to create awareness around token consumption and reduce unnecessary usage. Before we can prevent tokens from being wasted, we first need insight into how many credits we are consuming and which activities are responsible. For developers using GitHub Copilot Business or Enterprise through their employer, reaching a limit will not usually result in a personal bill. It can, however, prevent you from continuing to use Copilot Chat, Agent Mode and other AI-powered features until additional credits become available or the allowance resets. Fortunately, GitHub provides several ways to monitor your usage. Check your Copilot usage in GitHub Open your personal GitHub settings and navigate to: Profile picture → Settings → Copilot → Features. You can also open the page directly: github.com/settings/copilot/features. The Usage section shows how much of your included AI Credit allowance has already been consumed. This is the official usage information connected to your account, so it should be your main reference when checking how close you are to your limit. For professional Copilot plans, inline suggestions and Next Edit Suggestions do not consume AI Credits. The relevant usage comes primarily from features such as Copilot Chat, Agent Mode, Copilot CLI and other model-driven interactions. Check your usage from Visual Studio Code You can also view your current usage without leaving Visual Studio Code. Click the Copilot icon in the status bar to see the limits applying to your account and when they reset. This is useful after a long Agent Mode session or when using more capable reasoning models. A single task may involve several model calls, large amounts of repository context and multiple sub-agents behind the scenes. The built-in indicator tells you how much usage remains, but it does not necessarily explain which sessions consumed those credits. Understand where your credits are going For more details, you can install the third-party Copilot Cost & Token Tracker extension for Visual Studio Code. The extension reads the Copilot agent logs stored locally by Visual Studio Code and creates a dashboard showing: Estimated AI Credits per session Usage broken down by model Input, output and cached tokens Main-agent and sub-agent calls Aggregated usage over time This can help identify why one session consumed considerably more than another. Perhaps Copilot repeatedly loaded a large amount of context. Maybe it used a powerful model for a relatively simple task, created several sub-agents or kept retrying an unsuccessful approach. The extension should be treated as a diagnostic tool rather than an official billing overview. It only sees the sessions available in your local Visual Studio Code logs and calculates its results using its own pricing information. A useful distinction is: GitHub shows how close you are to your actual limit. The extension helps explain which local sessions consumed your credits. As with any third-party extension used in a professional environment, check whether your organisation permits its installation. My thoughts Usage-based pricing is understandable. A short coding question and an autonomous agent working across an entire repository clearly do not require the same amount of computing power. However, we are paying for the tokens consumed, not for the value of the result. An agent can use a large amount of context, call several tools and generate thousands of tokens, only to produce a solution that does not compile or completely misunderstands the problem. Those tokens cost exactly the same as tokens that resulted in a perfect solution. I would like to have the option to rate the value of an AI response. Was it useful, partly useful or completely useless? When a solution is terrible, should we really pay the full price for the tokens used to create it? In practice, this would be difficult to implement fairly. The model provider has already incurred the infrastructure costs, the quality of an answer is subjective, and a refund system would be easy to abuse. LLM providers also cannot guarantee that every answer will be correct. I therefore do not expect a thumbs-down button to return our AI Credits anytime soon. Still, it is an interesting thought. AI providers already ask us to rate their answers because that feedback helps improve their models. Perhaps future usage dashboards should not only show how many tokens we consumed, but also help us understand whether those tokens produced something valuable.
Read post →Ronald van der Plas · Jul 22, 2026
Content Insights Tip #81 | Connect Your AI Coding Agent to Vercel with MCP
Vercel has released an official MCP server that connects supported AI tools directly to your Vercel projects. It is currently available in beta on all Vercel plans and supports tools including Claude Code, Codex CLI, Cursor, ChatGPT and VS Code with GitHub Copilot. What does Vercel MCP do? MCP stands for Model Context Protocol. It allows AI assistants to connect to external tools and data sources. Vercel MCP uses OAuth to grant your AI assistant access to the Vercel projects associated with your account. Once connected, your agent can: Search the Vercel documentation List and inspect projects View recent deployments Retrieve failed build logs Search runtime logs Investigate production and preview errors The runtime log tools can filter by environment, log level, status code, source and time range. You could, for example, ask: Find the latest failed deployment for this project and analyse the build logs. Or: Show me the production errors from the last hour and identify the most likely cause. How is this different from the Vercel Plugin? The Vercel Plugin and Vercel MCP complement each other, but they solve different parts of the same problem. The plugin mainly improves what your AI coding agent knows about Vercel. It adds platform-specific context, skills, specialist agents and commands for areas such as Next.js, deployments, caching, performance and environment variables. Vercel MCP goes a step further by connecting the agent to your actual Vercel environment. Instead of only understanding how the platform works, the agent can retrieve information about your projects, deployments and logs. In other words, the plugin helps your agent understand Vercel, while MCP enables it to work with the Vercel environment you use. For SitecoreAI projects with a Next.js frontend, combining both could be particularly useful. The plugin helps the agent understand the frontend platform, while MCP provides information about what is happening after that frontend has been deployed. Connecting your coding agent Vercel provides a general installer that detects supported AI coding tools: npx add-mcp https://mcp.vercel.com For Codex CLI, you can add it directly: codex mcp add vercel --url https://mcp.vercel.com The client will open an OAuth flow in your browser, where you authorise access to your Vercel account. Keep access in mind The connected AI system receives the same level of Vercel access as the user who authorises it. That makes the authentication step more than a simple technical formality, because the permissions granted to the agent determine what it can inspect and potentially change. For that reason, Vercel recommends keeping human confirmation enabled for tool execution. This allows the developer to review an action before the agent carries it out, which is especially important when working with production environments. A sensible way to begin is by using Vercel MCP for read-oriented tasks. Let the agent investigate failed deployments, analyse build and runtime logs, inspect project configuration and search the Vercel documentation. These scenarios already provide considerable value without immediately giving the agent responsibility for making changes. My thoughts Vercel MCP looks like a useful addition to the AI-assisted development workflow. Giving an agent direct access to deployment information, runtime logs and project configuration removes a great deal of manual context gathering. It allows the assistant to work with what is actually happening in your Vercel environment, rather than relying only on the code and information you provide manually. At the same time, that convenience makes it important to think carefully about access. An agent can only be as safe as the permissions it has been given. So human confirmation should remain enabled, particularly when production environments are involved. When security is a primary concern, it may be worth authorising the MCP connection through a dedicated Vercel account with fewer privileges. That account could be limited to the projects and actions the agent genuinely needs. This follows the principle of least privilege and reduces the potential impact if the tooling behaves unexpectedly or is influenced by untrusted input. Vercel MCP has the potential to become a valuable part of the development toolkit, but it should be introduced with the same care as any other integration that receives access to your environments. Source: Use Vercel's MCP server
Read post →