DEV Community: Jorge Peraza

Why 46% of Teams Ship Failing AI Code (And How to Fix It)

Jorge Peraza — Mon, 12 Oct 2026 14:10:08 +0000

TL;DR:

A survey published by SmartBear on October 2, 2026, reveals that 46% of engineering teams have shipped AI-generated code that subsequently failed in production.
Software engineers report that top-down executive pressure to adopt AI tools has created a surge in bug volumes and unmanageable manual verification workloads.
Single-shot AI completions shift the burden of edge-case verification directly onto the developer during the Pull Request phase.
MonkeysCode addresses this structural flaw through its desktop editor (v1.2.12) and built-in Capuchin agent, which executes automated test suites and iterates on failures before code is finalized.

The Verification Trap of Raw Completions

On October 2, 2026, SmartBear released a survey of nearly 1,500 developers and engineering leaders detailing the downstream effects of AI adoption. The most glaring data point: 46% of engineering teams have shipped AI-generated code that failed in production.

The report highlights a growing friction point in modern software development. Executives, eager for efficiency gains, apply top-down pressure on engineering organizations to adopt AI coding tools. However, most first-generation AI assistants operate as single-shot generators. They emit raw code completions based on static context without any mechanism to verify if the code compiles, let alone if it satisfies business logic or handles edge cases.

The result is a predictable shift in bottlenecks. Time saved typing boilerplate is immediately lost to an unmanageable manual verification workload. Developers inherit a massive PR review burden, forced to act as human linters for models that confidently hallucinate API contracts or overlook complex systemic dependencies.

Why Single-Shot AI Fails in Complex Systems

Large Language Models (LLMs) predict the most statistically probable next tokens based on the prompt provided. When generating a function, a single-shot model does not have access to a runtime environment. It cannot run a compiler, it cannot execute a unit test, and it cannot observe the actual state of a database schema at runtime.

Consider a recent real-world scenario from the MonkeysCode platform development. When querying a Postgres database for a JSONB field, a developer might naturally use the ? operator. A standard AI autocomplete tool will likely suggest exactly that. However, depending on the specific Postgres driver or ORM configuration, the ? operator can conflict with parameterized query syntax, causing a runtime failure. The correct approach in that specific environment might be to use the jsonb_exists() function instead (a fix we recently shipped to our own platform on October 4).

A single-shot AI tool has no way of knowing this will fail until the developer runs the code, encounters the error, and manually corrects it. If the developer skips local testing—perhaps trusting the AI's output under deadline pressure—the bug ships to production.

Automating Verification with Capuchin

To counter the manual verification burden, the AI tooling architecture must evolve from static generation to dynamic iteration. The machine must take responsibility for the verification loop.

This is the engineering philosophy behind MonkeysCode, an AI coding platform designed around the Capuchin agent. Built directly into the MonkeysCode desktop IDE, Capuchin does not just emit raw text completions. Instead, it operates on a structured loop: plan, modify across multiple files, execute tests, and iterate.

With the release of MonkeysCode editor v1.2.12 and Agent Manager 1.0.16 (shipped October 5, 2026), this iterative workflow is deeply integrated into the local environment. When a developer assigns a task to Capuchin, the agent can run the local test suite using the MonkeysCode CLI. If a test fails, the agent reads the stdout/stderr output, analyzes the stack trace, and modifies the code to resolve the regression before presenting the final changes to the developer.

The Iterative Loop in Practice

Here is a conceptual look at how this loop functions within the MonkeysCode desktop IDE:

Context Assembly: The developer provides a prompt. The Context Kernel gathers relevant file context. To manage token costs efficiently during complex tasks, we separate system blocks for models like GPT-6 and GPT-5.6 to maximize cache breakpoints (a feature refined in our recent GPT-6 model refresh).
Multi-File Execution: Capuchin plans and executes edits across multiple files simultaneously.
Test Execution: Capuchin runs the designated test command (e.g., npm run test:auth).
Error Consumption: If a test fails, Capuchin consumes the error output.
Iteration: The agent writes a patch to fix the error and re-runs the test.

In version 1.2.11 of the editor, we shipped UI updates to make supervising this loop seamless. Markdown test output, including tables, now renders directly in the chat interface. Furthermore, file names on diff cards are fully interactive—clicking them immediately opens the corresponding file tab so the developer can inspect the agent's work in context.

# Example of Capuchin's internal iterative logging
[Agent] Executing modifications in src/db/queries.ts
[Agent] Running test command: npm test -- -t "should fetch user metadata"
[System] Test failed: syntax error at or near "$1"
[Agent] Analyzing failure: Postgres parameterization conflict with '?' operator.
[Agent] Modifying query to use jsonb_exists().
[Agent] Re-running test command...
[System] Test passed.
[Agent] Presenting diff to user.

Managing the Trade-Offs

It is important to acknowledge the trade-offs of this architecture. An iterative, test-driven agent takes longer to complete a task than a single-shot autocomplete tool. It requires keeping connections alive while the model "thinks" (our model-proxy actively keeps Anthropic SSE streams alive to handle these extended reasoning phases).

Furthermore, running multiple iterations consumes more tokens. To mitigate this, MonkeysCode leans heavily on prompt caching. Our newly shipped Auto mode tab on the Models & Pricing page allows teams to monitor cache ratios and warns on mixed frontier providers to ensure maximum efficiency. We also recently updated the usage dashboards to explicitly show cache-write tokens, giving engineering managers full visibility into the cost of automated verification.

However, the time spent waiting for an agent to run tests locally is time the developer gets back during the PR review phase. By catching hallucinations and regressions in the local environment, the volume of bugs that reach production drops significantly.

Takeaway

The SmartBear data confirms what senior engineers already know: adopting AI tools without adapting your verification workflows is a recipe for production regressions. Executive pressure to ship faster cannot override the fundamental requirement for code correctness.

AI coding tools must evolve to integrate deeply with existing testing infrastructure. By moving the test-and-iterate loop inside the agent itself, tools like MonkeysCode shift the verification burden away from the developer, ensuring that the code you review is code that actually works.

To explore automated test-and-iterate workflows, download the MonkeysCode editor or read the documentation.

Preventing AI Lock-in: Open Models and Auto Routing

Jorge Peraza — Sun, 11 Oct 2026 14:10:08 +0000

TL;DR

On October 2, 2026, Shakudo published a guide highlighting a shift toward open agents and open-weight models to prevent commercial vendor lock-in during repository refactoring.
MonkeysCode decouples agentic capabilities from specific providers by natively supporting Bring Your Own Key (BYOK), local models, and open-weight models via Capuchin.
With the release of CLI 1.0.2, Agent Manager 1.0.16, and Editor 1.2.12, developers can execute multi-provider agent runs across their codebase.
A new "Auto" routing tab in the Models & Pricing dashboard tracks cache ratios and actively warns when mixing frontier providers degrades prompt caching efficiency.

The Vendor Lock-In Problem

When adopting AI coding assistants for large-scale repository refactoring, engineering teams face a growing architectural risk: tight coupling to a single proprietary model provider.

On October 2, 2026, Shakudo published a comparative guide analyzing coding assistants like OpenHands, Cline, and Goose. The core finding was clear: development teams are increasingly leveraging open agents alongside self-hosted and open-weight models to perform complex, multi-file refactoring. The motivation is straightforward. Relying exclusively on a single commercial vendor exposes teams to unpredictable API pricing shifts, arbitrary rate limit changes, and restrictive data governance policies. If an agent's capability is hardcoded to a specific frontier model's API, migrating away from that provider means losing the agent's multi-file capabilities.

Developers want the freedom to choose their infrastructure. They need the ability to run open-weight models locally for sensitive modules, while dynamically routing complex planning tasks to frontier models—all without sacrificing the agentic workflow.

Decoupling the Agent from the API

At MonkeysCode, we believe your codebase should not be held hostage by your choice of model provider. Capuchin, our built-in coding agent, is designed as an abstraction layer that separates the agent's planning, testing, and editing logic from the underlying LLM.

This week, we released Editor 1.2.12, Agent Manager 1.0.16, and CLI 1.0.2, which solidify our support for multi-provider agent runs. You can utilize Capuchin to plan and execute codebase-wide edits while completely controlling the model backend. MonkeysCode supports:

Bring Your Own Key (BYOK): Connect directly to frontier models using your own API keys, ensuring your usage and billing remain under your control.
Open Models: Integrate with hosted open-weight models via compatible endpoints.
Local Models: Point Capuchin to a local inference server running on your own hardware, ensuring zero code leaves your machine.

By keeping the agent logic client-side within the MonkeysCode editor and CLI, you retain the ability to refactor safely without commercial lock-in.

Configuring Local and Open-Weight Models

Setting up Capuchin to use a local or self-hosted model is done via standard configuration. Because the MonkeysCode Agent Manager standardizes the communication protocol, you can point the agent to any compatible local endpoint.

Here is an example of how you might configure your workspace to route Capuchin's requests to a local inference server running an open-weight model on localhost:

{
  "models": {
    "default": "local-open-weight",
    "providers": {
      "local-open-weight": {
        "type": "custom",
        "endpoint": "http://127.0.0.1:8080/v1/chat/completions",
        "context_window": 32000,
        "require_authentication": false
      }
    }
  },
  "agent": {
    "auto_route": true
  }
}

Once configured, invoking the agent via the CLI seamlessly uses your local hardware:

# Start a refactoring task using the local model
monkeyscode agent run --task "Refactor the authentication middleware to use the new session store" --model local-open-weight

This workflow ensures that even if a commercial API experiences downtime or changes its pricing structure, your team can continue operating by switching to an open-weight alternative.

Auto Routing and the Prompt Caching Trade-off

While local models are excellent for data privacy and cost control, large-scale repository refactoring often benefits from routing highly complex planning tasks to frontier models. MonkeysCode supports "Auto" model routing, which dynamically selects the best model for a given sub-task.

However, mixing providers introduces a technical challenge: prompt caching.

When Capuchin reads your codebase, it loads significant context into the model's memory. Modern frontier APIs use prompt caching to reduce the cost and latency of subsequent requests that share the same context prefix. If Auto routing switches a task from Provider A to Provider B mid-execution, the cache context is lost. Provider B must ingest the entire codebase context from scratch, leading to increased token usage and higher latency.

To surface this trade-off, we shipped an update to the Models & Pricing dashboard on October 6, 2026. The new Auto tab explicitly tracks your cache ratios (including cache-write tokens) and actively warns you when mixed frontier providers are degrading your prompt caching efficiency.

If you are using Auto mode across multiple providers, the dashboard will now display an alert similar to this:

WARNING: Mixed Provider Caching Degradation
Auto routing has distributed tasks between Provider A and Provider B.
Cache hit ratio has dropped by 42% due to context invalidation across endpoints.
Recommendation: Pin repository context to a single provider for the duration of the agent session.

This visibility allows engineering teams to make informed decisions. You can choose to optimize for capability by mixing models, or optimize for cost and speed by pinning a session to a single provider to maximize cache hits.

Hardware and Latency Considerations

While the architectural freedom to use local and open-weight models is a significant advantage, it is important to acknowledge the practical trade-offs.

Currently, MonkeysCode does not publish documented memory or VRAM hardware requirements for running specific open-weight models locally. The performance of local inference is heavily dependent on your specific hardware configuration. Furthermore, we do not provide side-by-side performance and latency benchmarks comparing local Capuchin runs against frontier cloud APIs for repository refactoring.

Teams opting for local models must evaluate their own hardware constraints and test the latency of local inference against their specific refactoring workloads. If local latency becomes a bottleneck, the BYOK architecture allows you to easily pivot back to a hosted open-weight endpoint or a frontier model without changing your Capuchin workflows.

Takeaway

Vendor lock-in is a valid concern for engineering teams adopting AI tools, as highlighted by Shakudo's recent findings. Tying your development workflows to a single proprietary API limits flexibility and exposes you to external risks.

By decoupling the agent from the model, MonkeysCode ensures that Capuchin works seamlessly across frontier APIs via BYOK, hosted open-weight endpoints, and local models. With the new Auto routing dashboard providing transparent metrics on prompt caching, teams have the data they need to balance capability, cost, and independence.

Ready to regain control over your AI infrastructure? Download MonkeysCode today or explore our Teams plans for organization-wide deployment.

Handling Frontier Model Churn: GPT-6, Caching, and SSE

Jorge Peraza — Sat, 10 Oct 2026 14:10:09 +0000

TL;DR

SSE Keep-Alives: We shipped a model proxy fix (October 4) that injects application-level pings into Anthropic streams, preventing network timeouts during extended reasoning phases.
Cache Breakpoints: The context kernel now strictly separates GPT-6 and GPT-5.6 system blocks (October 5) to preserve prefix-matching prompt cache breakpoints.
Azure Foundry GPT-6: Full proxy support via Azure Foundry and the Responses API shipped October 5, ensuring cache and effort parity.
Visibility: New dashboard updates (October 5-6) surface cache-write tokens and warn against routing inefficiencies when mixing frontier providers in Auto mode.

Rapid frontier model releases create immediate pressure on developer tooling. On September 30, 2026, thenextlevelsoftware.com reported an unprecedented wave of launches, including GPT-6, Claude Fable, Mythos 5.1, and Gemini 3.8 variants focused on tool use and execution. Days later, on October 4, daily.dev detailed Microsoft's integration of GPT-6 Astra, Claude Opus 5.5, Sonnet 5.5, and DeepSeek 4.1 Flash across Azure Foundry and Copilot ecosystems.

Integrating these models into an AI coding platform requires more than swapping an API URL. Frontier models with long-horizon execution and reasoning capabilities stress the underlying infrastructure. Network connections drop when models "think" for too long without emitting tokens, and prompt caching economics collapse if system instructions are not strictly versioned.

Here is how the MonkeysCode engineering team handles these low-level mechanics to keep our editor, CLI, and Agent Manager running reliably.

The SSE Timeout Problem During Reasoning

Models that spend extended periods reasoning before returning a response introduce a distinct networking challenge. In standard Server-Sent Events (SSE) architectures, reverse proxies and load balancers typically enforce idle timeout thresholds. If a stream remains open but silent for an extended period (often 30 to 60 seconds depending on the cloud provider), the connection is forcibly closed by the infrastructure.

When developers use models like Anthropic's thinking variants via the API, the model might compute extensively before yielding the first text token. In a standard setup, this results in premature connection closures, failed agent tasks, and a broken developer experience. The client sees a network error, and the agent loses its context window.

On October 4, we shipped a fix to the MonkeysCode model proxy specifically to handle this lifecycle. The proxy now injects application-level keep-alive comments into the Anthropic SSE stream while the model is actively thinking.

// Standard SSE payload with keep-alive injection
event: message
data: {"type": "thinking", "content": "Evaluating dependency tree..."}

: keep-alive-ping-1704382910

event: message
data: {"type": "thinking", "content": "Resolving circular imports..."}

According to the SSE specification, any line beginning with a colon is treated as a comment and ignored by the client's EventSource implementation. However, passing these bytes over the wire keeps the TCP connection saturated enough to bypass aggressive idle timeouts at the load balancer layer. This ensures that long-horizon reasoning tasks can complete without dropping the connection to the MonkeysCode desktop editor or CLI.

Preserving Prompt Cache Breakpoints

Prompt caching relies on strict prefix matching. For a KV cache hit to register on the provider's infrastructure, the sequence of tokens at the beginning of the prompt must exactly match a previously computed sequence. Even a single token difference in a system instruction will invalidate the cache for the entire subsequent payload.

With the release of GPT-6, we faced a structural issue. If we appended GPT-6 specific instructions (such as new tool-use definitions or effort-level parameters) to a unified system block, we would alter the prefix for all users. This would immediately bust the cache for developers still running GPT-5.6, driving up latency and token costs.

To solve this, we updated the MonkeysCode context kernel on October 5. The context kernel now strictly separates GPT-6 and GPT-5.6 system blocks.

// Simplified representation of the context kernel routing
function buildSystemBlock(modelId: string, baseInstructions: string) {
  if (modelId.startsWith('gpt-6')) {
    return generateGpt6SystemBlock(baseInstructions);
  }
  if (modelId.startsWith('gpt-5.6')) {
    return generateGpt56SystemBlock(baseInstructions);
  }
  return generateDefaultSystemBlock(baseInstructions);
}

By maintaining separate, versioned system blocks, we ensure that prompt cache breakpoints remain intact. Developers using GPT-5.6 retain their high cache hit rates, while developers testing GPT-6 establish new, stable cache prefixes. This update shipped alongside our releases for CLI 1.0.2, Agent Manager 1.0.16, and editor 1.2.12.

Azure Foundry GPT-6 Proxying and Visibility

Supporting a new model requires aligning its specific API surface area with our existing multi-model infrastructure. On October 5, we shipped full model proxy support for GPT-6 via Azure Foundry and the Responses API. This integration ensures cache and effort parity, meaning developers can utilize GPT-6's adjustable effort levels without losing the caching benefits built into our platform.

However, giving developers the ability to route between multiple frontier models introduces a new risk: cache fragmentation. MonkeysCode supports "Auto" model routing, allowing the platform to select the best model for a given task. If the system rapidly switches between an Anthropic model and an OpenAI model, the context window must be rebuilt from scratch each time, resulting in massive cache misses.

To give developers visibility into this, we shipped two major updates to our dashboards:

Cache-Write Tokens (October 5): The usage dashboards now explicitly surface cache-write tokens alongside standard input and output tokens. This allows developers to see exactly when they are paying to write to the KV cache versus when they are successfully reading from it.
Auto Tab Warnings (October 6): The admin Auto tab on the Models & Pricing page now displays cache ratios. More importantly, it actively warns users when their routing configuration mixes frontier providers in a way that destroys cache continuity.

If your Auto configuration routes a planning step to Claude Opus 5.5 and the execution step to GPT-6 Astra, the dashboard will flag the resulting cache miss penalty. Developers can then adjust their BYOK (Bring Your Own Key) or platform settings to maintain provider affinity during long sessions.

Takeaway

Integrating frontier models is an exercise in infrastructure management. Rapid releases from Microsoft, Google, and Anthropic require tooling that can handle the low-level realities of HTTP streams, KV cache prefixes, and multi-provider routing economics.

By injecting SSE keep-alives, separating system prompt blocks in the context kernel, and surfacing cache-write metrics, MonkeysCode ensures that developers can adopt new models like GPT-6 without sacrificing reliability or blowing through their context budgets.

To explore these updates, check out the latest usage dashboards in your account, or read more about our multi-model approach in the MonkeysCode documentation. If you are running agents locally, ensure you have updated to the latest CLI and Agent Manager versions.

Multi-Model Routing and SSE Keep-Alives for Agent Resilience

Jorge Peraza — Fri, 09 Oct 2026 14:10:09 +0000

TL;DR:

Provider outages break workflows: Recent Anthropic API disruptions (October 5-6, 2026) affecting Claude Opus 5.5, Mythos 5.1, and Fable 5.1 demonstrate the risk of single-provider reliance for long-running agent tasks.
Preventing silent timeouts: MonkeysCode shipped a model-proxy fix on October 4 to keep Anthropic Server-Sent Event (SSE) streams alive during extended model "thinking" phases, bypassing aggressive load balancer idle timeouts.
Multi-model routing: Workloads can route to Azure Foundry GPT-6, which was integrated on October 5 with cache and effort parity, ensuring tasks complete even when primary endpoints degrade.
Managing cache trade-offs: The new Auto mode tab (shipped October 6) tracks cache ratios and warns on mixed frontier provider configurations to help developers balance resilience and API costs.

Building autonomous AI coding agents requires managing a significant amount of state. When an agent is tasked with planning a feature, editing multiple files across a codebase, and running tests, it relies on a continuous, reliable stream of reasoning from a frontier model.

However, the underlying infrastructure powering these models is distributed, complex, and subject to disruption. On October 5 and 6, 2026, Anthropic experienced incidents causing elevated error rates across their Claude Opus 5.5, Mythos 5.1, and Fable 5.1 endpoints. According to reports from Statusgator and Claude.com, this disruption impacted Claude AI, the API, Claude Code, and Claude Cowork before recovering within twenty minutes.

For developers relying on a single provider, an API outage or rate spike mid-workflow often results in lost state, hanging requests, or a complete halt to development tasks. When an agent is halfway through a complex refactor, a sudden 502 Bad Gateway or a silent timeout is more than an inconvenience; it is a loss of valuable context and compute time.

To protect developer productivity, AI coding platforms must be engineered with network resilience and multi-model failovers as foundational requirements. Here is a technical look at how MonkeysCode handles connection management and multi-model routing to prevent agentic workflows from stalling during provider disruptions.

The Mechanics of SSE Keep-Alives During Model Thinking

When you invoke Capuchin, MonkeysCode's built-in coding agent, you are initiating a stateful, multi-step process. The agent reads the local file system, establishes context, and opens a streaming connection to an LLM provider using Server-Sent Events (SSE).

SSE is a lightweight, unidirectional protocol built on top of HTTP, ideal for streaming text tokens from an LLM. However, during complex refactors, frontier models enter a "thinking" or reasoning phase. In this phase, the provider's API might not emit text tokens for several seconds or even minutes as it evaluates the prompt and computes the optimal output trajectory.

At the network level, this silence presents a significant problem. Most standard reverse proxies, cloud load balancers, and client-side HTTP libraries enforce strict idle timeouts. If no bytes are transmitted over the TCP connection within that window (often 30 to 60 seconds), the intermediary drops the connection. The client receives a sudden ECONNRESET or a silent hang, and the agent's context window is lost.

To mitigate this, MonkeysCode shipped a model-proxy fix on October 4, 2026, specifically designed to keep Anthropic SSE streams alive while the model thinks. By injecting periodic, non-disruptive keep-alive pings (typically formatted as SSE comments like : keep-alive\n\n) into the stream at the proxy layer, we ensure the connection remains active through the load balancer's idle timeout window. This prevents silent drops during long-running planning phases, ensuring the agent can successfully transition from thinking to emitting actionable code edits without the connection being severed by overzealous network infrastructure.

Multi-Model Routing: Bypassing Endpoint Degradation

Even with robust connection management, a complete endpoint outage requires a different strategy. When Anthropic's Opus 5.5 endpoints experienced elevated error rates on October 6, developers locked into a single provider were left waiting for resolution.

Resilience requires redundancy. MonkeysCode supports multi-model configurations, allowing developers to route requests across different frontier engines, local models, or through a Bring Your Own Key (BYOK) setup.

On October 5, 2026, we expanded this redundancy by integrating GPT-6 via Azure Foundry, complete with cache and effort parity alongside our existing Anthropic support. By maintaining parity in how context is cached and how reasoning effort is parameterized, developers can switch models without rewriting their system prompts or losing performance baselines.

If a primary provider experiences a spike in 5xx errors, developers can immediately route the agent's next step to a secondary provider. Because the MonkeysCode editor and Agent Manager maintain the local state and file context, the transition happens cleanly. The new model reads the existing context and continues the task.

Furthermore, to optimize this transition, we shipped an update to our context-kernel on October 5 that keeps GPT-6 and 5.6 system blocks separate for cache breakpoints. This architectural decision ensures that when you do route to a different model, the system prompt structure aligns with that specific provider's optimal caching strategy, reducing unnecessary token processing.

Managing Cache Trade-Offs in Auto Mode

Switching providers mid-task introduces a specific trade-off: prompt caching. Frontier models rely heavily on prompt caching to reduce latency and API costs when processing large codebases. When you switch from Anthropic to Azure Foundry, the new provider does not have your codebase in its cache. The first request to the new provider will incur a full context-window read, increasing latency and cost for that specific turn.

To make these trade-offs visible, MonkeysCode introduced the Auto mode tab on October 6, 2026. This interface provides direct visibility into your cache ratios. Crucially, it warns developers when they configure mixed frontier providers in Auto mode.

If you configure Auto mode to round-robin or fallback between Claude Opus 5.5 and GPT-6, you risk thrashing the cache on both providers. The Auto tab surfaces these metrics, showing exactly how much of your context is hitting the cache versus requiring a fresh read. We also updated our usage dashboards on October 5 to explicitly show cache-write tokens.

This visibility allows senior engineers to make informed decisions: accept the cache-miss penalty for the sake of immediate failover during an outage, or pin to a single provider and wait for the disruption to resolve to maximize cache utilization. The platform does not force a specific path; it provides the telemetry and the routing controls necessary to adapt to real-world infrastructure conditions.

Takeaway

Agentic coding workflows are only as reliable as the infrastructure executing them. By implementing strict SSE keep-alives to survive long thinking phases, and providing transparent multi-model routing with cache parity, MonkeysCode ensures your development environment remains functional even when frontier providers degrade.

You can review your caching metrics and configure your model routing today in the MonkeysCode editor or via the Agent Manager. For teams looking to standardize these resilient workflows across their organization, explore our team plans and documentation.

MonkeysCode Ships Auto Mode: Phase-Based Model Routing

Jorge Peraza — Fri, 09 Oct 2026 04:10:11 +0000

TL;DR

MonkeysCode Auto mode is now live across Editor 1.3.1, CLI 1.1.1, and Agent Manager 1.1.1.
The router dynamically shifts models across distinct agent phases (plan → execute → review).
Context handoff briefs bridge state between frontier planning models and standard execution models without polluting context.
Pricing is calculated strictly per-turn based on the routed model, avoiding opaque flat premiums.

Developers using AI coding agents face a consistent balancing act between cost and capability. Routing all requests to a frontier model provides high reasoning capacity for architecture and multi-file planning, but burns through budget on routine execution tasks like boilerplate generation or minor syntax edits. Conversely, pinning an agent to a cheaper, smaller model saves money but routinely fails when the agent needs to plan complex state changes across a large repository.

To address this, MonkeysCode has shipped Auto mode across the MonkeysCode Editor, CLI, and Agent Manager. Auto mode replaces static model selection with a dynamic router that shifts models based on the current phase of the agent's workflow.

The Core Problem: Cost vs. Capability

Before Auto mode, developers had to manually toggle between models depending on the task at hand. If you needed Capuchin, our built-in coding agent, to scaffold a new microservice, you would manually select a frontier model. If you just needed it to write unit tests for an existing file, you might switch to a faster, cheaper model.

This manual switching creates friction. Developers often forget to switch back, leading to either failed complex tasks (because a small model was left active) or inflated bills (because a frontier model was used for hours of simple refactoring).

Auto mode removes this friction by making the routing decision programmatically based on the active phase of the agent's lifecycle.

Phase-Based Routing Architecture

Auto mode operates by breaking down a developer's prompt into a strict lifecycle: plan → execute → review. Rather than handling this entirely within a single context window of a single model, the MonkeysCode model-proxy and context-kernel route the work dynamically.

Plan: The initial request requires deep reasoning. The router assigns this to a frontier model. The frontier model analyzes the codebase, determines the necessary file changes, and constructs a detailed execution plan.
Execute: Once the plan is approved, the task shifts to the execute phase. The router escalates the execution steps to a faster, more cost-effective model suited for writing the actual code.
Review: After execution, a review phase validates the changes, ensuring the implementation matches the initial architecture plan.

This role-based routing was engineered over several distinct build steps. In build step 7, we formalized the roles inside Auto (plan → execute → review). In build step 8, we integrated the SDK plan error and route events, and added Auto mode UI elements like the plan card and routing chips to the Agent Manager. Furthermore, as documented in our D14 and D15 specifications, every app opens on Capuchin by default, and any subsequent fix round is treated as a new task, ensuring the router re-evaluates the necessary model for the fix.

Context Handoffs

A major technical hurdle in multi-model routing is maintaining state. Passing the entire planning dialogue into an execution model is inefficient. It wastes context window space, increases latency, and risks confusing smaller models with excessive architectural deliberation.

To solve this, we introduced the handoff brief in build step 5. The model-proxy generates a concise handoff brief that distills the architectural decisions and exact file targets from the plan phase. This brief is passed to the execution model, providing a clean, highly focused state without the overhead of the entire conversational history. The context kernel also provides phase and signal hints directly to the models to ensure they understand their current role in the pipeline.

Transparent Per-Turn Pricing

A common industry practice for "auto" or "premium" modes is to charge a flat, inflated rate regardless of which model actually processes the request. We rejected this approach.

With the release of Editor 1.3.1 and CLI 1.1.1, we explicitly dropped the "Auto frontier" button and removed the /frontier command. Instead, the context-kernel prices Auto turns strictly as the routed model. If the router assigns an execution task to a cheaper model, you are billed the exact rate for that cheaper model.

To make this transparent, we shipped a dedicated Auto usage card and route log in the web dashboard (build step 9), accessible via the GET /v1/usage/auto-summary endpoint. The web dashboard now features a dedicated Auto mode page, a home section highlighting active routes, and detailed billing highlights. You can view your exact per-model breakdown at monkeyscode.com/pricing.

Using Auto Mode

Auto mode is now the default experience across the MonkeysCode ecosystem.

In the CLI

We have updated the MonkeysCode CLI to version 1.1.1. The /model command now prominently displays Auto. We also shipped CLI tabs, mouse and command menus, and an Auto usage card directly in the terminal interface.

# Update to the latest CLI
npm install -g monkeyscode-cli

# Start an agent session in Auto mode
monkeyscode run --mode auto

In addition to the CLI updates, build step 9 introduced Agent Manager SSH support, model-proxy identity verification, and platform CORS updates to support distributed agent deployments.

In the Editor and Agent Manager

In Editor 1.3.1, we introduced the Auto picker, route chips, and plan cards. We quickly followed up with Editor 1.3.2 and Agent Manager 1.1.2, which introduced plan approval under Auto.

This means that even when Auto mode is handling the routing, you retain control. The frontier model generates the plan, and the Editor presents a plan approval UI. Only after you approve the plan does the model-proxy generate the handoff brief and route the task to the execution model. We also added an Auto status strip and a per-tab change tray in 1.3.2 to make the active phase and model completely visible.

For teams managing internal models, Auto mode respects the admin profile. The versioned Auto mode model config and admin API (shipped in build step 4) ensure that Auto only routes to servable models approved by your organization. The platform also keeps the Auto config partial index intact across schema:update operations, ensuring zero downtime for your routing rules.

Takeaway

Auto mode is not magic; it is pragmatic resource allocation. By formally separating the agent lifecycle into plan, execute, and review phases, and utilizing context handoff briefs, MonkeysCode allows developers to leverage the reasoning of frontier models without paying frontier prices for basic syntax edits.

Update to Editor 1.3.2 and CLI 1.1.1 today to start using Auto mode. If you are new to the platform, we recently shipped a permanent 14-day promo trial (replacing the old referral system)—check out the MonkeysCode documentation to get started.

Countering Developer Burnout with Agentic Test Execution

Jorge Peraza — Thu, 08 Oct 2026 14:10:08 +0000

The QA Fatigue Epidemic: Recent surveys reveal developers feel reduced to "human meat proxies," burning out from manually debugging "almost right" AI code.
Junior Deskilling: Overreliance on isolated AI snippets is impairing junior engineers' ability to independently debug and understand software architecture.
Automated Verification: MonkeysCode Editor 1.2.12 and CLI 1.0.2 shift verification from manual reading to automated test-and-repair loops.
Agentic Workflows: Capuchin executes test suites and iterates across multiple files autonomously, ensuring code is validated before it reaches your review queue.

The "Almost Right" Illusion and Developer Burnout

The narrative around AI coding tools has largely focused on generation speed, but the reality of maintaining that code is catching up with the industry. On October 6, 2026, Business Insider reported on a Stack Overflow survey revealing a stark reality: engineers are facing an identity crisis. Many feel reduced to "button-pushers and human meat proxies."

Instead of architecting software, developers are spending their days acting as manual QA testers for plausible-sounding but subtly broken AI snippets. This sentiment is not isolated. Reports from TechTarget on October 5 and Medium on September 30 highlight the exact same exhaustion. Engineers are experiencing severe QA fatigue because current AI coding workflows often output code that is "almost right."

Reviewing code that looks correct at first glance but contains subtle logic errors requires a significantly higher cognitive load than writing it from scratch. When a human writes code, they build a mental model of the system. When a human reviews a peer's pull request, they can ask the author for their context. When a developer reviews an AI snippet, they are forced to reverse-engineer the intent of a statistical model, hunting for hallucinated variables, type mismatches, and edge-case failures.

When you paste a snippet into a file, the AI's job ends, and your job begins. You have to wire it up, write the tests, run the tests, find the errors, correct the implementation, and rerun the test. This manual verification loop—acting as the runtime environment for a black-box model—is the root cause of the burnout developers are vocalizing today.

The Deskilling of Junior Engineers

The impact of this dynamic extends beyond senior developer burnout; it is actively affecting the next generation of engineers. On October 5, 2026, LeadDev reported that overreliance on AI generation tools is impairing junior engineers' ability to independently debug and understand complex software.

Struggling through a stack trace, navigating a codebase to find a failing test, and manually tracing data flow are the crucibles where architectural understanding is forged. When junior developers rely on AI to generate code blocks without engaging in the debugging process, their system-level comprehension atrophies. They become highly dependent on the tool to fix the very errors the tool created, leading to a shallow understanding of the underlying architecture. If the industry continues to treat developers as passive reviewers of AI output, we risk creating a generation of engineers who can generate boilerplate but cannot debug a production outage.

Shifting from Manual QA to Agentic Verification

To counter this burnout and deskilling, the workflow must change. The burden of verifying AI-generated code must shift from human line-by-line reading to automated execution. MonkeysCode addresses passive "button-pushing" code generation through Capuchin in the desktop IDE and the Agent Manager CLI.

With the release of MonkeysCode Editor 1.2.12 and Agent Manager 1.0.16 on October 5, 2026, we have solidified a workflow that prioritizes verification over raw generation. Capuchin does not just dump code into your active file. It plans, edits multiple files, runs tests, and iterates based on the output.

When you assign a task to Capuchin, it writes the implementation and then executes the associated test suite. If the test fails, Capuchin reads the stack trace, analyzes the failure, and attempts to repair the code. This autonomous test-and-repair loop continues until the tests pass or the agent reaches its iteration limit. By the time a human reviews the diff, the code has already been validated against the project's actual test suite.

Supervised Runs with Agent Manager

For developers who prefer terminal-driven workflows or need to integrate agentic tasks into broader scripts, we shipped MonkeysCode CLI 1.0.2 alongside Agent Manager 1.0.16. This allows for supervised agent runs directly from your command line.

Instead of manually copying and pasting snippets, you can instruct the CLI to handle the implementation and verification loop:

# Running a supervised agent task via MonkeysCode CLI 1.0.2
npx @monkeyscode/cli@1.0.2 task "Implement the user authentication middleware and ensure all tests in auth.test.ts pass"

The Agent Manager orchestrates the process, providing clear visibility into the agent's actions:

[Agent] Planning changes across 2 files: middleware/auth.ts, tests/auth.test.ts
[Agent] Applying edits to middleware/auth.ts
[Agent] Executing test suite: npm run test -- tests/auth.test.ts
[System] Test failed: Expected 401 but received 500.
[Agent] Analyzing stack trace...
[Agent] Applying fix to middleware/auth.ts
[Agent] Executing test suite: npm run test -- tests/auth.test.ts
[System] 4 passing (850ms)
[Agent] Task complete. Ready for review.

Once the agent completes its run, the human review process is highly targeted. In Editor 1.2.11, we shipped improved diff navigation: diff card headers directly open the affected file tab for targeted inspection. You aren't hunting for where the AI made changes; the editor guides you directly to the modified files, allowing you to review the logic with the confidence that the syntax and tests are already passing.

Model Choice and BYOK

A significant part of developer frustration stems from being locked into opaque systems that offer no control over the underlying reasoning engine. MonkeysCode addresses this by supporting model choice via multi-model routing and BYOK (Bring Your Own Key).

By allowing teams to route requests to the models best suited for their specific codebase and providing the flexibility to bring their own API keys, developers regain control over their tooling. This ensures that the agentic workflows are powered by the models you trust, rather than forcing you into a one-size-fits-all black box.

Takeaway

The era of developers acting as full-time QA testers for AI snippets is unsustainable. The data from Stack Overflow, TechTarget, and LeadDev clearly shows that this dynamic leads to burnout and deskilling. By adopting agentic workflows that execute tests and iterate autonomously across multiple files, teams can shift the burden of verification back to the machine. Tools like Capuchin and the MonkeysCode CLI are designed to restore the developer's role as an architect, leaving the tedious work of syntax checking and test-fixing to the agent.

Explore how automated verification can improve your workflow by downloading the MonkeysCode Editor or reading our documentation. For organizational deployment, review our team plans.

Hardening Prompt Caches and SSE Streams for Coding Agents

Jorge Peraza — Wed, 07 Oct 2026 14:10:10 +0000

TL;DR:

Anthropic SSE Keep-Alives: We updated the model proxy to inject keep-alive pings during extended Anthropic "thinking" phases, preventing load balancer and NAT gateway timeouts.
GPT-6 Cache Breakpoints: The context kernel now strictly separates GPT-6 and GPT-5.6 system blocks to ensure deterministic prefix matching and reliable cache breakpoints.
Azure Foundry Support: GPT-6 is now supported via Azure Foundry and the Responses API with full cache and effort parity.
Cache Observability: Usage dashboards now surface cache-write tokens, and the Auto mode tab warns against provider-mix cache invalidation.
New Releases: MonkeysCode Editor 1.2.12, Agent Manager 1.0.16, and CLI 1.0.2 are now available.

When deploying autonomous coding agents for multi-turn tasks, infrastructure reliability is just as critical as the reasoning capabilities of the underlying models. During extended sessions, where an agent like Capuchin plans, edits multiple files, runs tests, and iterates, developers face two primary failure modes: dropped connections during long reasoning phases and cache misses across model switches.

These failures are not just minor inconveniences. A dropped connection forces the agent to retry, duplicating work and increasing latency. A cache miss forces the model to recompute the KV cache for the entire context window, leading directly to bloated API bills and degraded time-to-first-token (TTFT).

Over the last two weeks, we shipped a series of updates to the MonkeysCode context kernel and model proxy designed to harden prompt caching and agent stream reliability across frontier models.

The Mechanics of SSE Timeouts During Extended Reasoning

Modern frontier models utilize extended reasoning or "thinking" phases before emitting the first token of a response. While this drastically improves the quality of complex code generation, it introduces a significant networking challenge when streaming responses via Server-Sent Events (SSE).

When a client requests a completion, the proxy establishes an HTTP connection with chunked transfer encoding. In a standard generation scenario, the model emits tokens rapidly, ensuring continuous byte flow over the TCP connection. However, during a long thinking phase, the model may not emit any standard completion tokens for an extended period.

Network intermediaries—such as NAT gateways, load balancers, and reverse proxies—are configured with idle timeout thresholds. If no data traverses the connection before the timeout is reached, the intermediary assumes the connection is dead and unceremoniously severs it. For the developer, this manifests as a broken stream and an agent that halts midway through a complex refactor.

To address this, we shipped a fix to the MonkeysCode model proxy: fix(model-proxy): keep Anthropic SSE streams alive while the model thinks.

At the proxy layer, we now monitor the idle time between chunks during Anthropic streams. If the model is in a thinking state and the time since the last byte approaches the threshold, the proxy injects a standard SSE comment payload (e.g., : ping\n\n). Because SSE specifications require clients to ignore lines starting with a colon, these pings safely traverse the network, resetting intermediary idle timers without polluting the actual completion stream parsed by the Agent Manager. This ensures the connection remains open regardless of how long the model spends planning its next edit.

Deterministic Cache Breakpoints for GPT-6

Prompt caching is mechanism that allows providers to reuse the KV cache of previously processed tokens, provided the token sequence matches exactly from the beginning of the prompt (the prefix). Even a single differing token early in the system prompt will invalidate the prefix, causing a total cache miss for the remainder of the context window.

With the introduction of GPT-6, we observed that sharing dynamic system blocks between model generations was leading to unpredictable cache behavior. GPT-6 and GPT-5.6 often require slightly different system instructions to optimize their respective coding capabilities. If these instructions are concatenated or conditionally injected into the same block, the prefix diverges early, destroying cache efficiency.

To enforce predictable caching, we shipped an update to the context kernel: feat(context-kernel): GPT-6 model refresh; keep GPT-6/5.6 system blocks separate for cache breakpoints.

By physically separating the system blocks in the context kernel, we ensure that the shared foundational context—such as project architecture, file structures, and core rules—remains identical up to the designated breakpoint. The model-specific instructions are appended only after the shared prefix, maximizing the number of tokens that can be safely retrieved from the cache.

Additionally, we have fully integrated GPT-6 via Azure Foundry and the Responses API (feat(model-proxy): GPT-6 via Azure Foundry and the Responses API, with cache and effort parity), ensuring that enterprise developers using BYOK (Bring Your Own Key) on Azure receive the exact same cache and effort parity as those using the direct OpenAI API.

Observability and Cache Ratio Tracking in Auto Mode

MonkeysCode's "Auto" model routing allows the platform to dynamically select the best model for a given sub-task. While powerful, mixing models from different providers (e.g., routing a planning task to an Anthropic model and a syntax-checking task to an OpenAI model) introduces a hidden cost: cross-provider cache invalidation.

Anthropic and OpenAI use completely different tokenizers and isolated infrastructure. A context window cached on Anthropic's servers is entirely useless to an OpenAI model. If Auto mode rapidly alternates between providers in a multi-turn Capuchin run, the agent will incur the cost of processing the full context window on every single turn.

Developers need visibility into these mechanics to optimize their configurations. Relying on end-of-month billing reports is too slow.

We recently rolled out several updates to the admin and usage dashboards to make these mechanics transparent:

Cache-Write Tokens: The usage dashboards now explicitly track and display cache-write tokens (feat(web): usage dashboards show cache-write tokens). Developers can immediately see when their agents are writing to the cache versus reading from it.
Auto Mode Cache Ratios: In the Models & Pricing settings (feat(admin): Auto mode tab on Models & Pricing (Auto build step 4)), the new Auto tab surfaces real-time cache ratios.
Provider-Mix Warnings: The Auto tab now actively warns administrators when their model routing configuration mixes frontier providers in a way that will degrade cache efficiency (feat(admin): Auto tab shows cache ratios and warns on mixed frontier providers).

These additions allow senior engineers to make informed trade-offs. If a specific task requires the unique reasoning capabilities of two different providers, the developer can accept the cache miss. But they will no longer do so blindly.

Latest Releases and Next Steps

These infrastructure improvements require the latest client software to function correctly, particularly the updates to how the Agent Manager parses SSE streams and how the editor constructs context windows.

We have released MonkeysCode Editor 1.2.12, Agent Manager 1.0.16, and CLI 1.0.2. We recommend all teams upgrade to these versions immediately to benefit from the reduced latency and improved stream reliability.

To update the CLI, run:

npm install -g @monkeyscode/cli@latest

The desktop IDE will prompt you to update to 1.2.12 on your next launch, or you can download it directly from monkeyscode.com/download.

For teams participating in upcoming build events, we have also published new hackathon documentation (docs: hackathon docs), which details how to optimize agent context windows for rapid prototyping. You can find these guides at monkeyscode.com/docs.

By managing state cleanly across the proxy and kernel layers, we ensure that Capuchin spends less time re-reading unchanged files and recovering from network drops, and more time writing working code.

Stop Prompting, Start Pairing: How to Actually Get Better at Code by Working With AI Agents

Jorge Peraza — Wed, 16 Sep 2026 23:45:44 +0000

I've been writing code for more than 20 years: PHP, Drupal, TypeScript, cloud infrastructure, and now LLM serving for an agentic IDE I'm building. Over the last year of working with coding agents every day, I've seen developers split into two groups:

Developers who got sharper. They understand more languages, make better architecture decisions, and review code faster.
Developers who got rusty. They ship more code than ever, but they couldn't explain half of it without the agent open. The tool isn't the difference. Both groups use the same agents. The difference is what they delegate.

The trap: delegating the thinking

The default loop looks like this:

prompt → accept → run → "works" → ship

It feels productive, and in the short term it is. But this loop trains you in only one thing: writing prompts. You get output without gaining skill. Six months later, you're faster at producing code and slower at understanding it.

The fix isn't to stop using agents. It's to change the relationship. Treat the agent as three things at once:

A senior pair programmer who challenges your decisions
A rubber duck that talks back when you need to think out loud
A student you have to review and correct Here are the practices that made me better, not just faster.

1. Design first, and make the agent argue with you

Before any code, ask for options instead of an implementation:

I need to add multi-tenant support to this service.
Don't write code yet. Give me 3 architectural approaches
(e.g., shared schema, schema-per-tenant, database-per-tenant),
with trade-offs in cost, isolation, migrations, and operational
complexity. Then ask me which one I'd pick and why.

Then you choose, and you write down why. Now you're practicing the most valuable skill in the job, making architecture decisions under trade-offs, with an expert opponent available 24/7.

Bonus: save that reasoning as an ADR (Architecture Decision Record). Future you, and future agents, will thank you.

2. "Attempt first" for anything you want to learn

For code you just need done, let the agent write it. For code in an area you want to master, write it yourself first, then ask for a review:

Here's my implementation. Review it like a strict senior engineer.
Point out bugs, non-idiomatic code, performance issues, and
edge cases I missed. Don't rewrite it — explain each issue
and let me fix it.

The line "don't rewrite it" matters. If the agent fixes the issue, you learn nothing. If you fix it, you remember it.

3. The "explain it back" rule

My rule before merging any agent-generated code: I must be able to explain every line. If I can't, that's not a reason to trust it. It's a gap in what I know.

When I hit a line I don't fully understand, I flip the roles:

Don't explain this code to me. Quiz me on it.
Ask me 5 questions about what this function does,
why it's written this way, and what breaks if we change it.
Tell me which answers are wrong.

Being quizzed exposes gaps much faster than reading an explanation.

4. Learn new languages by porting code you already know

The fastest way I've found to learn a new language with an agent is to port something you already understand deeply.

Take a small module you wrote in your main language (for me, PHP) and rewrite it yourself in the target language (Go, Rust, whatever). Then ask:

I ported this PHP class to Go. Compare both versions.
Where is my Go code "PHP written in Go syntax"?
Show me the idiomatic Go approach for each case and explain
the language concept behind it (interfaces, error handling,
ownership, concurrency, etc.).

Because you already know the domain logic, all of your attention goes to the language itself: its idioms, its type system, its way of handling errors. You learn the language from your own mistakes instead of tutorial examples.

5. Always ask for the "why" and a source you can verify

Agents are confident even when they're wrong. Turn that into a learning habit:

Why is this the correct approach? Point me to the relevant
documentation section, RFC, or language spec so I can verify it.

Then actually open the source. Half the time you'll learn something the agent didn't mention. The other half, you'll catch it being wrong, and that teaches you even more.

6. Break things on purpose

This is my favorite one. Use the agent to create debugging exercises from your own codebase:

Introduce one subtle bug into this module — something that
passes a quick review but fails in production (race condition,
off-by-one, timezone, null handling). Don't tell me where.
Give me only the symptom a user would report.

Then hunt it down without help. It's like a debugging gym built from your own real code. You can also have the agent write failing tests and make them pass yourself.

7. Architecture katas: let the agent be the chaotic stakeholder

Designs look great until the requirements change. So simulate the change:

Here's my design for an order system. Act as a product manager
who changes requirements every round. Give me one new requirement
at a time (multi-currency, partial refunds, 10x traffic,
GDPR deletion...). After each one, ask me what changes in my design.
Tell me when my design starts to break.

After five rounds, you'll know where your design is fragile, and why patterns like event sourcing, CQRS, or hexagonal architecture exist. You'll understand them from experience, not from a blog post.

8. Review the agent like you'd review a junior, and keep a log

Treat every agent PR as a pull request from a talented junior developer: read it, question it, request changes.

Then keep a simple "agent mistakes log":

Date	Mistake	Why it was wrong	Pattern to remember
09/12	N+1 queries in listing	Lazy loading inside loop	Eager-load relations in list views
09/14	Swallowed exception	Empty catch block	Never catch without logging or rethrowing

After a month, this log becomes your personal list of anti-patterns. The agent's mistakes turn into your expertise.

9. Write your standards down, because it forces you to know them

Most agent tools support a project rules file (for example AGENTS.md, CLAUDE.md, or similar) where you describe conventions, architecture, and boundaries.

Writing that file is a surprisingly hard exercise. You have to spell out things you've only ever "felt":

Why is the domain layer separate from the infrastructure layer?
When do we use a queue versus a synchronous call?
What does "done" mean in this codebase? If you can't write your architecture down clearly, you don't understand it clearly yet. The agent just gave you a reason to find out.

A simple weekly routine

Daily: Apply the "explain it back" rule to every merged PR.
Twice a week: Write one feature yourself first, then get an agent review.
Weekly: Do one bug hunt (practice 6) or one architecture kata (practice 7).
Monthly: Review your mistakes log and update your rules file. It adds maybe 2 to 3 hours a week. In return, you grow as an engineer instead of just getting faster at typing prompts.

How to know if you're learning or just outsourcing

Ask yourself honestly:

Could I rebuild last week's feature without the agent, even if it took longer?
Do I catch the agent's mistakes more often than I did three months ago?
Can I explain the trade-offs behind our current architecture?
Am I comfortable reading code in a language I didn't know six months ago? If the answers are "yes," the agent is making you better. If they're "no," you're renting skill instead of building it.

Improve together

Agents aren't going away, and they'll keep getting better. The developers who thrive won't be the ones who write the best prompts. They'll be the ones who use every interaction as a chance to learn, and who can still think clearly when the agent is wrong.

Don't just give the agent instructions. Grow alongside it.

What's one thing an AI agent taught you that actually stuck? Tell me in the comments. I'd love to build a list of learning techniques together.

Your AI Coding Agent Shouldn't Live on Your Laptop

Jorge Peraza — Mon, 14 Sep 2026 00:47:19 +0000

Every AI coding tool I have used makes the same assumption: the code is on the laptop you are sitting at.

That is true for maybe half of what an engineering team actually does. The rest happens on a dev box, in CI, on a staging environment, or on a build machine that has the toolchain your laptop does not.

We just shipped the MonkeysCode Code Agent, a desktop app for running coding agents across projects without an editor in the way. The most interesting part of it is not the agent loop. It is where the agent is allowed to run.

Four execution backends

The agent can execute against any of these, and you pick per workspace.

Local. Your machine. Full capability, including semantic search against a local index and interactive shell sessions.

SSH. A remote development box. Every command is translated and executed there, not here. This is the one nobody else offers, and it is the one I use most.

Cloud. A managed container workspace, sandboxed by default.

Remote control. A peer machine over WebSocket, running a remote host agent. A build server, a test rig, a colleague's environment.

Each backend declares its real capabilities honestly. Semantic search is not available over SSH, so the agent's system prompt says so and the UI adapts. It is not allowed to attempt something that will fail and then improvise around the error.

That last detail matters more than it sounds. A lot of agent frustration comes from the model confidently trying something the environment cannot do, failing, and then trying three more things. Telling it the truth up front is cheaper than letting it discover the constraint.

What this looks like for DevOps

Here is the part I think is genuinely underexplored in this category.

CI that fixes itself

The CLI runs the same engine headless, with structured output and real exit codes.

- name: Attempt automated fix
  if: failure()
  run: |
    mcode -p "The test suite failed. Read the output, find the cause, fix it." \
          --output json \
          --permission-mode accept-edits > result.json
    echo "exit=$?"

Because every run is test-gated, a change that does not make the suite green never gets applied. The agent either produces a working fix or it produces nothing. There is no middle state where it commits something plausible and moves on.

That is what makes this usable unattended. Not the model quality, the guardrail.

Scheduled maintenance

Background and scheduled runs mean the boring recurring work can happen without a human starting it.

Every Monday 06:00
  → Update dependencies, run the suite, open a PR if green
Every night
  → Generate tests for files changed in the last 24h
Every deploy
  → Check the changelog matches what actually shipped

Each one produces a signed record and a diff you review before merging. It is not autonomous merging, it is autonomous preparation.

Agents on the machine that has the toolchain

This is the SSH case and it comes up constantly.

Your laptop is macOS on ARM. Production is Linux on x86. The build needs a GPU you do not have, or a database that only exists on the dev box, or a proprietary compiler your security team will not license per-seat.

Point the agent at the machine where those things live. It reads the real filesystem, runs the real build, sees the real errors.

mcode --backend ssh --host devbox-3 \
      -p "The nightly build is failing on the arm64 target. Diagnose it."

No syncing, no containerising your dev environment, no reproducing production locally.

Many agents, many projects

The desktop app orchestrates parallel runs across independent projects, each in an isolated workspace. A mission board shows what every agent is doing, an inbox collects the ones waiting on a decision, and you review a signed diff and test report before anything merges.

For anyone maintaining several services, this is the difference between an agent being a tool you use and an agent being work that happens.

The guardrails, because autonomy without them is a liability

Four permission modes, and you switch with a keystroke.

Mode	Reads	Edits	Runs commands
Plan	yes	no	no
Ask	yes	on approval	on approval
Accept edits	yes	automatic	on approval
Auto	yes	automatic	automatic

Note that edit permission and command permission are deliberately separate. In practice people trust an agent to modify a file long before they trust it to run something in their shell. Bundling those into one autonomy slider was a mistake we made early and corrected.

Auto mode is only available inside a sandbox. Not as a policy, as an enforced constraint. Seatbelt on macOS, bubblewrap on Linux, AppContainer on Windows.

Two engineering details worth stealing

We did not build undo on git stash

Every file the agent touches is snapshotted before its first mutation, so you can revert one file or an entire run.

The obvious implementation is git stash push -u. One command, already there, works.

It also destroys your own uncommitted work.

Think about the actual scenario. You have half-finished changes in your tree. You ask an agent to do something unrelated. You do not like the result and you revert. With git stash, your half-finished changes went with it.

So we built a separate snapshot store. Pre-mutation capture per file, selective revert, workspace-scoped so it cannot reach into another project, and honest about limits: a recursive directory delete is flagged as unrevertable rather than silently skipped.

More work than one git command. But an undo feature that occasionally destroys your work is not an undo feature.

Diagnostics report only what the agent broke

After edits, the agent runs your project's type-checker or linter.

The important part is that it captures a baseline at run start and reports only what is new. If your codebase already has 400 warnings, you do not get 400 warnings. You get the ones it just introduced.

Anyone who has introduced a linter to a legacy codebase knows why this matters. Signal drowns in noise, people stop reading it, and the tool stops working. A verification step that produces noise is the same as no verification step.

It also detects the right checker per language, scopes to affected packages in a monorepo rather than checking everything, and retries once on transient failures so a mid-build state does not report a false problem.

Research that outlives the session

One more thing that does not exist elsewhere as far as I know.

Some work is not a task. It is a question you chase across days. A performance regression nobody can reproduce. A migration you are scoping. A bug that only appears under load. That is a dozen runs across a week, and by Thursday you have forgotten what you ruled out on Monday.

Investigations are long-lived threads scoped to a project. Runs link to them, findings accumulate, and the output is real markdown under .monkeyscode/docs/ in your repository. Git-tracked. Editable in any editor. Reviewable in a pull request.

Not locked in an application database that dies with the tool. If your work lives inside a vendor's storage, you do not own it.

On the model

The agent runs on Capuchin, which we train and serve ourselves, or on Claude, Gemini, ChatGPT, or a model on your own hardware. Switching is a setting.

Capuchin Reason scores 62.1% on SWE-bench Pro. Claude Opus, the current leader, scores 64.3%. We are 2.2 points behind, measured on our own production endpoint at the same quantization and context configuration we actually serve, with the methodology published.

The number I find more informative: in production, 92.7% of requests run on Capuchin rather than on a frontier model, even though every user can switch with one setting. For most daily work the 2.2 points are not something you feel.

Owning the model is also why we can support the ones we do not own. Capuchin is cheap enough for us to serve that we can include frontier allowances in the plan and support local models we earn nothing from.

What is not finished

Semantic search only works on the local backend. Over SSH or against a cloud container you get grep and file operations, not vector search. The agent is told this explicitly rather than being allowed to try and fail, but it is a real limitation.

We have not published a cost-per-task figure. Cursor has. We should, and we will, once the measurement is standardised.

The CLI is shipping shortly rather than shipped.

We are pre-1.0 and say so.

Try it

The Code Agent and the IDE are both included in every plan, including the free tier with your own API keys. Thirty days of unlimited Capuchin, no credit card.

👉 monkeyscode.com/code-agent

If you try it, I would rather hear what broke than get a signup. Comments are open and I read all of them, particularly if you have opinions about the SSH backend, which is the part I am least sure we have got right.

Meet Capuchin AI: Fast, Reasoning, and Not the Only Option

Jorge Peraza — Wed, 29 Jul 2026 01:46:28 +0000

Capuchin is the AI that powers MonkeysCode by default. This post is about what it actually does, how it's served, and, since we've gotten this question a lot, what it isn't.

Two modes, one model

Coding tasks aren't uniform. Autocomplete and small edits need to feel instant. Planning a multi-file refactor or chasing a gnarly bug benefits from actually thinking it through. Most tools pick one tradeoff and apply it everywhere. Capuchin doesn't:

Capuchin Flash. Thinking off, sub-second responses. This is the 80% of coding work: completions, small edits, quick questions.
Capuchin Reason. Step-by-step reasoning, budgeted so "thinking" never turns into "spinning." This is the 20% that's actually hard: multi-file plans, debugging, tradeoffs. MonkeysCode routes between them automatically based on the task, or you can pin one yourself. The point isn't "slow but smart" vs "fast but dumb." It's picking the right tool per step, inside a single session.

Why we can afford to include unlimited usage

The honest answer is efficiency. Capuchin is built to activate only a fraction of its total capacity per token. The architecture spends its weights on software-engineering tasks specifically, rather than spreading capacity across everything a general chat model tries to do. That's what makes it both sharper on real coding work and cheap enough to serve that we can bundle generous usage into a subscription instead of metering every token.

Practically, that shows up as:

Speculative decoding and caching keep response times low even under load
A fair-use ceiling, not literal infinity. "Unlimited" is generous, not unbounded, so the economics stay sane for everyone ## Built to use tools, not just talk about them

Capuchin is tuned specifically for agentic work: it calls your terminal, git, test runner, browser, and MCP servers and uses the results accurately across long sessions, the kind of 20-30-tool-call runs that real refactors actually take, not a single-shot completion. It plans before it acts, executes across files in parallel, and runs your tests before handing back. If something fails, it sees the failure and fixes it rather than reporting success prematurely.

It's also polyglot by design, strong across Python, JavaScript/TypeScript, Go, Rust, Java, and more, because most of us aren't working in a single language, and a model that's only good at one is a model you'll outgrow.

What it is not: a local model

This is worth being precise about, because we've seen the confusion. Capuchin is a managed cloud service, the same delivery model as Claude, ChatGPT, or Codex. It is not something you download and run on your laptop.

If you need fully offline or air-gapped work, that's a real, fully supported path in MonkeysCode. It's just a different one: point the IDE at your own model, local (Ollama, llama.cpp, vLLM) or on your own server. Capuchin is the managed default; your own model is the offline path. Two clean, non-overlapping stories, not one confused one.

How it gets better

We start from a strong open foundation and specialize it hard for real software-engineering work inside MonkeysCode, rather than training something narrow from scratch. Improvement after that is:

Opt-in only. Free, Pro, and Team users choose whether usage signals contribute to improving the model. The default is off.
Never from enterprise, self-hosted, or air-gapped installs. No exceptions, regardless of any general opt-in setting.
Signal over source. Where opt-in is given, we prefer derived signals (was the edit kept? did tests pass?) over retaining raw code.
Gated releases. Every new checkpoint has to beat the current one on our internal benchmark before it ships. No regressions allowed through. ## Try it

Capuchin is included with unlimited usage on every paid MonkeysCode plan, and free to try for a month during our founding-user promo.

👉 monkeyscode.com/promo

If you've got questions about the Flash/Reason routing, the fair-use design, or where the local/managed line actually sits, ask away in the comments. Happy to get into the weeds.

Authentication with MonkeysLegion 2.0 + Next.js / React

Jorge Peraza — Fri, 08 May 2026 02:58:20 +0000

A complete guide to implementing JWT-based registration, login, session persistence, and token refresh using the MonkeysLegion v2 API with a Next.js (or React) frontend.

API Endpoints Overview
Backend Setup (MonkeysLegion)
Frontend: API Client
Frontend: Auth Context Provider
Frontend: Register Page
Frontend: Login Page
Frontend: Protected Routes
Token Refresh Flow
Common Issues & Solutions

API Endpoints Overview

MonkeysLegion v2 exposes the following auth endpoints under the /api/v2/auth prefix:

Method	Endpoint	Auth	Description
`POST`	`/auth/register`	No	Create a new user + company
`POST`	`/auth/login`	No	Authenticate and get JWT tokens
`POST`	`/auth/refresh`	No	Exchange refresh token for new access token
`GET`	`/auth/me`	Yes	Get authenticated user profile
`POST`	`/auth/logout`	Yes	Invalidate tokens
`POST`	`/auth/forgot-password`	No	Request password reset

Response Shapes

Login Response — POST /auth/login

{
  "data": {
    "access_token": "eyJ0eXAiOiJKV1Q...",
    "refresh_token": "eyJ0eXAiOiJKV1Q...",
    "token_type": "Bearer",
    "expires_in": 1800,
    "user": {
      "id": 1,
      "email": "user@example.com",
      "full_name": "John Doe"
    }
  }
}

Register Response — POST /auth/register (HTTP 201)

{
  "data": {
    "message": "Registration successful",
    "user": {
      "id": 1,
      "email": "user@example.com",
      "full_name": "John Doe"
    },
    "company": {
      "hash": "abc123",
      "name": "Acme Inc."
    },
    "access_token": "eyJ0eXAiOiJKV1Q...",
    "refresh_token": "eyJ0eXAiOiJKV1Q...",
    "token_type": "Bearer",
    "expires_in": 1800
  }
}

Me Response — GET /auth/me

{
  "data": {
    "id": 1,
    "email": "user@example.com",
    "full_name": "John Doe",
    "phone": null,
    "timezone": "UTC",
    "status": "active",
    "verified": false,
    "two_factor": false,
    "created_at": "2026-05-08T01:25:23+00:00"
  }
}

Backend Setup (MonkeysLegion)

1. Install the Framework

composer require monkeyscloud/monkeyslegion:^2.0.8

Important: Version 2.0.8+ is required. Earlier versions have a bug in DatabaseUserProvider where typed properties (DateTimeImmutable, int, bool) throw TypeError during hydration from raw PDO strings.

2. Entity — `app/Entity/User.php`

<?php
declare(strict_types=1);

namespace App\Entity;

use MonkeysLegion\Auth\Contract\AuthenticatableInterface;
use MonkeysLegion\Query\Attribute\{Entity, Field, Id, Timestamps, Hidden, Fillable};

#[Entity(table: 'users')]
#[Timestamps]
class User implements AuthenticatableInterface
{
    #[Id]
    public private(set) int $id;

    #[Field(type: 'string', length: 255, unique: true)]
    #[Fillable]
    public string $email;

    #[Field(type: 'string', length: 255)]
    #[Fillable]
    public string $full_name;

    #[Field(type: 'string', length: 255)]
    #[Hidden]
    public string $password_hash;

    #[Field(type: 'integer', default: 1)]
    public int $token_version = 1;

    #[Field(type: 'datetime')]
    public private(set) \DateTimeImmutable $created_at;

    #[Field(type: 'datetime')]
    public private(set) \DateTimeImmutable $updated_at;

    // ── AuthenticatableInterface ──
    public function getAuthIdentifier(): int { return $this->id; }
    public function getAuthPassword(): string { return $this->password_hash; }
}

3. Controller — `app/Controller/Api/AuthController.php`

<?php
declare(strict_types=1);

namespace App\Controller\Api;

use App\Service\AuthService;
use MonkeysLegion\Http\Attribute\{Route, Prefix, Throttle, Authenticated};
use MonkeysLegion\Http\Message\Response;
use Psr\Http\Message\ServerRequestInterface;

#[Prefix('/api/v2/auth')]
class AuthController
{
    public function __construct(
        private readonly AuthService $auth,
    ) {}

    #[Route('POST', '/login', name: 'auth.login')]
    #[Throttle(max: 5, per: 60)]
    public function login(ServerRequestInterface $request): Response
    {
        $body = json_decode((string) $request->getBody(), true) ?? [];

        if (empty($body['email']) || empty($body['password'])) {
            return Response::json(['error' => 'Missing credentials'], 400);
        }

        $result = $this->auth->login($body['email'], $body['password']);

        if ($result === null) {
            return Response::json(['error' => 'Invalid credentials'], 401);
        }

        return Response::json([
            'data' => [
                'access_token'  => $result['access_token'],
                'refresh_token' => $result['refresh_token'],
                'token_type'    => 'Bearer',
                'expires_in'    => $result['expires_in'],
                'user' => [
                    'id'        => $result['user']->id,
                    'email'     => $result['user']->email,
                    'full_name' => $result['user']->full_name,
                ],
            ],
        ]);
    }

    #[Route('POST', '/register', name: 'auth.register')]
    #[Throttle(max: 3, per: 60)]
    public function register(ServerRequestInterface $request): Response
    {
        $body = json_decode((string) $request->getBody(), true) ?? [];

        if (empty($body['email']) || empty($body['password']) || empty($body['name'])) {
            return Response::json(['error' => 'Missing required fields'], 400);
        }

        // Check for duplicate email
        $existing = $this->auth->findByEmail($body['email']);
        if ($existing !== null) {
            return Response::json([
                'error'   => 'Validation failed',
                'details' => ['email' => 'Email already registered'],
            ], 422);
        }

        $result = $this->auth->register($body);

        return Response::json([
            'data' => [
                'message'       => 'Registration successful',
                'user'          => [
                    'id'        => $result['user']->id,
                    'email'     => $result['user']->email,
                    'full_name' => $result['user']->full_name,
                ],
                'access_token'  => $result['access_token'],
                'refresh_token' => $result['refresh_token'],
                'token_type'    => 'Bearer',
                'expires_in'    => $result['expires_in'],
            ],
        ], 201);
    }

    #[Route('GET', '/me', name: 'auth.me')]
    #[Authenticated]
    public function me(ServerRequestInterface $request): Response
    {
        // NOTE: The attribute is 'auth.user', NOT 'user'
        $user = $request->getAttribute('auth.user');

        return Response::json([
            'data' => [
                'id'         => $user->id,
                'email'      => $user->email,
                'full_name'  => $user->full_name,
                'status'     => $user->status,
                'created_at' => $user->created_at->format('c'),
            ],
        ]);
    }
}

Tip: Always use $request->getAttribute('auth.user') — the AuthenticationMiddleware sets the attribute as auth.user, not user.

Frontend: API Client

Create a reusable API client that handles JWT tokens, automatic refresh, and typed requests.

`src/lib/api.ts`

"use client";

const API_URL = process.env.NEXT_PUBLIC_API_URL || "http://localhost:8088";

interface ApiOptions {
  method?: string;
  body?: unknown;
  headers?: Record<string, string>;
  token?: string | null;
}

class ApiClient {
  private baseUrl: string;

  constructor(baseUrl: string) {
    this.baseUrl = baseUrl;
  }

  private getToken(): string | null {
    if (typeof window === "undefined") return null;
    return localStorage.getItem("mm_token");
  }

  async request<T = unknown>(path: string, options: ApiOptions = {}): Promise<T> {
    const { method = "GET", body, headers = {}, token } = options;
    const authToken = token ?? this.getToken();

    const res = await fetch(`${this.baseUrl}${path}`, {
      method,
      headers: {
        "Content-Type": "application/json",
        ...(authToken ? { Authorization: `Bearer ${authToken}` } : {}),
        ...headers,
      },
      body: body ? JSON.stringify(body) : undefined,
    });

    // Auto-refresh on 401
    if (res.status === 401) {
      const refreshed = await this.refreshToken();
      if (refreshed) {
        return this.request<T>(path, { ...options, token: this.getToken() });
      }
      this.clearTokens();
      throw new Error("Unauthorized");
    }

    if (!res.ok) {
      const err = await res.json().catch(() => ({ error: res.statusText }));
      throw new Error(err.error || err.message || "Request failed");
    }

    return res.json();
  }

  private async refreshToken(): Promise<boolean> {
    const refresh = typeof window !== "undefined"
      ? localStorage.getItem("mm_refresh")
      : null;
    if (!refresh) return false;

    try {
      const res = await fetch(`${this.baseUrl}/api/v2/auth/refresh`, {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ refresh_token: refresh }),
      });

      if (!res.ok) return false;

      const data = await res.json();
      if (data.data?.access_token) {
        localStorage.setItem("mm_token", data.data.access_token);
        if (data.data.refresh_token) {
          localStorage.setItem("mm_refresh", data.data.refresh_token);
        }
        return true;
      }
      return false;
    } catch {
      return false;
    }
  }

  private clearTokens() {
    if (typeof window !== "undefined") {
      localStorage.removeItem("mm_token");
      localStorage.removeItem("mm_refresh");
      window.location.href = "/login";
    }
  }

  // ── Auth Methods ──────────────────────────────────────────
  login(email: string, password: string) {
    return this.request<{
      data: {
        access_token: string;
        refresh_token: string;
        user: { id: number; email: string; full_name: string };
      };
    }>("/api/v2/auth/login", { method: "POST", body: { email, password } });
  }

  register(name: string, email: string, password: string, companyName: string) {
    return this.request<{
      data: {
        access_token: string;
        refresh_token: string;
        user: { id: number; email: string; full_name: string };
      };
    }>("/api/v2/auth/register", {
      method: "POST",
      body: { name, email, password, company_name: companyName },
    });
  }
}

export const api = new ApiClient(API_URL);

Frontend: Auth Context Provider

Wrap your app with AuthProvider to share auth state across all components.

`src/lib/auth.tsx`

"use client";

import React, {
  createContext, useContext, useEffect, useState, useCallback,
  type ReactNode,
} from "react";
import { api } from "./api";

interface User {
  id: number;
  name: string;
  email: string;
}

interface AuthState {
  user: User | null;
  loading: boolean;
  login: (email: string, password: string) => Promise<void>;
  register: (
    name: string, email: string, password: string, companyName: string
  ) => Promise<void>;
  logout: () => void;
}

const AuthContext = createContext<AuthState | null>(null);

export function AuthProvider({ children }: { children: ReactNode }) {
  const [user, setUser] = useState<User | null>(null);
  const [loading, setLoading] = useState(true);

  // On mount: validate stored token by calling /me
  useEffect(() => {
    const token = localStorage.getItem("mm_token");
    if (token) {
      api
        .request<{ data: { id: number; email: string; full_name: string } }>(
          "/api/v2/auth/me"
        )
        .then((res) =>
          setUser({
            id: res.data.id,
            email: res.data.email,
            name: res.data.full_name,
          })
        )
        .catch(() => {
          localStorage.removeItem("mm_token");
          localStorage.removeItem("mm_refresh");
        })
        .finally(() => setLoading(false));
    } else {
      setLoading(false);
    }
  }, []);

  const login = useCallback(async (email: string, password: string) => {
    const res = await api.login(email, password);
    localStorage.setItem("mm_token", res.data.access_token);
    localStorage.setItem("mm_refresh", res.data.refresh_token);
    // Map full_name → name for frontend consistency
    const u = res.data.user;
    setUser({ id: u.id, email: u.email, name: u.full_name });
  }, []);

  const register = useCallback(
    async (
      name: string, email: string, password: string, companyName: string
    ) => {
      const res = await api.register(name, email, password, companyName);
      localStorage.setItem("mm_token", res.data.access_token);
      localStorage.setItem("mm_refresh", res.data.refresh_token);
      const u = res.data.user;
      setUser({ id: u.id, email: u.email, name: u.full_name });
    },
    []
  );

  const logout = useCallback(() => {
    localStorage.removeItem("mm_token");
    localStorage.removeItem("mm_refresh");
    setUser(null);
    window.location.href = "/login";
  }, []);

  return (
    <AuthContext.Provider value={{ user, loading, login, register, logout }}>
      {children}
    </AuthContext.Provider>
  );
}

export function useAuth() {
  const ctx = useContext(AuthContext);
  if (!ctx) throw new Error("useAuth must be used within AuthProvider");
  return ctx;
}

Note: The API returns full_name but we map it to name in the frontend User interface for simplicity. This mapping happens in three places: login, register, and the /me response handler.

Wire Into Layout — `src/app/layout.tsx`

import { AuthProvider } from "@/lib/auth";

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <AuthProvider>{children}</AuthProvider>
      </body>
    </html>
  );
}

Frontend: Register Page

`src/app/(auth)/register/page.tsx`

"use client";

import { useState } from "react";
import { useRouter } from "next/navigation";
import Link from "next/link";
import { useAuth } from "@/lib/auth";

export default function RegisterPage() {
  const { register } = useAuth();
  const router = useRouter();
  const [name, setName] = useState("");
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [companyName, setCompanyName] = useState("");
  const [error, setError] = useState("");
  const [loading, setLoading] = useState(false);

  async function handleSubmit(e: React.FormEvent) {
    e.preventDefault();
    setError("");
    setLoading(true);

    try {
      await register(name, email, password, companyName);
      router.push("/login"); // Redirect to login after registration
    } catch (err: unknown) {
      setError(err instanceof Error ? err.message : "Registration failed");
    } finally {
      setLoading(false);
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <h1>Create Account</h1>

      {error && <div className="error">{error}</div>}

      <input type="text"     value={name}        onChange={(e) => setName(e.target.value)}        placeholder="Full name"    required />
      <input type="email"    value={email}       onChange={(e) => setEmail(e.target.value)}       placeholder="Email"        required />
      <input type="password" value={password}    onChange={(e) => setPassword(e.target.value)}    placeholder="Password"     required />
      <input type="text"     value={companyName} onChange={(e) => setCompanyName(e.target.value)} placeholder="Company name" required />

      <button type="submit" disabled={loading}>
        {loading ? "Creating..." : "Create Account"}
      </button>

      <p>Already have an account? <Link href="/login">Sign in</Link></p>
    </form>
  );
}

Frontend: Login Page

`src/app/(auth)/login/page.tsx`

"use client";

import { useState } from "react";
import { useRouter } from "next/navigation";
import Link from "next/link";
import { useAuth } from "@/lib/auth";

export default function LoginPage() {
  const { login } = useAuth();
  const router = useRouter();
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const [error, setError] = useState("");
  const [loading, setLoading] = useState(false);

  async function handleSubmit(e: React.FormEvent) {
    e.preventDefault();
    setError("");
    setLoading(true);

    try {
      await login(email, password);
      router.push("/"); // Redirect to dashboard
    } catch (err: unknown) {
      setError(err instanceof Error ? err.message : "Login failed");
    } finally {
      setLoading(false);
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <h1>Welcome Back</h1>

      {error && <div className="error">{error}</div>}

      <input type="email"    value={email}    onChange={(e) => setEmail(e.target.value)}    placeholder="Email"    required />
      <input type="password" value={password} onChange={(e) => setPassword(e.target.value)} placeholder="Password" required />

      <button type="submit" disabled={loading}>
        {loading ? "Signing in..." : "Sign in"}
      </button>

      <p>Don't have an account? <Link href="/register">Create one</Link></p>
    </form>
  );
}

Frontend: Protected Routes

Wrap dashboard pages with a layout that redirects unauthenticated users.

`src/app/(dashboard)/layout.tsx`

"use client";

import { useEffect } from "react";
import { useRouter } from "next/navigation";
import { useAuth } from "@/lib/auth";

export default function DashboardLayout({ children }: { children: React.ReactNode }) {
  const { user, loading } = useAuth();
  const router = useRouter();

  useEffect(() => {
    if (!loading && !user) {
      router.push("/login");
    }
  }, [user, loading, router]);

  if (loading) {
    return <div>Loading...</div>;
  }

  if (!user) return null;

  return <>{children}</>;
}

Using the User in Components

"use client";

import { useAuth } from "@/lib/auth";

export default function ProfileCard() {
  const { user, logout } = useAuth();

  return (
    <div>
      <h2>Welcome, {user?.name}</h2>
      <p>{user?.email}</p>
      <button onClick={logout}>Sign Out</button>
    </div>
  );
}

Token Refresh Flow

The API client handles token refresh automatically. Here's the sequence:

Browser makes a request (e.g. GET /api/v2/messages)
API Client attaches the stored Bearer token
If the API returns 401 Unauthorized (token expired):
- Client sends POST /api/v2/auth/refresh with the refresh token
- On success: stores the new tokens and retries the original request
- On failure: clears all tokens and redirects to /login

Token Lifetimes

Token	Lifetime	Storage Key
Access Token	30 minutes	`localStorage("mm_token")`
Refresh Token	7 days	`localStorage("mm_refresh")`

Warning: If both tokens are expired (user inactive for 7+ days), the client clears storage and redirects to /login.

Common Issues & Solutions

1. `TypeError: Cannot assign string to property ... of type DateTimeImmutable`

Cause: DatabaseUserProvider in MonkeysLegion ≤ 2.0.7 does raw assignment from PDO strings to typed properties.

Fix: Upgrade to monkeyscloud/monkeyslegion:^2.0.8 which includes castValue() type coercion in the hydrator.

2. `/me` returns `null` user — `$request->getAttribute('user')` is null

Cause: The AuthenticationMiddleware sets the attribute as auth.user, not user.

Fix:

- $user = $request->getAttribute('user');
+ $user = $request->getAttribute('auth.user');

3. `422 Unprocessable Content` on register

Cause: The email is already registered. The API returns:

{ "error": "Validation failed", "details": { "email": "Email already registered" } }

Fix: Use a different email, or parse the error details in the frontend to show a specific message.

4. `full_name` vs `name` mismatch

Cause: The API returns full_name but your frontend User interface expects name.

Fix: Map the field in every place you read user data:

setUser({ id: u.id, email: u.email, name: u.full_name });

5. CORS errors from `localhost:3000` → `localhost:8088`

Cause: The API needs CORS headers for cross-origin requests.

Fix: Add CORS middleware in your MonkeysLegion middleware stack:

// config/middleware.mlc
MonkeysLegion\Http\Middleware\CorsMiddleware::class

Or set the environment variable:

CORS_ORIGINS=http://localhost:3000

6. Page redirects to `/login` on refresh despite being logged in

Cause: The /me endpoint crashes (often the DateTimeImmutable bug), so the auth provider clears tokens and sets user = null.

Fix: Upgrade MonkeysLegion to 2.0.8+ and verify /me works:

curl -s http://localhost:8088/api/v2/auth/me \
  -H "Authorization: Bearer YOUR_TOKEN"

Quick Reference

# Register a user via curl
curl -X POST http://localhost:8088/api/v2/auth/register \
  -H "Content-Type: application/json" \
  -d '{
    "name": "John Doe",
    "email": "john@example.com",
    "password": "securepass123",
    "company_name": "Acme Inc."
  }'

# Login
curl -X POST http://localhost:8088/api/v2/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email": "john@example.com", "password": "securepass123"}'

# Get current user
curl http://localhost:8088/api/v2/auth/me \
  -H "Authorization: Bearer <access_token>"

# Refresh token
curl -X POST http://localhost:8088/api/v2/auth/refresh \
  -H "Content-Type: application/json" \
  -d '{"refresh_token": "<refresh_token>"}'

MonkeysLegion

MonkeysLegion 2.0 Is Released — Introducing Apex AI and a Faster PHP Runtime

Jorge Peraza — Tue, 28 Apr 2026 22:43:51 +0000

MonkeysLegion 2.0 is officially released.

This is more than a framework update. It is a full architectural step forward for the MonkeysLegion ecosystem: a faster runtime, a cleaner PHP 8.4+ foundation, a stronger modular package structure, and a new AI orchestration layer built directly for modern PHP applications.

PHP has always been one of the most productive languages on the web.

It powers SaaS platforms, APIs, internal tools, content systems, enterprise applications, dashboards, automation workflows, and products used by millions of people every day.

But modern teams are building in a different environment now.

They need faster boot times.

They need clean architecture.

They need APIs by default.

They need cloud-native deployment.

They need observability.

They need DevOps-friendly workflows.

They need AI-ready applications.

They need developer experience without hidden runtime magic.

That is why we are releasing MonkeysLegion 2.0.

MonkeysLegion 2.0 is built for developers and teams who want the clarity of raw PHP, the structure of a serious framework, the productivity of a modular ecosystem, and the performance profile of a runtime that gets out of the way.

Why MonkeysLegion 2.0 Matters

Laravel built an incredible ecosystem.

Forge, Vapor, Nova, Cashier, queues, jobs, billing tools, starter kits, and one of the largest PHP communities in the world. If you need a batteries-included SaaS starter, Laravel is hard to beat.

Symfony powers some of the most mission-critical enterprise systems on earth.

Its profiler, debug toolbar, reusable components, release discipline, and enterprise credibility are best-in-class.

MonkeysLegion is built for a different moment.

A moment where teams want:

Raw throughput
PHP 8.4+ architecture
Attribute-first development
Minimal runtime overhead
Clean dependency injection
Modular packages
API-first structure
DevOps automation
Cloud-native deployment
Observability
AI orchestration
Enterprise-ready foundations

No unnecessary heavy boot process.

No runtime proxies.

No hidden magic.

No fighting the framework.

Just your code, clean architecture, and a framework designed to move fast from local development to production.

What Changed in 2.0

MonkeysLegion 2.0 is a full architectural pass across the framework and package ecosystem.

The release focuses on:

PHP 8.4+ native architecture
Attribute-first routing and configuration
Compiled dependency injection
Typed MLC configuration
PSR-compliant HTTP and middleware layers
Production-ready security middleware
OpenAPI-first API development
A modular package ecosystem
Better developer tooling
Faster runtime behavior
AI orchestration with Apex AI

The goal is simple:

Make PHP feel modern again — fast, clean, modular, typed, observable, deployable, and ready for AI-native applications.

PHP 8.4+ Native Architecture

MonkeysLegion 2.0 is designed around modern PHP instead of legacy conventions.

The framework is moving deeper into:

Strict types
PHP attributes
Property hooks
Constructor injection
Typed configuration
Compiled containers
PSR standards
Clean service boundaries
Lightweight runtime behavior

The main idea is that your application should be readable from the code itself.

Routes should be visible.

Services should be explicit.

Configuration should be understandable.

Controllers should be clean.

Database logic should be predictable.

Deployment should not require guessing.

MonkeysLegion 2.0 keeps the code close to the developer.

Attribute-First Development

MonkeysLegion 2.0 uses PHP attributes as a first-class architecture pattern.

Routes, validation rules, service providers, commands, middleware, and AI tools can be declared close to the code they affect.

Example:

use MonkeysLegion\Http\Attributes\Route;
use Psr\Http\Message\ResponseInterface;

final class ProjectController
{
  #[Route('/api/projects', methods: ['GET'])]
  public function index(): ResponseInterface
  {
    return $this->json($this->projects->list());
  }
}

This makes applications easier to understand.

You open a controller and immediately see:

The endpoint
The HTTP method
The handler
The dependencies
The response flow

For teams building APIs, dashboards, SaaS platforms, internal tools, CMS platforms, or microservices, this matters.

Compiled Dependency Injection

Dependency injection should help developers, not confuse them.

MonkeysLegion 2.0 continues the direction of a clean, predictable container that favors explicit services, typed dependencies, and production compilation.

The goal is not to create a magical container that hides everything.

The goal is to make dependency management simple:

use Psr\Log\LoggerInterface;

final class ProjectService
{
  public function __construct(
    private ProjectRepository $projects,
    private LoggerInterface $logger,
  ) {}
}

Your services are clear.

Your dependencies are explicit.

Your application is easier to test.

Your architecture is easier to reason about.

In production, the framework can compile container definitions so applications avoid unnecessary runtime reflection on the hot path.

That is one of the core performance principles behind MonkeysLegion 2.0.

Performance Is a Core Feature

Performance is not a marketing layer in MonkeysLegion 2.0.

It is part of the architecture.

The framework is designed around zero-magic PHP objects, compiled routing, compiled dependency injection, attribute discovery at cache/build time, and a lean PSR middleware pipeline.

The performance direction is based on several key principles:

Zero-magic architecture

Entities, DTOs, resources, and enums should behave like plain PHP objects.
No proxy-heavy runtime model

The framework avoids forcing every application through runtime proxy layers.
Compiled routing and DI

Discovery happens before production runtime where possible.
Lean middleware pipeline

Middleware should be powerful, but the request path should remain predictable.
PHP 8.4+ features

The framework embraces modern PHP language improvements instead of simulating them with legacy patterns.

On the current MonkeysLegion benchmarks, the framework is positioned around major improvements over heavier runtime approaches:

Entity creation: around 140× faster than Laravel
DTO construction: around 60× faster than Laravel
Enum operations: around 25× faster than Laravel
Resource serialization: around 5.5× faster than Laravel
HTTP throughput: around 12.5K requests/sec vs Laravel’s ~2.1K requests/sec
Cold boot memory: significantly lower than heavier full-stack boot processes

These benchmark numbers should be understood in context: benchmarks depend on hardware, PHP version, configuration, JIT, opcache, test harness, and workload.

But the architectural direction is clear:

MonkeysLegion 2.0 is designed to reduce runtime overhead and make high-performance PHP applications easier to build.

API-First by Default

Modern applications are API-driven.

A backend is rarely just a backend anymore. It may serve:

A web app
A mobile app
A dashboard
A CMS
A CLI
A partner integration
An AI workflow
A microservice
A third-party API consumer

MonkeysLegion 2.0 is designed with APIs as a first-class concern.

The framework and skeleton are moving toward a complete API foundation with support for:

PSR-7 and PSR-15 HTTP handling
Middleware pipelines
JWT authentication
RBAC
API keys
Validation
DTO binding
OpenAPI documentation
Swagger UI
Rate limiting
Security headers
Request IDs
CORS
Trusted proxies

That means teams can build real production APIs without stitching together half a dozen disconnected tools.

Introducing Apex AI

The biggest new direction in the MonkeysLegion ecosystem is Apex AI.

Apex AI is an AI orchestration package for PHP 8.4+.

It is not just another OpenAI wrapper.

Apex AI is designed to bring production-ready AI infrastructure into PHP with a clean, framework-native developer experience.

The goal is simple:

Build AI-powered applications in PHP without stitching together multiple disconnected tools.

Apex AI introduces a unified way to work with multiple AI providers, route requests intelligently, build pipelines, manage cost, use tools, stream responses, and create real AI workflows inside PHP applications.

What Apex AI Brings to PHP

Apex AI is designed around the needs of real production applications.

It focuses on:

Unified AI provider interface
Multi-provider routing
OpenAI support
Anthropic support
Google AI Studio support
Vertex AI support
Ollama/local model support
Smart model routing
Fallback chains
Declarative AI pipelines
Guardrails
Structured outputs
Tool calling with PHP attributes
Streaming with Server-Sent Events
Agent-style workflows
Multi-agent crews
Memory strategies
Cost tracking
Budget controls
Model Context Protocol support
Clean integration with MonkeysLegion applications

This matters because AI development is moving beyond simple prompt calls.

Modern AI applications need:

Routing
Retries
Fallbacks
Guardrails
Tool execution
Structured responses
Memory
Context management
Cost controls
Streaming
Evaluation
Observability

Apex AI brings these ideas into PHP as part of the MonkeysLegion ecosystem.

AI-Native PHP Applications

PHP developers should not need to leave PHP to build serious AI workflows.

Many companies already have PHP backends, PHP teams, PHP infrastructure, PHP CMS platforms, PHP APIs, and PHP business logic.

The question is not whether PHP can be used for AI applications.

The question is whether the ecosystem gives PHP developers the right tools.

Apex AI is built around that belief.

With Apex AI, a PHP application can become:

An AI-powered CMS
An AI-assisted dashboard
A document processing system
A content generation platform
A support automation tool
An internal agent workflow
A SaaS product with AI features
A developer platform with AI orchestration
A backend that routes between cloud and local models

This is where MonkeysLegion 2.0 becomes more than a framework release.

It becomes the foundation for AI-native PHP development.

Example: Tool Calling with Attributes

Apex AI is designed to feel natural inside modern PHP.

Instead of forcing AI workflows into disconnected configuration files, tools can be represented as PHP code.

Example:

use MonkeysLegion\Apex\Attributes\Tool;

final class ProjectTools
{
  #[Tool(
    name: 'find_project',
    description: 'Find a project by ID and return its current status.'
  )]
  public function findProject(string $id): array
  {
    return $this->projects->findStatus($id);
  }
}

This keeps AI tools close to the domain logic of the application.

The result is easier to read, easier to test, and easier to maintain.

Built for SaaS, Internal Tools, and Enterprise Platforms

MonkeysLegion 2.0 is not only for small apps.

It is being designed for companies building:

SaaS platforms
Internal business tools
Developer portals
Admin dashboards
API platforms
Automation systems
AI-enabled products
Cloud-native services
CMS-driven websites
Enterprise applications

Many companies do not need another heavy framework that assumes one way of working.

They need a framework that lets them move fast while keeping the codebase clean.

MonkeysLegion gives teams a structured foundation without forcing unnecessary complexity.

Apex AI extends that foundation into AI-powered product development.

Modular Ecosystem

One of the most important ideas behind MonkeysLegion is modularity.

You should not need to install a giant framework if you only need one part of it.

MonkeysLegion is moving toward a package ecosystem where teams can use the pieces they need:

Core
Router
Dependency Injection
HTTP
Security
Database
Query Builder
Migration
Authentication
Validation
Internationalization
Telemetry
DevTools
CLI
GraphQL
Apex AI
Cloud tooling
Testing utilities
CMS-related packages

This package-first approach makes the framework flexible.

Small projects can stay small.

Large projects can grow with structure.

Enterprise teams can standardize around the packages that matter to them.

Telemetry and Observability

Modern applications need visibility.

It is not enough for a framework to run code. Teams need to understand what is happening in production.

MonkeysLegion 2.0 treats observability as part of the developer platform, not as an afterthought.

That includes visibility into:

Request performance
Application health
Security events
API usage
Background processes
AI requests
Model routing
Provider fallbacks
Cost tracking
Latency
Error rates

This becomes even more important with Apex AI.

AI applications need observability because model behavior, token usage, latency, provider availability, and costs all affect production reliability.

Cloud-Native From the Start

MonkeysLegion is not being designed only for local development.

It is being built with deployment in mind.

Modern teams need applications that can move from local development to containers, servers, CI/CD pipelines, and cloud environments without massive rewrites.

That matters because software delivery is no longer just about writing PHP classes.

It is about the full lifecycle:

Build
Test
Package
Deploy
Monitor
Scale
Improve

MonkeysLegion 2.0 is being shaped around that complete workflow.

A Better Developer Experience Without Heavy Runtime Cost

Developer experience matters.

But developer experience should not require hiding everything behind magic.

MonkeysLegion 2.0 is focused on a balanced philosophy:

Give developers speed, structure, and useful defaults — without making the runtime heavy or the code difficult to understand.

That means:

Clear file structure
Fast boot process
Explicit dependencies
Attribute-based configuration
Useful CLI commands
Strong defaults
Modular packages
Production-ready skeleton
Easy local setup
Cloud-ready conventions
AI-ready workflows

The framework should feel productive without becoming opaque.

Inspired by the Best, Built With a Different Philosophy

MonkeysLegion is not trying to replace Laravel or Symfony.

They are excellent frameworks with massive ecosystems and proven track records.

But not every team wants the same tradeoffs.

Laravel is great when you want a large ecosystem and rapid application scaffolding.

Symfony is great when you want enterprise components, stability, and deep configurability.

MonkeysLegion is for teams that want:

A lighter framework
Less magic
More direct control
Modern PHP-first architecture
Fast APIs
Modular packages
Cloud-native defaults
Strong developer tooling
Clean enterprise structure
AI orchestration built into the ecosystem

It is not about copying the old model.

It is about building a framework for where PHP is going next.

Built as an Ecosystem, Not Just a Framework

MonkeysLegion 2.0 is part of a bigger vision.

The framework is the foundation, but the ecosystem is the real goal.

That ecosystem includes:

MonkeysLegion Framework
MonkeysLegion Skeleton
MonkeysLegion DevTools
MonkeysLegion GraphQL
MonkeysLegion Telemetry
MonkeysLegion Apex AI
MonkeysCMS
Cloud deployment tooling
AI-ready developer workflows
Enterprise package roadmap

This matters because modern teams do not only need a router or container.

They need a complete development platform.

MonkeysLegion is moving toward that full-stack ecosystem while keeping the core lightweight and modular.

MonkeysCMS and the Future of AI-Ready Content Platforms

MonkeysLegion also powers the direction behind MonkeysCMS.

MonkeysCMS is being designed as a modern, code-first CMS built on top of the MonkeysLegion framework.

This is one of the strongest examples of why MonkeysLegion matters.

A framework is not only valuable when it can serve a JSON response.

It becomes powerful when it can support real products:

CMS platforms
Admin systems
API products
AI workflows
Enterprise dashboards
Developer platforms

With Apex AI, the CMS direction becomes even stronger.

Content systems are one of the clearest places where AI can help:

Generate drafts
Improve content
Critique content
Translate content
Classify content
Extract metadata
Build summaries
Power editorial assistants
Automate workflow tasks

MonkeysLegion 2.0 is the foundation for that future.

Open Source and Community-Driven

MonkeysLegion is open source.

The project started from a simple belief:

Modern PHP projects deserve a framework that is fast, cloud-native, AI-ready, and clear to work with.

Version 2.0 is a call to developers, agencies, founders, and engineering teams:

Come test it.

Break it.

Improve it.

Build with it.

Open issues.

Submit pull requests.

Share ideas.

Help shape the next generation of PHP tooling.

Who MonkeysLegion 2.0 Is For

MonkeysLegion 2.0 is for developers and teams who want to build serious software with PHP.

It is for the solo founder building a SaaS product.

It is for the agency building multiple client platforms.

It is for the backend engineer building APIs.

It is for the enterprise team that needs maintainable internal tools.

It is for the startup that wants speed without technical debt.

It is for the developer who loves PHP but wants a framework that feels modern, clean, fast, and ready for AI-powered products.

It is for builders who want control.

Getting Started

The easiest way to start is with the official skeleton.

composer create-project monkeyscloud/monkeyslegion-skeleton my-app
cd my-app
composer serve

From there, you can begin building APIs, services, dashboards, internal tools, SaaS applications, AI workflows, CMS platforms, or custom products using the MonkeysLegion architecture.

Useful links:

Website: monkeyslegion.com
Release article: monkeyslegion.com/news/2026-04/monkeyslegion-2-announcing
Framework: github.com/MonkeysCloud/MonkeysLegion
Skeleton: github.com/MonkeysCloud/MonkeysLegion-Skeleton

Final Thoughts

MonkeysLegion 2.0 is built with a clear belief:

PHP is not done.

PHP is still one of the most important languages on the web. But the ecosystem needs new ideas, new tooling, and new frameworks that match how software is built today.

MonkeysLegion is our answer.

A feather-light framework.

A modular ecosystem.

A cloud-native foundation.

A clean architecture for modern PHP.

A faster runtime path.

A developer platform built for speed, clarity, and scale.

An AI orchestration layer for the next generation of PHP applications.

Version 2.0 is not the finish line.

It is the foundation.

Welcome to MonkeysLegion 2.0.

Welcome to Apex AI.

Let’s build the next era of PHP.