Particle 1: a complete analysis of the model based on testing four projects

Particle 1 is a language model for agentic work with code and tools. The author tested it on four related projects: a procedural 3D model of a knight, a fortress, a browser game, and a website. The experiment took 3 hours 37 minutes and cost 1 dollars 65 cents. Three of the four projects encountered error 413, while the final ratings remained average.

This material reflects the author's personal test, not an independent benchmark of Particle AI. The prices, specifications, and conclusions below are presented as information and assessments from that experiment.

What exactly was tested

The author used one shared story about a knight who stands guard for 704 nights. First, the model had to create the knight himself. The character then moved into a game, while the model's story and images were used on a website. This scenario tests not only the ability to write code but also the preservation of a visual concept across multiple tasks.

The workflow was simple: the author submitted a prompt, waited for the first version, checked the result, and requested one refinement when there were serious shortcomings. The time and cost of the first version, as well as the refinement parameters, were tracked separately. This approach is closer to user prototyping than to a laboratory comparison of models: quality depended on a single scenario, browser, prompt wording, and manual evaluation.

The tests used Particle 1 from Particle AI. The author describes it as a fine-tuned DeepSeek V4.1 Flash focused on reducing the costs of reasoning and tool calls. The model was run through OpenRouter and Open Code, without an OpenRouter subscription.

Particle 1: capabilities and price stated in the test

According to the author, Particle 1 works with a context of approximately 1 million tokens and produces up to 131 000 tokens. The model accepts text and images, and its reasoning level can be adjusted from zero to maximum. These figures should be understood in the article as specifications reported by the test's author: there is no independent confirmation in the source materials.

The author gave the following call pricing: 5 cents per 1 million input tokens, 50 cents per 1 million output tokens, and 0,3 cents for cache. The low price is evident in the experiment's results, but it does not eliminate the time costs of checking, rerunning, and fixing code that has already been created.

The author was unable to access benchmarks, so he provisionally rated the model's power as average. This is not the result of standardized testing but a subjective assessment based on four projects and their visual quality.

Results of the four projects

The total result for the four projects was 1 dollars 65 cents and 3 hours 37 minutes.

The author considers the fortress the strongest 3D result. It received 7,5 out of 10, although the final rating was limited by problems with the readability of details.

3D knight model

The prompt called for a procedural model assembled with code, without ready-made files or images. It specified a closed helmet, a bell on the shoulder, a shield with an emblem, a heraldic cloak, a guard stance, walking, and a sword swing.

The author gave the first version 5 out of 10. The main elements were present, but the figure resembled a mannequin made of tubes, the head looked oversized, the metal was too light, and some shield details were incorrect. After refinement, the metal became darker, the helmet more proportionate, the body more massive, and separate plates appeared on the boots.

The correction also created new problems. The emblem disappeared from the front of the shield and tabard, and the guard stance became less expressive. The cloak remained a flat trapezoid with almost no folds, while the dent and crack details on the bell were difficult to make out. The walking and sword-swing animations remained in the model.

Fortress of Nine Bells

The second prompt described an 3D diorama with a plot of land, a road, a bridge, a gate, walls, towers, an open bell tower, nine places for bells, trees, rooks, and two banners bearing the knight's coat of arms.

The first version cost 23 cents and took 34 minutes. The entrance was blocked by a wall, the road hung over the edge of the plot, and the birds, with rectangular wings, looked like little airplanes. After refinement, the passage was opened, the paved floor led inward, the road correctly connected to the bridge, a rocky ledge appeared, and the birds looked more realistic.

The code provided nine places for bells, but they were difficult to count and the one empty place was hard to see in the overall view. The cracks on the bells were indistinguishable, and the gate grille blended into the shadow. The scene was the best of the four specifically because of its composition and overall appearance, not because every detail in the prompt was executed precisely.

Visual Hold the Torch game

The game cost 42 cents and took 54 minutes to create. No refinement was needed, and the author recorded no failures during generation. The player walks with a torch through a dark castle, sees a limited area around the character, fights monsters, and lights braziers. The attack is assigned to the J key.

The knight from the first test remained sufficiently detailed, but the sword-swing animation looked unnatural. The monsters moved slowly and were easily destroyed, and their visuals were noticeably simpler than the character's. After all the braziers were lit, the game did not explain the next objective, enemies continued appearing endlessly, and there was no way out of the location. The author assumed that the player's task was to survive, but the game itself did not explain this.

The Long Guard website

The fourth project was supposed to tell a story of 704 nights and use only images of the knight from the first test. The website cost 15 cents and took 37 minutes, making it the cheapest project in the experiment. No refinement was needed, although continuing work in the same session ended with error 413. The final part had to be assigned to a new session.

The author rated the first screen as the work of a mid-level designer from before the neural era: a large serif font, restrained colors, and the knight on the cover. The fortress section successfully used a light sheet with a plan on a dark page, while the chronicle of five entries created a coherent story. The gallery contained nine images that opened on click.

The section about the dead looked weaker. The scene seemed primitive and poorly matched the other images, the supporting text was too small and dim, the middle of the page was stretched out, and the final phrase was lost against the background. The knight on the cover had an empty shield and the pose from the previous refinement. The author considers these shortcomings errors in the model, not in the website itself.

Stability and error 413

Three of the four projects were interrupted by the same error, 413. In one episode, the system reported that the request exceeded the 16 MB limit. In no case was the author able to continue working in the previous session: another attempt ended in a new failure, after which the project had to be reopened from scratch.

The author did not confirm the exact cause of the error. The theory that the failure was related to screenshots remains an assumption, not an established fact. The test results cannot establish that Particle 1 itself always causes error 413 or that the problem occurs only because of images: OpenRouter, Open Code, the size of the transmitted data, and the specific session configuration may all have affected the result.

This is a significant limitation for an agentic workflow. Restarting removes the convenience of continuing a task, and a new session may take previous decisions into account less effectively. The user has to explain the context again, check the saved files, and make sure the model does not rebuild the project with different logic.

What the refinements showed

The main problem with the corrections was the conflict between local improvement and preserving elements that already worked. After being asked to improve the knight, the model made the metal and proportions better but lost the emblem and changed the readability of the pose. The author also noted that small details from the prompt often remained illegible in the frame, even when the corresponding object was present in the code.

This feature is important for 3D tasks, where the result must be evaluated on two levels. First, one checks whether the object exists in the scene and whether the code works; then one looks at whether it is distinguishable from the required distance, whether it blends into the shadow, and whether it matches the stated design. In this experiment, Particle 1 handled the first level more often than it achieved precise visual rendering of small elements.

Strengths and weaknesses of Particle 1

• Low test cost. Four related projects cost the author 1 dollars 65 cents, while the website required just 15 cents.
• Working with code and tools. The model was able to create a browser-based 3D scene, a game, and a website, as well as transfer the character between projects.
• Acceptable prototyping. The fortress, game, and website achieved a functional appearance without a long series of manual corrections.
• Session instability. Error 413 interrupted three of the four projects, and continuation in the previous session was unsuccessful.
• Loss of details during refinement. Correcting one shortcoming sometimes broke an element that was already working.
• Poor readability of small objects. Emblems, cracks, cloak folds, and places for bells were not always visible in the finished scene.
• Incomplete game logic. The game did not explain the objective after the braziers were lit, and monsters appeared endlessly.

Who Particle 1 may suit

Based on this test, Particle 1 may be useful for inexpensive browser prototypes, simple websites, demo scenes, and early game versions when the developer is prepared to check the result manually. It is particularly interesting where the cost of many attempts matters more than perfect detail and the project can be quickly restarted after a failure.

For a commercial 3D model, a complex game, or a scene with many mandatory visual details, this result calls for caution. The user must allow time to check geometry, lighting, animations, interface, and logic, and should save file versions before each refinement.

Is the model suitable for a complex agentic task? The answer depends on the requirements. If an inexpensive browser prototype is needed, Particle 1 appears suitable. If a stable long session, precise preservation of details, and predictable corrections are required, the test results do not provide grounds for a confident choice.

Experiment limitations

The author tested Particle 1 in a browser using 3.js. There were no tests in Blender or Godot, although the author considers them necessary for a more complete evaluation. The conclusion about working with 3D cannot be extended to all engines and working environments.

The experiment involved four projects, one shared story, and one workflow with a maximum of one refinement per task. The author did not have access to benchmarks, and the quality ratings were subjective. The comparison with other models was also not designed as a controlled test under identical conditions, so the final characterization of "middling quality" remains the author's personal opinion.

The practical conclusion is this: Particle 1 can inexpensively assemble a combination of an 3D scene, a game, and a website, but its strength here lies in rapid prototyping rather than precise 3D generation. The low price does not compensate for errors 413, the need to start new sessions, and the risk of losing details during corrections. In the author's subjective assessment, the model is probably unsuitable for 3D tasks, while the original PSK performed better.

Frequently asked questions

How much did the Particle 1 test cost?

The author spent 1 dollars and 65 cents on four projects. This amount included model calls as part of the described experiment, but not separate infrastructure or specialist labor costs.

Which model was used in the test?

The test used Particle 1 from Particle AI. The author describes it as a fine-tuned DeepSeek V4.1 Flash.

Why did the projects end with error 413?

The exact cause was not established. The author hypothesized a connection with screenshots, but this version was not confirmed. Three of the four projects had to be continued in new sessions.

Did Particle 1 create a complete game?

The model created a working browser prototype, Visual Hold the Torch, featuring a knight, a torch, monsters, and braziers. The author also noted unnatural animation, simple enemies, the endless appearance of monsters, and the lack of a clear objective after the main action was completed.

Can Particle 1 be considered the best model for 3D?

No, the experiment does not support that conclusion. The author assessed Particle 1 as rather unsuitable for 3D generation and noted that the original PSK performed better. This is a subjective conclusion based on four projects, not the result of an overall model ranking.