Cloudflare’s DeepSeek V4 Release Shows How to Build 1M-Token Agent Workspaces with Workers and R2

Cloudflare has put DeepSeek V4 Pro 0813 and DeepSeek V4 Flash 0731 on Workers AI. Both models support a full 1,048,576-token context window, thinking mode and multi-turn function calling. Cloudflare is explicitly positioning them for large codebases, long-horizon agent workflows and multi-step reasoning.[1]

For AI engineers, that is more than another model listing. It creates a practical stack for repository-scale agents:

Workers AI runs DeepSeek V4 Pro or Flash.
Workers receives the task, assembles context and controls tools.
R2 stores repositories, documents, checkpoints and generated artifacts.
Cloudflare Agents carries durable state, workflows and recovery.
AI Gateway gives the model route an observable control surface.

That combination is particularly relevant to the direction of ChaseOS. It could provide an edge-native lane for large technical dossiers, repository analysis, long-running engineering tasks and inspectable phase handovers without making the primary runtime depend on one model.

The point is not to move everything onto Cloudflare. The point is to understand what this release makes possible and where each part of the stack belongs.

What Cloudflare actually released

Cloudflare’s canonical changelog names two Workers AI models:[1]

@cf/deepseek-ai/deepseek-v4-pro-0813
@cf/deepseek-ai/deepseek-v4-flash-0731

Both expose the same maximum context window: 1,048,576 tokens. Both support reasoning and function calling. They are available through a Workers AI binding, Cloudflare’s OpenAI-compatible endpoint, the REST API or AI Gateway.[1]

They serve different operating roles.

DeepSeek V4 Flash 0731: the default long-context route

Cloudflare calls Flash the faster, lower-cost sibling and says this release supersedes its earlier preview with improved agentic capabilities.[1]

The current model page lists:

1,048,576-token context;
reasoning;
function calling;
$0.44 per million input tokens;
$1.32 per million output tokens;
$0.014 per million cached input tokens.[3]

Flash is the natural first route for frequent work such as:

searching a large repository;
connecting an issue to the correct files and tests;
analysing long logs or CI histories;
converting a technical dossier into a structured task packet;
maintaining a long-running agent plan across multiple tool calls;
producing an initial implementation plan before a more expensive review.

DeepSeek V4 Pro 0813: the visual and higher-value route

Pro exposes the same listed context ceiling but adds vision support. Cloudflare currently marks it beta and lists:[2]

1,048,576-token context;
reasoning;
function calling;
vision;
$1.32 per million input tokens;
$3.96 per million output tokens;
$0.044 per million cached input tokens.

That makes Pro more relevant when the engineering evidence is not text-only:

a UI regression with screenshots;
an architecture review involving diagrams;
a browser-agent failure with visual traces;
OCR mixed with repository evidence;
a high-value code change where an additional model route is cheaper than a failed deployment.

Both models require Workers Paid or prepaid AI Gateway credits according to Cloudflare.[1][2][3]

Why one million tokens matters to agent engineers

Most model announcements discuss context as a chat feature. Harness engineers should think of it as a working-set ceiling.

A million-token run can potentially hold:

a substantial repository snapshot;
issue and pull-request history;
architecture decisions;
test output;
API specifications;
runbooks;
agent plans and previous tool results;
screenshots or diagrams on the Pro route.

This reduces one common failure mode: an agent solves the fragment it can see while missing the contract, dependency or historical decision sitting outside its context.

But it introduces another risk. If the harness simply uploads everything, the model gets a large but badly defined workspace. Relevant evidence competes with stale files, generated output, secrets, abandoned plans and unrelated history.

The better question is not:

Can this repository fit inside one million tokens?

It is:

What verified working set gives the model enough context to finish this exact job?

That is where R2 and Workers become useful.

R2 gives the agent a workspace outside the prompt

R2 is Cloudflare’s object-storage layer. Cloudflare says it stores unstructured data without the egress bandwidth fees associated with typical cloud storage services.[5]

For an agent system, R2 should not be described vaguely as “memory.” It can be something more useful: a durable, inspectable workspace.

A repository-scale run can store:

r2://agent-sources/{source_hash}/repository.tar.zst
r2://agent-sources/{source_hash}/manifest.json
r2://runs/{run_id}/task-packet.json
r2://runs/{run_id}/selected-context.json
r2://runs/{run_id}/checkpoints/plan.json
r2://runs/{run_id}/checkpoints/implementation.json
r2://runs/{run_id}/artifacts/candidate.patch
r2://runs/{run_id}/verification/test-results.json
r2://approvals/{approval_id}/packet.json
r2://receipts/{run_id}/execution.json
r2://receipts/{run_id}/readback.json

The repository object is the source. The manifest tells the harness what exists. The selected-context record shows what the model actually received. Checkpoints make a long task resumable. Verification and receipt objects prove what happened afterward.

A Worker can read and write R2 objects through a bucket binding.[6] That means context does not need to arrive as one giant browser upload or remain trapped in an opaque conversation.

Workers turns storage and models into a harness

Workers should sit between the external request, R2 and Workers AI.

Its job is to make the run explicit:

Authenticate the caller.
Validate the task packet.
Resolve the approved R2 source objects.
Build the context manifest.
Select Flash or Pro.
Expose only the tools permitted for that phase.
Enforce token, tool-turn and time budgets.
Write checkpoints and artifacts to R2.
Run deterministic verification.
Require approval before protected actions.
Read the destination back and write a receipt.

A simplified binding configuration could expose both AI and R2 to the Worker:

{
  "ai": {
    "binding": "AI"
  },
  "r2_buckets": [
    {
      "binding": "AGENT_WORKSPACE",
      "bucket_name": "agent-workspace"
    }
  ]
}

The model router stays small:

const ROUTES = {
  flash: "@cf/deepseek-ai/deepseek-v4-flash-0731",
  pro: "@cf/deepseek-ai/deepseek-v4-pro-0813",
} as const;

async function runEngineeringPhase(
  env: Env,
  packet: TaskPacket,
) {
  const route = chooseRoute(packet);
  const context = await buildContextFromR2(
    env.AGENT_WORKSPACE,
    packet,
  );

  assertContextPolicy(context, packet);
  assertRunBudget(packet, route);

  return env.AI.run(ROUTES[route], {
    messages: context.messages,
    tools: toolsForPhase(packet.phase),
  });
}

The important code is not the two model IDs. It is buildContextFromR2, assertContextPolicy, assertRunBudget and toolsForPhase. Those functions define the harness.

Seven practical uses for this stack

1. Repository archaeology

An engineer can upload or synchronise a repository snapshot into R2. A deterministic indexer produces a file manifest, symbol map, dependency graph and recent-change summary.

Flash receives the manifest first. It selects the likely files for the task and explains why. The Worker retrieves those files and expands context only when required.

This gives the model repository-scale awareness without blindly pasting every file into the prompt.

2. Long-running migrations

Framework upgrades, database migrations and CLI consolidations rarely fit into one model turn. They need discovery, planning, staged implementation, tests and rollback.

Each phase can write a checkpoint to R2:

{
  "phase": "implementation-2-of-5",
  "completed": ["schema adapter", "compatibility tests"],
  "pending": ["worker migration", "deployment rehearsal"],
  "acceptance_checks": ["unit", "integration", "rollback"],
  "source_hash": "sha256:...",
  "artifact_hash": "sha256:..."
}

If a run stops, another model can continue from the checkpoint rather than reconstructing state from a chat transcript.

3. Multimodal debugging

The Pro route can combine screenshots with code, logs and test evidence. A browser or desktop agent can write screenshots and DOM captures to R2, then pass the exact referenced objects to the model.

The final fix still needs deterministic checks and visual readback. Vision helps interpret evidence; it does not prove the UI is fixed.

4. Technical-document workspaces

R2 can hold specifications, PDFs, diagrams, meeting decisions and implementation contracts. A Worker can build a source-bound context pack for a documentation or architecture agent.

This is useful for AI engineers working across long design histories where the model must preserve exact terminology and cite the correct source.

5. Evaluation and model comparison

The same R2 fixture can run through Flash, Pro and another provider. The harness records accepted output, retries, tool calls, latency, token use and human correction.

That gives engineers a real answer to “which model is cheaper?” Cost per token becomes cost per accepted task.

6. Agent-generated artifacts

An agent can produce patches, reports, diagrams, spreadsheets or media into a staged R2 prefix. The Worker computes hashes and builds an approval packet.

Approved artifacts move to the next stage. Rejected artifacts remain attached to the run but never reach a public destination.

7. External developer agents

A public Worker endpoint can accept a constrained task without exposing the internal runtime. The Worker authenticates the caller, applies rate limits, retrieves only allowed objects and returns a receipt-linked result.

That creates a path to agent services for developers without giving a model blanket access to ChaseOS internals.

A concrete ChaseOS pilot

The release is directly relevant to ChaseOS because it could support an isolated repository and dossier engineering lane.

The pilot should be narrow.

Input

one repository snapshot;
one issue or feature dossier;
one acceptance contract;
an explicit list of allowed tools;
no production credentials;
no deployment authority.

Cloudflare lane

Request
  -> Worker intake
  -> R2 source manifest
  -> DeepSeek V4 Flash navigation
  -> bounded source expansion
  -> Flash or Pro implementation plan
  -> candidate artifact in R2
  -> deterministic verification
  -> independent review
  -> human approval
  -> handover back to ChaseOS

Model routing

Use Flash by default. Escalate to Pro when:

the task includes screenshots or diagrams;
Flash fails a verifier more than once;
the change crosses a high-risk boundary;
ambiguity remains after repository navigation;
the expected cost of failure is higher than the added model cost.

Evidence returned to ChaseOS

The lane should return:

source manifest and hashes;
selected-context manifest;
model and pricing route;
tool-call trace;
checkpoints;
candidate artifact hash;
test and review results;
human approval reference;
execution and readback receipts where applicable.

That is more valuable than returning a message saying “task completed.”

What not to do

A million-token window can encourage bad architecture. Avoid these shortcuts:

Do not load a bucket directly into the model

R2 may contain unrelated runs, secrets, customer exports or stale artifacts. The Worker must select exact objects for the exact task.

Do not use the model’s summary as the checkpoint

A checkpoint should be a typed record with source and artifact hashes, completed steps and remaining acceptance checks.

Do not let function calling define the permission model

The fact that a model can call a function does not mean that function should exist for every run. Tool visibility belongs to the harness.

Do not confuse context size with reliable recall

Measure whether the model retrieves and uses the decisive evidence as irrelevant context grows.

Do not hard-code ChaseOS to DeepSeek

Put the models behind role contracts. The repository navigator, visual reviewer or implementation planner should be replaceable without rewriting the workflow.

The evaluation that matters

For every test task, record:

selected model;
source tokens and cached tokens;
output tokens;
context objects included;
tool calls;
verifier failures;
retries;
elapsed time;
human correction time;
accepted or rejected result.

The comparison should answer:

Does Flash navigate large codebases accurately enough to be the default?
Does Pro’s vision improve visual-debug tasks enough to justify the cost?
Does selective R2 retrieval outperform loading the entire repository?
Can the agent resume from a checkpoint without losing constraints?
Can every final claim be tied to a source, test or readback receipt?

If the answer is yes, Cloudflare becomes a useful execution lane. If not, the architecture still preserves the source objects and evaluation evidence needed to change models.

Why this release matters

DeepSeek V4 Pro and Flash are the first Workers AI models that Cloudflare lists with a full one-million-token context window.[1] That gives agent engineers a serious new working-set ceiling on an edge platform that already has compute, object storage, durable agent primitives and model routing.

For AI engineers, the opportunity is repository-scale reasoning without building every infrastructure layer from scratch.

For harness engineers, the opportunity is more important: keeping the repository, checkpoints, permissions, tools, verification and receipts outside the model.

For ChaseOS, this creates a concrete pilot path for long-horizon engineering and dossier work. R2 can be the workspace. Workers can be the gate. DeepSeek can be the reasoning route. ChaseOS can remain the system that defines the contract, chooses the lane and verifies the outcome.

That is the useful interpretation of this announcement. Not one million tokens of autonomy. One million tokens of working context inside a controlled engineering system.

Cloudflare's DeepSeek V4 Release Shows How to Build 1M-Token Agent Workspaces with Workers and R2