Neuralwatt’s co-founders: CEO Chad Gibson, left, and Scott Chamberlin, chief technology officer. (LinkedIn Photos)
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.
The Neuralwatt dashboard with carbon emissions displayed. (Neuralwatt Image)
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)5 = 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:
where is the current state of the workflow and 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%.
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!
Log in
