Particle-1 reaches coding agents through two access routes

Particle’s [October 28 launch](https://particle.ai/blog/introducing‑particle‑1) makes Particle‑1 available through its API for a user’s own harness or agent workflow. The release focuses on software engineering; other domains are planned. Particle says the model is post‑trained on DeepSeek V4.1 Flash. For a developer considering the release, the first decision is where a request should go. A team evaluating the direct provider route can begin by identifying the application that will send requests and the account responsible for that connection. An existing gateway workflow presents a different integration decision: selecting a newly listed model within that route. Keeping those decisions explicit makes an evaluation easier to reproduce. A useful run record names the provider route, the model identifier actually configured and the engineering task assigned. A result labelled only with the model’s name leaves a future reviewer to reconstruct which connection was used.

[Vercel’s October 28 changelog](https://vercel.com/changelog/particle‑1‑is‑now‑available‑on‑ai‑gateway) lists Particle‑1 on AI Gateway as `particle/particle‑1` and describes a 1M‑token context window. It presents AI SDK and coding‑agent setup routes. Those are Vercel’s published integration instructions, not an OpenTools account or setup test. The provider/model name is useful precisely because it is concrete: it identifies the model selection shown for the gateway. It should not be silently substituted for an unverified identifier in a different provider interface. Read the instructions for the chosen route before changing a production configuration. A large context specification also leaves an application decision to make. Decide which repository material and prior task history are necessary for the current change, and record what was supplied. Context capacity alone does not establish that an agent has the right files, understands their relationships or has permission to modify them.

A coding workflow has an acceptance problem as well as a connection problem. For a proposed change, identify the files it may affect, the checks that demonstrate the intended behavior and the work that must remain outside its scope. Preserve the resulting patch and check results alongside the route and model selection. That record lets a reviewer distinguish a completed change from a plausible explanation of one. It also avoids treating the length of an answer as evidence that the requested behavior was delivered. These are prospective evaluation questions; OpenTools did not call Particle’s API, run Vercel’s setup command or test the model. The current announcements provide two ways to start that evaluation. Choosing one route and one well‑defined engineering task is a more useful first step than assuming that the same model name makes different integrations interchangeable. Archival photograph of two programmers at a computer, September 30, 2011. It illustrates software‑work review, not a Particle‑1 session, model interface or tested result. Photo: [Calqui / Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Pair_Programming.jpg), [CC BY‑SA 3.0](https://creativecommons.org/licenses/by‑sa/3.0/). Cropped for display; the adapted image remains under the same license.