Neuralwatt, a Seattle-based startup launched by two Microsoft veterans, has released what appears to be the first tool for calculating, in real time, the carbon emissions of individual AI requests — everything from asking a bot to edit a high school essay to deploying an autonomous AI agent for a complex coding assignment.

The co-founders hope the data will unlock more planet-friendly operations and give AI developers something to feel optimistic about, even as public anxiety grows over data centers’ energy, water and utility bill impacts.

There’s a lot of worry that AI requires “a data center in every neighborhood,” said Chad Gibson, Neuralwatt’s co-founder and CEO. While new facilities will be built, he added, existing ones and their energy sources could be used much more efficiently.

The startup estimates that if AI growth continues at its current pace, and with the current approach to energy use, the technology could generate 24 million to 44 million metric tons of carbon dioxide per year by 2030 — volumes equivalent to adding millions of gas-powered cars to the road.

Neuralwatt aims to help avoid that outcome. The carbon intensity of grid power varies throughout the day and across regions, depending on its source and how much demand there is. The company’s platform captures a carbon intensity snapshot each time an AI function — or “inference,” in tech jargon — runs, giving customers insight into the emissions tied to that specific task.

Just as cloud users have come to expect emissions data linked to their usage, Gibson said companies running AI workloads will soon expect the same. “We believe that is going to be the future.”

The data is increasingly important for companies that will need to comply with Europe’s Corporate Sustainability Reporting Directive and for other organizations disclosing the full range of their carbon emissions.

Neuralwatt offers three products, all of which integrate the carbon-impact metrics: Neuralwatt Cloud, which provides AI services from leased data centers with energy-based pricing; Neuralwatt Deploy, which identifies underused data centers for AI customers to tap into; and Neuralwatt Optimize, which lets data center managers subtly adjust operations in real time to improve efficiency.

Its customers include Parasail, an AI inference startup; ZutaCore, which makes chip-cooling technology; and Crusoe Cloud.

Gibson launched Neuralwatt in December 2024 with Scott Chamberlin, who serves as chief technologist. Both spent more than two decades at Microsoft, with Gibson departing in 2019 and Chamberlin in 2022. The two overlapped while working on the company’s now-defunct Zune media player.

After leaving Microsoft, Gibson took an entrepreneurial path, becoming a limited partner at Seattle investment firm Flying Fish and an angel investor with Alliance of Angels. Chamberlin, whose final Microsoft role was sustainability lead for Windows, moved to Intel to lead its green software strategy.

Neuralwatt joined the Climate Collective accelerator in 2025 and received a grant to support its work, then was selected this year for the Plug and Play accelerator. The startup is also part of the Nvidia Inception and Microsoft for Startups programs, which provide access to hardware and services.

Last summer, the company received an undisclosed pre-seed investment from Powerhouse Ventures, Avesta Fund and Remarkable Ventures. The team has four employees and three advisors.

Many AI agent systems become economically unsustainable long before they become technically impressive. Teams usually focus on model choice, prompt design, tool calling, and orchestration. Those things matter, but they are only part of the system setup. The deeper issue is that coding agents, such as Claude Code, Codex, and Jules, make agent workflows easier to generate. But when implementation is abstracted away, the underlying mechanics become harder to see. Bad engineering used to produce slow code. Now it produces expensive systems that also happen to be slow.

When we design agent systems, we still need to remember that the costs scale nonlinearly. A single user request rarely triggers a single model call. It expands into routing, retrieval, reasoning, reflection, guardrail checks, tool calls, and synthesis. Each step may repeat shared context, reload state, recompute a planner decision, or retry a failed path. What looks like an intelligent workflow can therefore behave like a recursive, stateful computation with overlapping subproblems. If that sounds like backtracking, dynamic programming, and memoization to you, you’re right.

We already know how to optimize systems like this. The problem is that coding agents make agent systems easier to generate, but not necessarily easier to optimize. Unless we recognize the underlying mechanics, we may never ask our coding agents to apply the optimization patterns that keep our systems viable.

Old problems wearing new clothes

When we use coding agents to generate agent architectures, it’s tempting to stop at “the trace looks reasonable.” The tool can generate routers, retrievers, planners, evaluators, guardrails, tool interfaces, and synthesis steps. It may also know about caching, pruning, memoization, and state modeling. But it won’t necessarily implement those patterns unless you ask for these optimization layers explicitly.

Even if you work with agent instructions, unless your SKILL.md, AGENTS.md, or project instructions include constraints around repeated context, memoization, cache invalidation, pruning, and cost per request, your resulting agent system may be functionally correct and economically wasteful at the same time. That’s the tricky part: The code can pass review, the unit tests can pass, and the architecture can look reasonable. The invoice is where the hidden computation finally shows up.

It’s easy to give too much agency to tools like Claude Code. When a coding agent reasons in language, calls tools, reflects, and produces fluent text or code, it can feel like a knowledgeable coworker. At the interface level, that impression is understandable. These tools help teams generate more code, move faster, and become more productive. Still, this doesn’t remove the need for engineering craft underneath. Someone still has to recognize repeated context, recomputed planner decisions, correlated retries, unpruned branches, and state that can’t be reused. The coding agent can implement the system, but the engineer still has to understand what kind of system should be implemented. This is where old computer science returns, not as theory but as the optimization layer our agent systems need in production.

The cost multiplier, repeated-work problems, and backtracking

The cost multiplier often shows up first as latency. The user doesn’t see the router, the retries, the reflection loop, or the tool calls. They only see that the agent is taking too long. From the outside, the system looks stuck or broken. From the inside, it may simply be repeating work.

This is one of the uncomfortable differences between traditional software and agent systems. In a conventional application, a failed operation often throws an error, times out, or leaves a trace that is easy to inspect. In an agent workflow, failure can look like effort to improve reliability. Take the weakest step in your agent workflow. If it succeeds 60% of the time, and you try to push it close to 99% reliability through retries, you need 5 retries:

1 − (1 − 0.60)⁵ = 0.98976

This math assumes each retry is a roll of fair dice. LLMs aren’t dice. Whether you’re using greedy decoding or probabilistic sampling, the model is still drawing from the same underlying distribution shaped by your prompt. If the first “thought” is a hallucination or logic error, bumping the temperature won’t fix the underlying state. You aren’t buying independent trials; you’re just sampling different paths through the same flawed map and state.

This is where the old algorithmic framing matters. In a backtracking problem, you don’t keep walking down the same failed branch and call it progress. You return to the last valid state, mark the failed path, and use the failure as information for the next choice. The point isn’t just to try again. The point is to try again under a changed state.

Agent workflows need the same discipline. A retry shouldn’t mean “run it again and hope.” It should give the model structured feedback about why the previous attempt failed: which constraint failed, which tool result was invalid, which schema didn’t validate, which assumption was unsupported, or which branch added nothing. The next attempt should then change something meaningful: the prompt, the tool choice, the retrieved evidence, the validation constraint, or the planner state.

Memoization, pruning, and dynamic programming

Prompt caching is usually the first optimization. If every step repeats the same system prompt, tool definitions, schema constraints, examples, and policy rules, then caching the shared prefix is an obvious win. It reduces the cost of repeated context. But prompt caching only recognizes that text repeats. It doesn’t notice that decisions repeat.

In many agent systems, the expensive unit isn’t only text. It’s the repeated decision. If the same or equivalent state appears again, paying the model to rediscover the same action is unnecessary. That is what memoization does: It turns repeated computation into lookup. In classical algorithms, the repeated computation might be a recursive subproblem. In an agent system, it might be a planner decision over the same task, facts, tools, and constraints. The planner can be treated as a function over state:

$$^πLLM(S_t) \rightarrow a_{t+1}$$

where $S_t$ is the current state of the workflow and $a_{t+1}$ is the next action. Without memoization, this function is evaluated again and again through an LLM call. With memoization, the system first checks whether it has seen the same or equivalent state before. If you want a deeper walkthrough of how to use memoization, I cover it in AI Agents: The Definitive Guide.

But memoization only helps once the system knows which states are worth revisiting. Pruning handles the other side of the problem: branches that shouldn’t be explored further. However, don’t limit pruning to KV cache pruning or speculative decoding. Use it also when a tool repeatedly returns no new information. Your next LLM call shouldn’t be a slightly reworded version of the same query. If a reflection loop keeps producing stylistic changes without improving correctness, the loop should stop. If a search path violates a constraint or depends on an unsupported assumption, it should be marked as unproductive and removed from the active search space.

Dynamic programming becomes relevant when different branches of the workflow solve overlapping subproblems. A research agent may ask similar questions across several documents. A coding agent may inspect the same dependency chain from different entry points. A business analysis agent may compute the same metric for several report sections. If every branch solves these subproblems from scratch, the system pays repeatedly for work it has already done. Table 1 shows examples of how these patterns map to AI agent systems.

Table 1. Classical optimization patterns applied to AI agent systems 

Optimization	The “old” CS way	The “agent” way
Memoization	Store results of expensive function calls.	Cache decisions. If the agent saw this state before, don’t ask it to reason again.
Pruning	Cut off search paths in a tree that won’t lead to a solution.	Kill a reflection loop when the critique stops yielding structural improvements.
Dynamic programming	Break problems into overlapping subproblems.	Share codebase analysis across multiple specialized agents instead of rereading files.

This isn’t nostalgia. These patterns mitigate the cost structure of agent systems. Memoization reduces repeated decisions. Pruning reduces repeated failure. Dynamic programming reduces repeated subproblem solving. Together, they form the optimization layer many agent architectures are missing in production.

Where to start: Optimization follows topology

The patterns above aren’t a checklist you apply uniformly. Each multi-agent topology, whether centralized, decentralized, independent, or hybrid, distributes communication and coordination differently, which directly affects overhead, latency, and failure propagation. The optimization layer has to follow.

Centralized
A single orchestrator decides, delegates, and aggregates. The expensive unit is the orchestrator’s decision, repeated across similar inputs. Memoize the planner first.

Decentralized
Agents coordinate peer-to-peer, exchanging messages without a central authority. The cost moves into the communication itself: redundant exchanges, restated context, agents reasoning over the same shared state from different angles. Prompt caching on the shared context is the first win, followed by pruning exchanges that no longer add information.

Independent/swarms
Lightweight agents fan out without coordinating. Cheap individually, expensive in aggregate. If three of your ten agents ask semantically equivalent questions, you pay three times for the same answer. Memoization and pruning aren’t optimizations here; they’re load-bearing.

Hybrid
The repeated work shows up at two scales: within a cluster (overlapping subproblems among peers) and across clusters (the coordinator rediscovering the same routing decision). Use dynamic programming on shared subproblems inside the cluster, memoization on the coordinator’s decisions across them.

The optimization layer isn’t a generic discipline you bolt on. It’s a function of the shape of the implementation. Coding agents made it easy to generate the shape without seeing it. The craft is in seeing it anyway.

Analyze MSIX packages with Advanced Installer to detect missing Execution Aliases, File Type Associations, environment variables, and other manifest declarations.

In the ever-evolving world of artificial intelligence, knowing the right tools and tricks can set you miles apart from the rest. Slash commands in Claude are one of those underutilized features that hold immense power. Whether you’re a seasoned pro or a newcomer, these commands can enhance your productivity and the quality of your AI interactions.

Here’s a deep dive into the six essential slash commands in Claude, plus a bonus custom command that’s been a personal game-changer, boosting my outputs by a remarkable 43%.

Based on content from Tristen O’Brien

Understanding Slash Commands

Slash commands are essentially shortcuts that streamline your interactions with Claude. Instead of laboriously crafting detailed requests each time, you can simply type a forward slash, followed by a command, and Claude will execute your directive efficiently. These commands can be accessed via the terminal or the desktop app — it’s as simple as typing a slash.

1. /clear

The /clear command provides a fresh start by erasing the current context and starting a new conversation. Given that Claude retains information in its context window, this command is invaluable when shifting between different tasks, ensuring no previous context muddies your new project.

2. /btw

The /btw or “by the way” command is perfect for those moments when inspiration strikes in the middle of another task. It allows you to interject with questions or additional information without interrupting the original task flow. Imagine it as a sidebar chat where Claude attends to your queries while remaining focused on the main task.

3. /statusline

Do you want to keep a constant eye on the technical specifics of your session? Use /statusline. Customize the bottom status bar of Claude with details such as the model in use, memory usage, real-time costs, or the number of running agents. Set it up once, and you’re good to go.

4. /plan

When precision is key, /plan is your best friend. Before jumping into a task, this command prompts Claude to research, lay out a plan, and seek your approval. Not only does it allow you to refine the directives, but it also prevents wasted effort on wrong assumptions.

5. /rewind and /resume

Mistakes happen, but with /rewind, they don’t have to be permanent. Roll back to any previous checkpoint during your current task. Should you wish to revisit an entirely different past conversation, /resume helps you jump back seamlessly.

6. /goal

Often, setting crystal-clear objectives can mean the difference between success and frustration. The /goal command encourages Claude to persistently work towards a defined outcome, integrating a secondary checker for successful completion. It’s a safety net ensuring your task is truly complete.

Beyond the Basics: Customizing Your Commands

Creating a custom command can personalize Claude to your unique workflow. My custom command, /scope, has been transformative. It guides Claude to ask clarifying questions, develop a comprehensive task plan, and confirm the plan with me before proceeding. This structured approach has significantly enhanced output quality.

To implement this, open Claude Code, initiate the command /scope, and paste the following instructions:

When I run this command and give you a task, do NOT start working right away. First, ask me at least 5 clarifying questions about the goal, the scope, any constraints, and exactly how I want it done. Wait for my answers. Once I respond, enter plan mode: research the relevant code and context, then lay out a complete, step-by-step plan for how you'll do it. Show me that plan and wait for my explicit approval. Do not write or change anything until I say go. Only after I approve the plan, build it.

Bonus Commands

For a little fun and education, try /radio to tune into Claude’s own YouTube radio station or /powerup for interactive lessons on Claude’s capabilities.

These slash commands are just the iceberg’s tip — dive deeper, explore, and customize to find what works best for you. Whether using pre-existing commands or building your own, Claude is a versatile tool, ready to be shaped to your needs.

If you’ve found this guide helpful, consider sharing it with your network and subscribe to stay updated on the latest in AI!

Are you writing for a younger audience? Use our quick start guide to writing for children to help you write your stories.

Read the other posts in our Quick Start series:

1. A Quick Start Guide To Creating Characters
2. A Quick Start Guide To Writing Fantasy
3. A Quick Start Guide For Beating Writer’s Block
4. A Quick Start Guide To Writing For Children
5. A Quick Start Guide To Writing YA Fiction
6. A Quick Start Guide To Writing A Memoir
7. A Quick Start Guide To Writing Descriptions
8. A Quick Start Guide To Writing Romance
9. A Quick Start Guide To Writing Science Fiction
10. A Quick Start Guide To Foreshadowing
11. A Quick Start Guide To Writing An Inciting Incident
12. A Quick Start Guide To Writing Dialogue
13. A Quick Start Guide To Writing Crime Fiction
14. A Quick Start Guide To Writing Emotions
15. A Quick Start Guide To Writing Revenge
16. A Quick Start Guide To Writing First & Last Lines

This post is about writing for children.

Many writers are under the misconception that is easier to write for children than it is to write for adults. This isn’t true. Writing for children is fun, probably the most fun you can have while you are writing, but it is not easy. There is a lot to consider when you want to keep the kiddos engaged.

[TOP TIP: If you want to learn how to write for children, sign up for kids etc. online]

Let’s Take A Look

Children’s literature is a huge category with many subdivisions. To know what you have to do or what is required of you, you have to know who you are writing for.

Everything depends on the age of the reader and there is overlap and wiggle room, but as a beginner writer you’ll have to follow industry guidelines as far as possible, but when you are famous you can get away with more.

A Quick Start Guide To Writing For Children

Notes:

1. I have excluded non-fiction and board books.
2. You’ll notice that the age groups overlap. This depends on the child and how well they can read.
3. I’ve used the term ‘appropriate for children’, but of course that is very subjective. Captain Underpants and Harry Potter are frequently challenged titles.
4. Children read for the same reasons that adults do. They also read for fun and entertainment. Stop trying to preach to them. Add a theme or a lesson but have fun with it. Teach them without wagging your finger.
5. Do your research. Find out exactly what an agent or publisher wants and work to their guidelines.

Creating Characters For Children’s Books

If you want help with this, please read these posts:

1. Everything You Need To Know About Creating Characters For Children’s Books
2. How To Develop Strong Characters Children Will Relate To

The Last Word

Writing for children is a challenge and it is incredibly rewarding. It is really about letting your imagination run wild within some very strict confines. If you want to learn how to write for children, sign up for kids etc. online.

by Mia Botha

If you enjoyed Mia’s post, you will love: 

1. 15 Inspiring Reasons To Start Writing Poetry
2. Worldbuilding: The Ultimate Setting Checklist For Writers
3. Show Don’t Tell: 5 Simple Techniques Every Writer Should Know
4. How To Show & Not Tell In Short Stories
5. A Complete Guide To Writing Prompts & Daily Writing Practice
6. How To Write What You Love
7. 4 Point Of View Choices For Writers
8. Where Does Conflict Come From In Fiction?
9. Writing Competitions To Inspire You
10. How To Write Epic Beginnings

Top Tip: Sign up for our free daily writing links.

The post A Quick Start Guide To Writing For Children appeared first on Writers Write.

Today, we’re excited to announce the general availability of the Azure Cosmos DB built-in connector for Azure Logic Apps Standard. This connector gives you a native, high-performance way to integrate Azure Cosmos DB into your Standard logic app workflows, with better throughput, lower latency, and richer functionality than the managed connector. That includes real-time change feed processing, bulk operations, and Microsoft Entra ID authentication.

If you’ve been building integration workflows that read, write, or react to data in Azure Cosmos DB, this GA release means you can do all of that with production-grade reliability, enterprise security, and the performance benefits of a connector that runs in-process alongside your logic app runtime.

Azure Logic Apps offers two types of connectors: managed connectors that run in shared, multitenant infrastructure, and built-in connectors that run directly in the single-tenant Logic Apps runtime. Built-in connectors have some significant advantages:

• Lower latency. Operations execute in-process, so you eliminate the network hop to an external connector service.

• Higher throughput. No shared connector throttling. Performance scales with your Logic Apps plan.

• Richer functionality. You get access to capabilities like the change feed trigger that simply aren’t available in the managed connector.

• Better cost efficiency. Built-in connectors run on the Logic Apps compute and are not billed separately, which often means lower costs at scale.

The Azure Cosmos DB built-in connector brings all of these benefits to your Azure Cosmos DB integration scenarios.

The built-in trigger, When an item is created or modified, uses the Azure Cosmos DB change feed to fire your workflow whenever documents are created or updated in a monitored container. This is the same battle-tested change feed pattern used in Azure Functions and the change feed processor, now available directly in your Logic Apps workflow.

Use it to:

• Sync data to downstream systems in real time
• Trigger notifications when orders, profiles, or inventory items change
• Feed AI pipelines with fresh data as it arrives
• Build event-driven architectures without custom code

The trigger manages checkpointing for you via a lease container. You’ll need to either point it at an existing lease container, or set Create Lease Container to true so the connector creates one automatically. (Note that createLeaseCollectionIfNotExists defaults to false, so if you skip this step the trigger won’t fire.) Once that’s in place, you point it at your database and monitored container, and it handles the rest.

The connector provides a complete set of document operations:

Action	Description
Create or update item	Create a new item or replace an existing one (upsert supported)
Create or update many items in bulk	Batch upsert multiple items in a single operation
Read an item	Point-read a document by ID and partition key
Query items	Run Azure Cosmos DB SQL queries with full parameterization
Patch an item	Apply partial updates without replacing the entire document
Delete an item	Remove a document by ID and partition key

Each operation returns detailed metadata including request charges, ETags for optimistic concurrency, session tokens for consistency, and activity IDs for diagnostics.

The Create or update many items in bulk action is purpose-built for high-volume data ingestion. Whether you’re loading data from an external system, processing batch files, or hydrating a container as part of an AI pipeline, bulk operations let you write many items in a single action with optimized throughput.

The Patch an item action lets you do partial document updates. You can modify specific properties without reading and replacing the full document. This is great for workflows that update status fields, append to arrays, or increment counters without the overhead of a full read-modify-write cycle.

Security-conscious organizations can now authenticate to Azure Cosmos DB using Microsoft Entra ID with managed identities, meaning you no longer need to rely on access keys if you don’t want to. The connector still fully supports connection-string (account key) authentication, but Entra ID gives you a passwordless option that aligns with Azure’s zero-trust security model:

• Managed Identity support. Authenticate using your Logic App’s system-assigned or user-assigned managed identity.

• Fine-grained RBAC. Assign the Cosmos DB Built-in Data Contributor or Cosmos DB Built-in Data Reader roles for least-privilege access.

• No secrets to rotate. If you go the Entra ID route, you eliminate the operational overhead of managing and rotating access keys.

This is especially important for enterprise scenarios where security policies prohibit storing connection strings or keys, and for organizations that are adopting passwordless authentication across their Azure estate.

 Learn more about Microsoft Entra ID authentication for the Azure Cosmos DB connector

The combination of the change feed trigger, bulk operations, and query capabilities makes this connector a natural fit for AI-powered workflows.

Azure Logic Apps recently introduced a Knowledge Base-as-a-Service (KBaaS) capability that uses Azure Cosmos DB as its underlying data and vector store. With KBaaS, you can upload unstructured documents (PDFs, Word files, spreadsheets, and more) and the service automatically parses, chunks, summarizes, and vectorizes the content, storing everything in Cosmos DB containers with the right indexing policies already configured.

When an agent loop in your agentic workflow queries the knowledge base, the service rewrites the query if needed, generates a vector embedding, performs a semantic search against Cosmos DB, and returns the most relevant chunks to your LLM for response generation. It’s a fully managed RAG pipeline that runs entirely within your Logic Apps Standard environment, with no custom code required.

This is a great example of what the Cosmos DB built-in connector enables at a platform level: deep, native integration between Logic Apps and Cosmos DB that powers higher-level AI capabilities without you having to wire up the plumbing yourself.

You can also build your own custom embedding pipelines that trigger when new documents land in Cosmos DB. Use the change feed trigger to detect new items, call an embedding model (via the Azure OpenAI connector or an HTTP action), and write the vector back to the same or a different container. All of this happens within a single Logic Apps workflow. No custom code, no separate infrastructure to manage.

For custom Retrieval-Augmented Generation (RAG) applications where you need more control than KBaaS provides, you can use Logic Apps Standard workflows to orchestrate the full data preparation pipeline:

• Ingest documents from any source using Logic Apps’ 400+ connectors
• Transform content (chunk, clean, enrich) using inline code or external services
• Embed text using Azure OpenAI or other model endpoints
• Store documents with vectors in Azure Cosmos DB using the bulk upsert action

This pattern pairs naturally with Azure Cosmos DB’s vector search capabilities and integrated embeddings for end-to-end AI application scenarios.

You can also combine the change feed trigger with AI services to build workflows that react intelligently to data changes:

• A new support ticket comes in, gets summarized by an LLM, and is routed to the right team
• A product review arrives, gets sentiment analysis, and negative reviews are flagged for follow-up
• A customer profile is updated, recommendations are re-computed, and the personalization cache is refreshed

The connector exposes session tokens as both an input and output on each operation, which gives you session-level consistency guarantees. In practice, this means you can read your own writes within a workflow by passing the session token returned from a write action into the next read or query action. Wire up that token, and you’re guaranteed to see your update. This is critical for workflows where later operations depend on earlier results within the same run.

 Azure Cosmos DB built-in connector reference

 Connect to Azure Cosmos DB from workflows in Azure Logic Apps

 Create Knowledge Bases for Agentic Workflows

 Azure Cosmos DB change feed

 Microsoft Entra ID authentication for the connector

Azure Cosmos DB is a fully managed and serverless NoSQL and vector database for modern app development, including AI applications. With its SLA-backed speed and availability as well as instant dynamic scalability, it is ideal for real-time NoSQL and MongoDB applications that require high performance and distributed computing over massive volumes of NoSQL and vector data.

To stay in the loop on Azure Cosmos DB updates, follow us on X, YouTube, and LinkedIn. Join the discussion with other developers on the #nosql channel on the Microsoft Open Source Discord.

The post Announcing General Availability of the Azure Cosmos DB Built-in Connector for Logic Apps Standard appeared first on Azure Cosmos DB Blog.