The Cold Start Problem That's Costing You an Hour Every Week

You open Claude Code on Monday morning. The agent has no idea what you built on Friday. It doesn't know your project's architecture, your coding conventions, the bug you fixed at 4pm, or the deployment you ran before logging off. It's a blank slate. Again.

So you spend the first 10 minutes re-explaining. The stack. The file structure. The naming conventions. The decision about cursor-based pagination. The warning about the Stripe webhook needing the raw body. The pattern for error responses. The three things it must never do.

Fifteen minutes later, the agent is finally useful. Then the context window fills up, compaction fires, and half of what you explained is summarised into oblivion. Or worse: the session ends and tomorrow you start the whole process over.

One developer calculated the cost: 12 minutes of re-explanation per session, five sessions per week, roughly an hour lost every week. Over a month, that's a full working day spent teaching an AI things it already knew yesterday.

This is the cold start problem. And almost everyone using AI coding tools is paying the tax without realising how avoidable it is.

Why Cold Start Happens

AI coding agents are stateless by design. Each session begins with a fresh context window. The model has no memory of previous sessions, no knowledge of your project beyond what it can infer from the files it reads, and no awareness of decisions, conventions, or history unless you provide them.

The tools have attempted to address this:

CLAUDE.md loads project instructions at session start. It works for small, stable sets of rules. But as we've covered in a previous article, it degrades past 200 lines. Claude Code's own documentation acknowledges this.

Auto Memory lets Claude write notes to itself between sessions. It captures preferences and corrections, but it's unstructured. You can't query it by type. You can't filter it by topic. You can't prioritise what loads first. And it's capped at 200 lines before adherence starts dropping.

Session Memory recalls what happened in previous sessions. It helps with "what did I do yesterday" but not with "what are the 50 rules this project has accumulated over six months." Short-term recall, not long-term knowledge.

.cursorrules and AGENTS.md follow the same flat-file pattern with the same scaling limitations.

Every one of these solutions stores context inside the conversation pipeline, where it competes for attention with the actual work. The cold start problem persists because the knowledge is either lost between sessions (conversation history), too unstructured to query (auto memory), or too bloated to be followed reliably (flat files).

What Developers Are Actually Doing About It

The community has been inventive. Across Reddit, DEV Community, Medium, and the Claude Code GitHub issues, developers are building elaborate workarounds:

Manual session notes. Write 5-10 bullet points at the end of each session summarising what happened. Point CLAUDE.md at these notes so the agent reads them at session start. One developer reported this works if you're disciplined, but admitted they skipped writing notes 40% of the time, usually after the most frustrating sessions where the context mattered most.

Local memory servers. Install mcp-memory-service, Claude-Mem, or memsearch as local MCP servers. The agent stores memories in a SQLite database and retrieves them via semantic search. The problem: cold start race conditions (the embedding model hasn't loaded when the session hook fires), the agent doesn't always reach for the memory tool, and the memories are local to one machine.

Structured file systems. Create a .fcontext/ or memory/ directory with topic files, hot/cold tiers, and manual pruning protocols. One developer built a three-tier system with a 200-line hot memory file, topic-specific warm files, and a compressed monthly archive. It works, but it's infrastructure they built and maintain instead of working on their actual project.

Post-compaction hooks. Use Claude Code's hook system to inject critical context after compaction. A shell script fires on the PostToolUse lifecycle event with a compact matcher, injecting 10-50 lines of "context essentials" back into the session. Clever, but it's a band-aid: the hook only fires after context has already been lost.

Session handoff protocols. Elaborate prompt templates that instruct the agent to document everything it learns, write checkpoint files, and read them back at the next session start. Some developers add hourly reminders ("Remember to update your LCMP logs") because the agent forgets to maintain its own memory without prompting.

Every one of these is a developer solving an infrastructure problem by hand. They work to varying degrees. They all require discipline, maintenance, and ongoing attention. And they all miss the core issue: the context should exist outside the conversation from the start, not be reconstructed from conversation artifacts after the fact.

The Difference Between Warm Start and Cold Start

The distinction matters. A cold start is when the agent begins with zero project knowledge and builds understanding from scratch through conversation. A warm start is when the agent begins with project knowledge already loaded and can start working immediately.

Current solutions try to create warm starts by carrying over conversation context: session summaries, memory files, compaction hooks. This is fragile because conversation context is inherently lossy. Every summarisation discards detail. Every compaction reduces fidelity. Every session boundary is a point where knowledge can be lost.

A genuinely warm start requires project knowledge that exists independently of any conversation. Rules that were defined once and are always available. Decisions with rationale that persist regardless of which session discovered them. Warnings that survive compaction because they were never in the context window to begin with. An agent identity that doesn't depend on CLAUDE.md instructions being followed.

The distinction is between reconstructing context (carrying conversation artifacts forward) and loading context (querying a persistent, structured knowledge base). Reconstruction is lossy and fragile. Loading is deterministic and reliable.

Frontloading: Solving Cold Start Before Session One

Frontloading is the practice of populating your project's knowledge base before the agent's first session. Instead of building context organically over many sessions (and losing some of it every time), you seed everything upfront so the agent has the full picture from day one.

This means:

Rules go in before the first line of code is written. "All CSS in external files." "Never use offset pagination." "Always validate input before database queries." These aren't discovered during development. They're known constraints. Store them before the agent starts, and it follows them from the first session.

Decisions go in as they're made. "We chose PostgreSQL over MySQL because of the JSONB support for flexible schema fields." "We're using cursor-based pagination because offset breaks on large datasets with concurrent inserts." When the agent encounters these areas, it reads the decision instead of suggesting alternatives you've already rejected.

Warnings go in as they're discovered. Every gotcha, every framework quirk, every integration surprise. "The Stripe webhook signature requires the raw request body, not the parsed JSON." Store it once, and no agent on this project ever makes that mistake.

Patterns go in as they're established. The controller-service-model pattern. The error response format. The migration naming convention. The agent reads these before writing code, and the code follows existing conventions automatically.

Facts go in at project setup. The tech stack. The hosting environment. The database version. The deployment method. These are the foundational details that ground the agent in reality.

The How to Frontload Your Data guide walks through the full process: storing context entries via the dashboard or API, creating agent definitions, setting up runbooks, defining design system tokens, and creating initial tasks. The bulk API endpoint lets you create up to 50 entries at once, making it practical to seed an entire project's knowledge base in one sitting.

Bootstrap: The One-Call Warm Start

Frontloading puts the knowledge in the system. Bootstrap delivers it to the agent.

Bootstrap is a single MCP call that returns everything the agent needs to start a session with full project awareness:

• Agent identity: The agent's name, role, and system prompt. It knows who it is before it does anything.
• High-priority context entries: Rules, warnings, and facts tagged as high priority. The non-negotiables that apply to every session.
• Prompt entries: Context entries tagged with bootstrap that are injected as session instructions. These shape the agent's behaviour persistently.
• Styleguide summary: What design tokens, components, and patterns exist. The agent knows the design system is defined before it writes any UI.
• Active runbook runs: Procedures that are in progress. If a deployment was paused at step 6 yesterday, the agent knows to resume it.
• Open feedback count: How many unresolved user reports are waiting. The agent has situational awareness about what users need.
• Assigned tasks: Work items assigned to this agent, grouped by status. The agent knows what it should be working on.
• Recent feed activity: What the team (humans and other agents) has been doing since the last session.

All of this loads in a single call. The agent doesn't need to search memory, read flat files, or wait for hooks to fire. It calls bootstrap and starts working.

Compare this to the current cold start experience:

The cold start problem disappears because the knowledge never lived in the conversation. It lives in a structured store that the agent queries on demand. Compaction can't destroy it. Session endings can't erase it. Version upgrades can't wipe it. Switching machines can't lose it.

What This Looks Like in Practice

A developer who has frontloaded their project starts a Claude Code session:

> bootstrap

Session bootstrapped. Agent: Riley (Senior full-stack developer).
Loaded: 23 high-priority context entries, 4 prompt instructions.
Styleguide: defined (colours, typography, spacing, 8 components).
Active runs: none.
Open feedback: 2 items.
Assigned tasks: 3 open, 1 in review.
Recent feed: Nathan added a note on "Fix timezone bug" 2 hours ago.

The agent immediately knows:

• Who it is and how to behave (Riley, senior developer role)
• The project's rules (23 high-priority entries)
• The design system (8 components with tokens)
• That users have reported 2 issues (feedback)
• That it has 3 tasks to work on (with priorities)
• That a teammate left feedback on a task 2 hours ago

No re-explaining. No 10-minute warmup. No hoping CLAUDE.md is followed. The agent starts working on the highest priority task with full project context loaded in one call.

Why External Structured Context Beats Every Alternative

The cold start solutions developers are building (memory files, hooks, session handoff protocols) all share the same limitation: they store context inside or alongside the conversation pipeline. That means they're subject to the same failure modes: compaction loss, session boundary resets, flat-file scaling problems, and the non-determinism of whether the agent actually reads the context.

External structured context avoids all of these:

Compaction-proof. The context was never in the conversation window. Compaction can't lose what was never there. The agent re-queries what it needs after compaction.

Session-proof. Knowledge persists in a hosted API. Closing the terminal, switching machines, or starting a new session changes nothing. The knowledge base is the same on every session start.

Scalable. A project can have 500 context entries without any degradation. The agent doesn't load all 500. It queries by type, tags, scope, and priority, loading only what's relevant to the current task.

Deterministic. "Give me all high-priority rules" returns exactly that. Every time. No semantic similarity guessing. No hoping the right memory surfaces. No dependency on the agent choosing to search.

Shareable. The same knowledge base is available to every agent on the project and every developer on the team. A new team member's agent calls bootstrap and gets the same rules, decisions, and warnings that everyone else's agent knows.

Maintainable. Entries are created, updated, and deleted through the dashboard or API. No pruning protocols, no 200-line caps, no manual archiving. The knowledge base is a living system that grows with the project.

Getting Started

If your sessions start cold and you're spending 10+ minutes on context every time, here's how to fix it:

1. Sign up at app.minolith.io/register. 14-day free trial, no card required.

2. Frontload your context. Start with rules and facts. Even 10 high-priority entries will make a noticeable difference. Follow the frontloading guide for the full process.

3. Create an agent definition. Give your agent a name, role, and prompt. Set it as the main agent so bootstrap returns it automatically.

4. Connect via MCP:

   claude mcp add --transport http minolith https://mcp.minolith.io \
     --header "Authorization: Bearer mlth_your_api_key" \
     --header "X-Minolith-Agent: riley"

5. Call bootstrap at the start of your next session and see the difference.

Context operations are free on every plan. Store as many entries as you need. The cold start problem is solved the moment your project knowledge exists outside the conversation.

Your agent doesn't have to start from zero. Give it a memory before its first session, and it never starts cold again.

Built by Minolith. Persistent project memory for AI coding agents.