DEV Community: Prasad Rane

A $1 AWS Budget Didn't Stop a $106 Claude Code Bill. Here's What Does

Prasad Rane — Mon, 12 Oct 2026 15:32:04 +0000

I set a $1 AWS budget before letting Claude Code loose on a hobby project. Less than 24 hours later I had a $106.26 charge.

My mistake was treating the budget as a limit. It is an alert, and a slow one. This post covers what actually happened, why an agent can burn money this fast, and the layered setup I use now. I'll also be clear about what I have not verified, because I only have one data point: my own bill.

What happened

The setup was ordinary. Claude Code pointed at Amazon Bedrock, a hobby project, and a $1 monthly cost budget with an email alert. I assumed $1 meant I would be stopped at roughly $1.

I wasn't. By the time anything told me I was over, I was over by two orders of magnitude.

Two separate things went wrong, and they compound.

1. The budget could not have stopped me

AWS Budgets does not sit in the request path. It reads billing data and compares it to your threshold. The AWS documentation is direct about the cadence: budget information is updated up to three times a day, typically 8 to 12 hours after the previous update. It also warns that you might incur costs that exceed your threshold before Budgets can notify you.

So a budget is a smoke detector, not a circuit breaker. If something spends $100 in the gap between two updates, the first signal arrives after the money is gone.

2. The agent was spending much faster than I expected

I did not hit an infinite loop, as far as I can tell. What I saw was the agent re-verifying its own work again and again. That alone is a lot of requests. The part I underestimated is what each request costs.

Claude Code sends the whole conversation with every request, and every tool use produces another request carrying the accumulated tool results. The cost docs describe the same thing: a long session draws on the full history on each turn, even for a one-line follow-up.

Many requests multiplied by a large context each time is a bill that grows quickly while the agent looks perfectly productive.

Figure 1: Agent spend accrues continuously, while budget data arrives in coarse, delayed updates.

A rough model of the cost

I don't have a per-request breakdown of my bill, so this is an illustration, not a measurement.

Suppose an agent session has a 100k token context and makes 100 requests while it checks its own work. That is 10 million input tokens. At a hypothetical $3 per million input tokens, that is $30 if every request pays full price to re-read the context.

With prompt caching working, those repeated reads are billed at the cached rate, which is a fraction of base input price on Anthropic's published pricing (check the current Bedrock rates for your model). The same 10 million tokens could cost a fraction of that $30.

Two details make this worse in practice:

Cache lifetime depends on how you connect. The Claude Code docs say the cache lasts an hour on a subscription, and five minutes by default on an API key or cloud provider. A pause longer than the lifetime means the next request reprocesses the full context.
Everything that sends a request carries context. Scheduled tasks, subagents, and compaction each make their own requests. /compact itself reads the whole conversation it summarizes, so compacting a huge context is a large request.

Figure 2: Unguarded, the only brake is a delayed email. Guarded, a budget action and cheaper requests bound the damage.

What I changed

Three changes, in order of how much I trust them.

A budget action that revokes access

AWS Budgets can do more than send email. A budget action can run automatically when a threshold is crossed, and the available actions include applying an IAM policy or an SCP, or targeting specific EC2 or RDS instances.

I use an IAM action that attaches an explicit deny on Bedrock invocation to the role Claude Code uses.

The deny policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyBedrockInvokeOnBudgetBreach",
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:Converse",
        "bedrock:ConverseStream"
      ],
      "Resource": "*"
    }
  ]
}

Create it as a customer managed policy, but do not attach it. The budget action attaches it when the threshold is hit.

The action itself, via the CLI. Treat this as a sketch and check each flag against the current aws budgets create-budget-action reference before running it:

aws budgets create-budget-action \
  --account-id 123456789012 \
  --budget-name agent-hobby-budget \
  --notification-type ACTUAL \
  --action-type APPLY_IAM_POLICY \
  --action-threshold ActionThresholdValue=80,ActionThresholdType=PERCENTAGE \
  --definition 'IamActionDefinition={PolicyArn=arn:aws:iam::123456789012:policy/DenyBedrockInvoke,Roles=[claude-code-role]}' \
  --execution-role-arn arn:aws:iam::123456789012:role/BudgetsActionRole \
  --approval-model AUTOMATIC \
  --subscribers SubscriptionType=EMAIL,Address=you@example.com

Two things to get right:

The execution role. AWS Budgets needs a service role it can assume, with permission to apply IAM policies. AWS publishes an example policy for this ("Allow AWS Budgets to apply IAM policies and SCPs").
Who the deny attaches to. The action only affects the users, groups, or roles you list. If Claude Code runs with different credentials than the ones you listed, the deny does nothing.

An honest limitation: this still runs off the same delayed billing data. It turns an email into an actual cutoff, but it does not remove the lag. That is why the threshold needs to sit well below what you can afford to lose, not at it. My $1 budget was the right idea with no action attached.

I also had to be careful about which costs the budget watched. Model usage on Bedrock may appear under service names that are specific to the model, so a budget filtered to one service name can miss spend. For a hobby account, an account-wide cost budget is simpler. Check Cost Explorer to see how your own usage is grouped before you rely on a filter.

Prompt caching, verified rather than assumed

Prompt caching is on by default in Claude Code, but "on" is not the same as "working". Claude Code shows a prompt cache line in the session block of /usage: request count, share of input tokens served from cache, misses, and whether the cache is currently warm.

That line is the thing to read. A low cache share on a long session means you are paying full price to re-read your codebase every turn, which is exactly the failure mode that hurt me.

Compact and clear on purpose

Run /compact before a session gets large, and give it instructions about what to keep.
Use /clear when you switch to unrelated work. Stale context is paid for on every later request.
Check /usage during long runs instead of after.

None of these is a hard control. They lower the rate. The budget action is what bounds the worst case.

Figure 3: Each layer and its guarantee. Only the IAM deny or a request-path gateway actually stops requests.

Controls compared

Control	Stops requests?	Latency	Notes
Budget email alert	No	Hours	Tells you after the fact
Budget action (IAM deny)	Yes	Hours, tied to billing updates	Bounded worst case, not a tight cap
Prompt caching	No	None	Lowers the rate; verify it with `/usage`
`/compact`, `/clear`, `/usage`	No	None	Habits, and easy to forget
LLM gateway with per-key limits	Yes	Near real time	Sits in the request path; extra infrastructure

On cloud providers, the Claude Code docs say spend controls live in your cloud billing console. For per-user attribution they point to OpenTelemetry export or an LLM gateway. If you run agents for a team, or you want a cap that reacts in seconds instead of hours, a gateway is the control that matches the problem. For a single hobby account, a budget action is a reasonable first step.

Checklist

[ ] A budget exists, and it has an action, not only an email.
[ ] The action's role list matches the credentials Claude Code actually uses.
[ ] The threshold is set well below what you can afford to lose, because billing data lags.
[ ] /usage shows a healthy prompt cache share on a long session.
[ ] Long sessions get /compact; unrelated tasks get /clear.
[ ] You know where your own spend appears in Cost Explorer.

Discussion

I treated the budget as a limit and it cost me. If you run agents against a cloud provider, how are you capping spend: budget actions, a gateway, or watching /usage? I'm especially interested in anyone running a gateway for a single developer, and whether the setup was worth it.

Original post and discussion on LinkedIn.

My AI-assisted coding interview was a lesson in reading unfamiliar code

Prasad Rane — Thu, 01 Oct 2026 04:44:25 +0000

The AI assistant was right there in my coding interview. It wasn’t allowed to help me debug.

Implementation help was restricted too.

I regularly use AI in day-to-day coding, so that took some adjusting. I was given an unfamiliar codebase and asked to fix bugs within a time limit. The immediate challenge was figuring out where to look.

Which files mattered? Where did the relevant behavior start? How did the execution flow through the application? What were the unit tests setting up, and what did they expect?

Those questions became a substantial part of the exercise.

In a codebase you know, you carry around context that’s easy to take for granted. You recognize the entry points. You know which component owns a behavior. You have some sense of where a change belongs and which other parts might be affected.

Even when you don’t know the answer, you usually have a reasonable starting point.

In this interview, I had to build that understanding while the clock was running.

Finding my way through the code

Navigating an unfamiliar repository involves more than opening files and reading methods. The useful part is connecting them.

A method can make sense on its own while leaving important questions unanswered. Who calls it? What assumptions does the caller make? Has the input already been validated or transformed? What happens to the result?

That surrounding context matters when you’re trying to fix a bug. A line can look suspicious in isolation and still be doing exactly what its caller expects.

The time limit made this more noticeable. I had to decide what to investigate next without first understanding the whole project.

For a task like this, the practical goal is to build a small, accurate picture of the behavior involved: where the input comes from, which code handles it, and where the result starts differing from what’s expected.

That’s enough to support an investigation. Reading every file isn’t a prerequisite.

Unit tests were part of understanding the application

The unit tests were another part of the codebase I needed to understand.

A failing assertion gives you somewhere to start, but the assertion alone doesn’t explain the whole situation. The setup matters. So do the inputs, dependencies, and assumptions built into the test.

Reading a test means asking:

What situation is being created?
What behavior does this assertion expect?
How does the implementation produce a different result?
What would explain that difference?

These questions help connect the test to the application’s behavior.

They also make it easier to judge a proposed fix. If I can explain only why a change makes an assertion pass, I may still be missing something about the underlying problem.

The stronger explanation is why the behavior was wrong, how the change addresses its cause, and what evidence supports that conclusion.

What the AI-assisted label didn’t tell me

I wouldn’t use this experience to describe every AI-assisted interview. The tool’s permissions shaped this particular exercise.

In my normal coding workflow, I can ask AI to help investigate a failure or suggest an implementation. Those options weren’t available here.

That made the distinction between having an assistant and having debugging assistance very concrete.

My experience felt like a software engineering exercise in getting oriented: navigating files, tracing execution, understanding tests, and building enough context to reason about a change.

I don’t know the interviewer’s complete scoring rubric. Those were the demands of the task from my side of the screen.

For anyone preparing for a similar interview, I’d ask about the assistant’s capabilities beforehand. “AI is available” leaves several questions open. Can it explain existing code? Suggest changes? Investigate failures? Or is its role more limited?

Knowing those boundaries helps you choose a useful way to practise.

What I’d change about my preparation

After this experience, I’d give unfamiliar repositories more room in my interview preparation.

Working on your own project is useful, but you already know why much of the code exists. You remember the decisions behind it. An unfamiliar project makes you practise reconstructing that context.

I’d start with a small repository that has a working test suite and a reproducible issue. Then:

Establish the starting state. Run the existing tests and see what passes and fails before changing anything.
Read the relevant test. Understand its setup, inputs, and assertions.
Trace the execution path. Follow the behavior involved in the failure across the relevant files.
Form an explanation. Write down what might be causing the problem and check that against the code.
Make a focused change. Run the relevant tests again and check nearby behavior that the change could affect.
Review and explain the fix. Read the diff and describe why the change addresses the cause.

I’d also practise within the tool restrictions expected in the interview. If debugging help is unavailable, it makes sense to rehearse investigating without it.

The explanation at the end matters to me. Could I walk someone through the failure, the cause, and the fix without relying on “the tests passed” as my entire justification?

That’s the skill I’d want the practice to develop.

The part of this interview that stayed with me was having to make sense of code I hadn’t written under time pressure. Before I could make a useful change, I had to understand enough of the system to know what that change should be.

How I Use Coding Agents Without Losing My Mental Models

Prasad Rane — Tue, 22 Sep 2026 19:02:50 +0000

A junior developer recently asked me if he was falling behind because he used AI less than his peers.

I said - "Using AI for everything early in your career buys speed at the cost of mental models".

The cache bugs I wrote by hand years ago taught me why write ordering and TTL expiry interact badly. That lesson only stuck because I watched my own wrong intuition fail in production and had to trace the logs myself. A generated fix skips the failure, and the failure was the teacher.

If you accept AI fixes without understanding the underlying failure, you trade a quick fix today for a system you cannot debug when something unusual breaks.

Here is how I approach this now -

Form a hypothesis first,
use the model to find blind spots, and
ration where AI is allowed to write code.

The Hypothesis-First AI Loop The most common trap with coding agents is pasting an error log into the prompt and asking the model to fix it.

When you do that, you skip the step where you build a mental model of the system. The model returns code that compiles and passes the immediate test, but you do not learn why the failure happened or what secondary effects the change introduces.

A more reliable loop keeps the engineer responsible for the hypothesis while using the model to stress-test assumptions.

Figure 1: The four-step loop for pairing with coding agents.

The Four Steps:

Form a hypothesis: Before opening a prompt, write down what you think is failing and why. Even if your guess is wrong, stating it forces you to model the system in your head.
Ask the model for alternatives: Instead of asking for code, ask the model what other failure modes could produce the same symptom. For example: "I suspect this timeout is caused by database connection pool saturation. What other downstream bottlenecks could produce this error pattern?"
Verify against empirical evidence: Check distributed traces, server logs, and queue metrics to see which explanation fits the data.
Update your understanding: Compare the actual root cause with your original hypothesis. The gap between what you thought happened and what the telemetry showed is where your understanding improves.

2. A Common Failure Mode: Naive Retries and Pool Exhaustion

Here is an example I have seen in production code generated by AI assistants.

A service calling an external API starts seeing intermittent HTTP 504 gateway timeouts. When given the error log, the model suggests adding a retry loop with an increased timeout.

# Anti-pattern: Naive retry loop masking systemic failure
import time
import requests

def call_upstream_service(url: str, payload: dict, max_retries: int = 5):
    # Model suggested increasing timeout from 3s to 10s and retrying 5 times
    timeout = 10.0
    for attempt in range(1, max_retries + 1):
        try:
            response = requests.post(url, json=payload, timeout=timeout)
            response.raise_for_status()
            return response.json()
        except requests.exceptions.RequestException as exc:
            if attempt == max_retries:
                raise RuntimeError(f"Service failed after {max_retries} attempts: {exc}")

            # Predictable exponential backoff without jitter
            sleep_duration = 2 ** attempt
            time.sleep(sleep_duration)

In isolated unit tests, this snippet passes. Under production load, it causes several problems:

Synchronized retry storms: Because the backoff uses fixed powers of two without jitter, hundreds of concurrent callers retry at the exact same intervals, overwhelming the upstream service as it tries to recover.
Socket and thread exhaustion: Increasing the timeout from 3 seconds to 10 seconds means threads hold outbound connections three times longer. Under steady traffic, the web server exhausts its worker pool, and incoming requests queue up until the health check fails.
Latency amplification: Instead of failing fast within 3 seconds so the caller can degrade gracefully, requests hang for up to a minute before failing anyway.

Figure 2: How an unjittered retry loop exhausts connection pools compared to a bounded circuit-breaker pattern.

The model suggested this implementation because retrying with exponential backoff is standard boilerplate in its training data. It has no visibility into your thread pool limits, traffic distribution, or upstream capacity.

3. Resilient Implementation: Bounded Retries and Circuit Breaking

When you know the failure dynamics, you do not let the model pick the strategy. You define the bounds first: maximum latency, randomized jitter, and a circuit breaker that sheds load when the downstream service is down.

Here is a Python implementation that enforces those boundaries:

import random
import time
from dataclasses import dataclass
from enum import Enum
from typing import Callable, Any

class CircuitState(Enum):
    CLOSED = "CLOSED"
    OPEN = "OPEN"
    HALF_OPEN = "HALF_OPEN"

@dataclass(frozen=True)
class ResilienceConfig:
    max_attempts: int = 3
    base_backoff_sec: float = 0.2
    max_backoff_sec: float = 2.0
    failure_threshold: int = 5
    recovery_timeout_sec: float = 15.0

class CircuitBreakerOpenException(Exception):
    """Raised when requests are shed immediately because the circuit is open."""
    pass

class BoundedResilientClient:
    """
    Client that limits retry duration, adds full jitter,
    and protects thread pools through circuit breaking.
    """
    def __init__(self, name: str, config: ResilienceConfig):
        self.name = name
        self.config = config
        self.state = CircuitState.CLOSED
        self.failure_count = 0
        self.last_state_change = time.monotonic()

    def _on_failure(self):
        self.failure_count += 1
        if self.failure_count >= self.config.failure_threshold:
            self.state = CircuitState.OPEN
            self.last_state_change = time.monotonic()

    def _on_success(self):
        self.failure_count = 0
        self.state = CircuitState.CLOSED

    def _compute_backoff_with_jitter(self, attempt: int) -> float:
        ceiling = min(
            self.config.max_backoff_sec,
            self.config.base_backoff_sec * (2 ** (attempt - 1))
        )
        return random.uniform(0, ceiling)

    def execute(self, action: Callable[[], Any]) -> Any:
        now = time.monotonic()

        if self.state == CircuitState.OPEN:
            if now - self.last_state_change > self.config.recovery_timeout_sec:
                self.state = CircuitState.HALF_OPEN
            else:
                # Fail immediately to protect local thread and connection pools
                raise CircuitBreakerOpenException(f"{self.name} circuit is OPEN. Request shed.")

        for attempt in range(1, self.config.max_attempts + 1):
            try:
                result = action()
                self._on_success()
                return result
            except Exception:
                if attempt == self.config.max_attempts or self.state == CircuitState.HALF_OPEN:
                    self._on_failure()
                    raise

                backoff = self._compute_backoff_with_jitter(attempt)
                time.sleep(backoff)

This pattern prevents cascading issues in three ways:

Immediate rejection: When the circuit is open, requests fail in fractions of a millisecond, leaving thread pools free for healthy routes.
De-synchronized traffic: Full jitter spreads retries evenly across time, avoiding thundering herd spikes on recovering services.
Strictly bounded wait time: Retries cap out quickly rather than holding resources for long timeouts.

4. The AI Task Rationing Matrix

To build and preserve engineering judgment, categorize engineering tasks by the risk of outsourcing understanding:

Figure 3: Framework for delegating engineering tasks to AI based on cognitive value and risk.

Category	Typical Tasks	Role for AI	Review Rule
Low Risk (High Leverage)	Syntax lookups, boilerplate, regular expressions, test setup, CLI flags	Full delegation	Verify syntax and run existing tests. Relearning these syntax details adds little value.
Medium Risk (Collaborative)	Edge cases, schema validation, test coverage gaps, local refactoring	Sounding board	Write the core logic yourself first. Ask the model what inputs or boundaries you missed.
High Risk (Critical Core)	Concurrency controls, database transactions, auth/permissions, cache invalidation	Adversarial reviewer	Design and write alone. Use the model only to generate adversarial test cases against your finished contracts.

5. Practical Guidelines for Teams

Before merging code authored or suggested by an agent, review against these checks:

[ ] Can you explain the execution path and edge cases without consulting the prompt?
[ ] Did you state a hypothesis about the bug before asking the model for a fix?
[ ] Are failure modes (timeouts, 429 rate limits, partial payloads) verified with actual test assertions rather than happy-path mocks?
[ ] Are retries, timeouts, and resource pools strictly bounded?
[ ] Does the change solve the root cause rather than increasing a buffer or timeout to mask a bottleneck?

6. Summary

Coding tools are fast, but they do not build mental models for you.

Point AI at the parts of your work where being wrong has low consequence: typing boilerplate, scaffolding tests, and looking up syntax. Keep your hands on the core logic: state management, failure modes, and system boundaries.

The Part of AI Coding Agents I Didn't Expect to Care About: Latency

Prasad Rane — Mon, 07 Sep 2026 06:19:42 +0000

I spent the last few months pretty much living in Claude Code.

It became a regular part of how I worked: give it a task, let it work through the codebase, review what it changed, and keep iterating.

Today I ran the same multi-step agentic task through Google Antigravity, and the difference surprised me.

Antigravity, running Gemini Flash 3.8, finished the task in about half the time Claude Code took with Sonnet 5.

The speed was nice, but that's not actually what stood out to me.

It was the waiting.

The hidden cost of waiting

When an AI coding agent is working through several tool calls, there are moments where you can be staring at the screen for a minute or two waiting for the next step.

At first, I didn't think much of it.

But I've noticed what I do during those waits.

I check Slack.

I look at another tab.

I start thinking about something else.

And when the agent finally finishes, I have to spend a few seconds — sometimes longer — figuring out where I was in the problem.

That's a surprisingly expensive interruption.

It's not just the two minutes spent waiting. It's the context switch that happens during those two minutes.

When the feedback loop gets tight

With a faster agent, the interaction feels different.

You make a change.

The agent runs a tool.

It comes back.

You review the result and give it the next instruction.

Repeat.

When those cycles happen in seconds rather than minutes, it's much easier to stay focused on the problem.

You still have the architecture in your head. You remember why you made the previous change. You know what you want to try next.

You don't have to reconstruct the mental model every time the agent finishes a long operation.

That was the part I didn't expect to notice as much as I did.

Speed isn't just about tokens per second

When we compare coding agents, we tend to focus on things like:

Which model writes better code?
How good is the reasoning?
How well does it understand a large codebase?
How accurate are its tool calls?
How fast does it generate tokens?

Those things obviously matter.

But there's another metric that is harder to measure:

How long does it take to get back into the interaction?

A coding agent isn't operating in isolation. There's a human sitting in the loop.

If the agent takes two minutes to complete a step, the human doesn't necessarily remain in the loop for those two minutes.

That's where latency starts affecting productivity in a way that raw benchmark numbers don't really capture.

I'm not abandoning Claude Code

Claude Code is still very good, and I wouldn't make a broader conclusion from one task or one comparison.

The point isn't that one tool is universally better than another.

What surprised me was how much low latency changed the way I interacted with the agent.

After experiencing an agent that keeps the feedback loop moving quickly, long waits feel much more noticeable.

Maybe that's one of the next things we'll start paying more attention to with agentic development:

Not just how capable is the model?

But also:

How well does the system keep the developer in the loop?

Because sometimes the biggest productivity improvement isn't getting the agent to do more.

It's simply not giving the developer enough time to get distracted.

The Feynman Algorithm: A Developer’s Guide to "Thinking Very Hard"

Prasad Rane — Mon, 27 Apr 2026 16:06:50 +0000

If you search for Richard Feynman’s methods, you’ll likely stumble upon the famous Feynman Technique, a brilliant framework for learning new concepts by explaining them to a child.

But there’s another, lesser-known Feynman method. It was jokingly coined by his colleague, physicist Murray Gell-Mann, who said that Feynman’s process for solving problems looked like this:

Write down the problem.

Think very hard.

Write down the solution.

At first glance, this sounds like a meme. "Draw the rest of the owl," right? But if we look closer at this "Feynman Algorithm," it actually perfectly outlines the lifecycle of debugging and writing software.
Let’s break down how this tongue-in-cheek algorithm can actually help you become a better developer.

Step 1: Write down the problem ✍️

Albert Einstein supposedly said, "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions."

In programming, we often skip this. We see an error log and immediately start changing variables and refreshing the browser. But "writing down the problem" forces you to define exactly what is going wrong.

Bad Problem Definition:

"The login page is broken."

Good Problem Definition:

"When a returning user tries to log in with Google OAuth, the API returns a 500 server error, but only on mobile Safari."

When you write the problem down clearly, the scope narrows. Half the time, simply defining the problem accurately reveals the solution.

Step 2: "Think very hard" 🧠

This is the punchline of the joke. To outsiders, Feynman just stared at a chalkboard and magically found the answer. But "thinking very hard" doesn't mean having a massive IQ; it means engaging in structured, focused analysis.

How do developers "think very hard"?

We Rubber Duck: We explain the code line-by-line to an inanimate object (or a patient coworker).

We Isolate: We comment out chunks of code to see if the bug still happens. We narrow down the variables.

We Step Away: Sometimes, "thinking very hard" means taking a shower or going for a walk. Your brain's "diffuse mode" keeps working on the problem in the background.

"Thinking very hard" means resisting the urge to copy-paste the first Stack Overflow answer you see without understanding why it works.

Step 3: Write down the solution 💡

You figured it out! You fixed the bug! Time to push to production and go home, right? Not quite.

In the context of coding, "writing down the solution" means three things:

Writing clean code: Making sure your solution isn't just a hacky workaround, but a readable, maintainable piece of logic.

Writing tests: Proving that your solution actually works and ensuring it won't break in the future.

Writing documentation: Leaving comments explaining why you did what you did.

Your future self (and your team) will thank you when they read a comment like:

// Using a Set here instead of an Array because checking for duplicates was causing a massive performance bottleneck.

Final Thoughts

The Feynman Algorithm might have started as a joke among Nobel Prize-winning physicists, but it’s remarkably practical for software engineers.

Next time you are stuck on a nasty bug, don't just start mashing the keyboard. Stop. Write the problem down. Take a walk to think very hard. And when you solve it, document it for the next developer.

Let me know in the comments how you practice "thinking very hard" when you are stuck on a tricky coding problem!