Astra + Jev + DS V4.1 Flash: SUPER FAST, SUPER CHEAP & SOTA WORKER Setup!

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Astra + Jev + DS V4.1 Flash: SUPER FAST, SUPER CHEAP & SOTA WORKER Setup! · Channel: AICodeKing · 13:56 · Watch on YouTube

Topics: AI agents, Software engineering with AI, AI developer tools, Model inference and optimization, AI models

Summary

The video demonstrates an architect-and-worker coding workflow in Bamboo, using a stronger model for planning and review and more affordable models for implementation. The creator configures Open Code workers and optional Jev decision and browser-testing features, then uses them to build and test a Minesweeper-style game. The workflow emphasizes clear file ownership, checkpoints, reviewing diffs and evidence, and focused follow-up fixes. The video also cautions that extra tools and subscriptions do not automatically reduce total cost, so users should measure their complete run.

Key points

Bamboo lets an architect model divide a project into assignments for workers and review their results.
The creator uses Codeex for the architect and Open Code with a DeepSeek model for workers; supported models depend on the connected harness and account.
Workers need clear assignments and file ownership so independently written components fit together.
Bamboo supports up to three simultaneous worker assignments in the demonstrated setup, and profiles can save reusable team configurations.
Jev is optional: decision assistance can help with worker suggestions, context lookup, and checks of saved changes against evidence or project rules.
Jev browser testing requires enabling its separate option and configuring the runtime; users can instead test the app themselves.
Review saved diffs, test output, and browser evidence rather than relying only on an agent’s completion claim.
Browser checks cover specific assertions and interactions, but do not prove all game logic is correct; the creator recommends additional tests and manual checks.
To assess economy, include retries, subscriptions, and Jev or browser-helper usage; the cheapest token price does not necessarily mean the cheapest completed task.

Chapters

Start	Chapter	Summary
00:02	The architect-and-worker approach	The creator introduces Bamboo’s team workflow, the Reddit inspiration, and the distinction between the architect and lower-cost workers.
02:05	Models, Bamboo, and optional Jev setup	The video explains the roles of the architect, workers, and Jev, then walks through connecting models and configuring optional decision and browser assistance.
04:39	Configure a team and assign the game	The creator sets up architect and worker profiles, adds project rules, and gives the team a Minesweeper-style game task with defined responsibilities.
07:13	Coordinate work and review evidence	The video shows how to monitor assignments and checkpoints, retrieve a prior decision with Jev, and review saved changes against evidence and project rules.
10:20	Test the app and evaluate the workflow	The creator demonstrates browser testing and follow-up checks, then discusses when team workflows are worthwhile and how to compare their full costs.
13:25	Wrap-up	The creator summarizes Bamboo’s built-in team workflow and optional Jev checks before ending the video.

Quotes

I don’t think every part of a project needs your most expensive model. — 00:02

The workers implement those assignments with clear file ownership and a clear description of the expected result. — 02:05

This is where I want to see the diff and the actual test output, not just a confident paragraph saying everything is done. — 09:17

Agent finished means the browser agent reported that it finished. Checks passed means those specific assertions passed. — 10:50

The cheapest token price doesn’t necessarily give you the cheapest completed task. — 12:55

Concepts and entities

Bamboo, Jev, Astra, DeepSeek V4.1 Flash, Codex, OpenCode, TypeSafe

Full transcript (original language)

00:02 [music] Hi, welcome to another video. So, if you’re using an expensive coding model, a lot of your usage can go into pretty ordinary work. Reading files, writing repetitive code, fixing imports, and making small changes. I don’t think every part of a project needs your most expensive model. Today, I want to show you an architect and worker setup in a tool called Bamboo. A stronger model plans the project and reviews the result while more affordable models handle the individual assignments. And we’re going

00:33 to add Jev to help with a few decisions along the way, including choosing workers, checking changes, and testing the app in a browser. The idea comes from a Reddit post where someone paired Astra with 8 DeepSeek 4.1 sub agents. They reported spending 94 cents on the workers while Astra used about 10% of their weekly subscription allowance. Those are their figures. The entire setup didn’t cost 94 cents and we need to measure our own run. Their expanded explanation uses MCP to connect DeepSseek to Codeex with Codeex leading development and reviewing the workers. I’ll link that below. I’m using Bamboo

01:04 because the team setup is builtin and I want to choose the models and follow their work through an interface. Jev is an optional addition to that workflow. You can use Bambood run teams and review your changes without a Jev API key. I’ll show where the extra assistance fits so you can decide which parts are useful to you. So, let’s get right into it. First, just look at the workspace. A lot of coding tools give you this dark, plain window, and that’s fine, but I like the nature backgrounds and translucent panels here. It feels a lot less dull when you’re spending hours looking at agent responses. You can change the wallpaper, adjust its visibility, and

01:35 add blur. I like having the scenery there, but I still want the text to be readable. You can tone it down as much as you want. Bamboo is $20 a month with model subscriptions and API usage build separately. It’s also still in alpha. So yes, it’s another subscription and there will be rough edges. What interests me is having the team controls, conversations, browser, and changes together in a workspace that feels good to use. Now the architect keeps track of the overall objective. It decides what

02:05 needs to be built, breaks that into assignments, and checks whether the pieces fit together. The workers implement those assignments with clear file ownership and a clear description of the expected result. Jev has a smaller role. It’s type- safe’s decision model. It can look at supplied information and make a focused judgment such as which configured worker fits an assignment or whether the evidence supports a completion claim. The coding models still plan, write code, and fix problems. The potential saving comes from dividing the work sensibly. A

02:37 cheaper worker can handle implementation while the architect concentrates on coordination and review. Jev gives us another way to handle focus checks, but every extra call has a cost, so we’ll use it selectively. First, install and activate Bamboo using the download and license from your website account. I’m showing the Mac OS version here. You’ll also need your chosen coding tools installed and signed in. The Bamboo subscription doesn’t include access to their paid models. For this example, I’m using Codeex for the architect and Open Code for the workers. You can also choose from other supported connections

03:08 including claude code, Kimmy code, and GLM through claude code. The models available depend on the harness and account you’ve connected. For DeepS through open code, open open code first. Use /connect. Choose DeepSeek and enter your provider key in the connection prompt. Then use /models to see what’s available. Use the actual model listed in your account. This workflow doesn’t depend on the exact version in the Reddit post. Back in Bambood, open settings, then agents. Find open code models. Click choose models. Select the

03:38 entries you want and save them. These become available in the main model dropdown and the team selectors. If you only see default, refresh the catalog after connecting your provider and choose an explicit model. Now, while we’re in settings, let’s set up the optional Jev part. Under agents, open setup Jev and enable decision assistance. Add your Typesafe API key and save. That’s enough for the worker suggestions, context lookup, and review checks. They don’t need a browser runtime or another text model. Browser testing has its own switch labeled let

04:09 your agents test their apps. For that part, enable the switch. Add the text model API key as well and click save settings again. Then install the Jev runtime using the button and check the setup. You’ll need Chrome and either the UV package manager or Python version 3.12 or newer available for the installation. The browser helper model can be configured separately. If you only want the decision features, leave browser testing off and skip that extra setup. Both parts start disabled and your normal coding workflow continues without them. The information used for a requested Jev check goes to type safe

04:39 and browser text entry can use the configured helper provider. Reports stay on your device. So this is an additional provider connection with separate usage and you control whether to enable it. Now open a project and create a new task. Bamboo uses your last active project, but check the name and change it if needed. In the message box, click team to open the compact architect and workers panel. Choose codeex and your planning model for the architect. If Astra is available, you can use it to follow the Reddit idea or choose another model you trust for this project. Set

05:10 the reasoning effort where supported. I wouldn’t automatically put every agent on its highest setting. For the workers, select open code and the deepseek model you added. Let’s create two profiles called logic and interface. They can use the same model or different ones. The names describe the roles we intend to give them. We’ll still need to provide the actual assignments set at once to two. Bambood currently supports up to three simultaneous worker assignments. So this is a smaller team than the eight agents in the post. Under run limits and

05:40 context, you can also limit assignments and architect rounds and control how much worker output is summarized. Those are workflow limits, not a hard dollar budget. Save this combination as a profile called budget coding. Then apply it with save setup. The setup is remembered and profiles let you switch teams without selecting all the models again. This is our first place to try Jev. Let’s also give the review a couple of concrete rules from task actions. Open Jev assistance then project rules. I’ll save two. The game engine must not

06:11 read or modify the browser interface and changes to game rules must include meaningful tests for the affected behavior. Saving those rules doesn’t call a model. We’ll check them against saved changes later. I’ll include them in the task request as well, so the workers know the expectations before they start coding. Now, let’s build the mind sweeper game. It has a useful split between game rules and interface work, and we can test the behavior instead of judging only a screenshot. I’ll give the architect this request. Build a browserbased minder game with difficulty

06:42 levels, a timer, flags, a safe first click, keyboard controls, and saved best times. Define the engine interface and file ownership first. Assign the engine and its tests to logic and the layout and controls to interface. Run independent work in parallel. Ask for checkpoints and blockers. Then review and integrate the results. I’m also adding the project rules and a short instruction. If the tools are available, use them selectively for worker suggestions and checking saved changes. Use relevant context excerpts when needed. Treat the results as advice.

07:13 Continue normally if Jev is unavailable and verify the game with actual tests. The complete prompt will be linked below including the browser checks. So let’s send it and see how the work gets divided. First watch whether the architect actually delegates. We want separate assignments with an agreed interface. The game engine needs to expose the board state and game actions and the interface worker needs to know how to use them. Otherwise, both workers can produce reasonable code that doesn’t fit together. The team uses a shared checkout overlapping declared file scopes weight which helps coordinate edits, but sensible boundaries still matter. Two agents shouldn’t both be

07:44 rewriting the same page because they were each told to build the entire game. Open architect and workers on the right of the conversation. You can see the assignments and status. Then click a worker to read its response tool activity and latest checkpoint. The main conversation stays manageable while the detailed work remains available. Workers can also communicate with the architect and teammates. If the interface needs a different engine response, it can raise that issue and the architect can coordinate the change. A checkpoint records progress, next steps, and

08:15 blockers, which is useful when a task takes several rounds. Here’s another place Jev fits. Suppose we’ve discussed the engine contract and now need to find that agreement. In Jev assistance, open find context and ask what contract we agreed on between the engine and interface. Preview the excerpts, then run the lookup. It returns relevant original text from the recent task conversation. This doesn’t rewrite the history and it isn’t a search across every file or every worker transcript. If the agreement is outside that recent window, open the original worker conversation. I like this as a focused

08:46 way to retrieve an earlier decision. The normal checkpoints and conversation history still do the main job of keeping a longer task coherent. We aren’t making the agent depend on Jev remembering everything. Bamboo can bring the architect back when teammates send messages or when worker results are ready for review. You also have pause, resume, and stop controls. If the same blocker keeps returning, check what’s happening before spending more on another round. Once a worker settles, open its saved changes. This is where I want to see the diff and the actual test

09:17 output, not just a confident paragraph saying everything is done. From that worker or from its saved diff, click review with Jev. Ask it to assess whether the available evidence covers the requested behavior and point out missing verification. Preview evidence shows what will be assessed before you run it. The report can flag unsupported claims or uncertainty. For example, if a worker says best times persist, but there’s no relevant test or browser evidence, that’s something to investigate. The check doesn’t run the test itself, and I would keep the

09:48 architect responsible for deciding what to do next. Review a settled worker here. If you review a task while agents are still running, active work will be called out as unresolved. That makes sense and there’s no reason to keep calling the checker until it agrees to finish. Then check the saved changes against our project rules. We want to know whether the engine stayed separate from browser code and whether the changed rules have meaningful tests. These are file level judgments about the saved patch. So open the source diff when something gets flagged. Use report in prompt adds the result to your draft.

10:20 You can ask the architect to investigate a finding and give the relevant worker a focused follow-up. Nothing gets sent just because you open the report. Now, let’s test the actual app. Ask the architect to start the local preview. Then, open it from Bambood’s browser panel and its list of local servers with the optional browser integration enabled. Click test with Jev. Give it a specific journey. Start a game. Reveal a cell. Place and remove a flag. Restart and change the difficulty. Finish on the game screen and report any interaction that fails. Jev drives a separate Chrome session, so it isn’t using your personal

10:50 browser tabs or signed in cookies. For this demo, the build prompt asks for the title, mind sweeper, and visible labels for difficulty and new game. We can use the title and visible text as independent final checks. Then watch the actions stream into the report and inspect the screenshot. There’s an important distinction in the result. Agent finished means the browser agent reported that it finished. Checks passed means those specific assertions passed. A correct page title doesn’t prove that the mind placement or timer logic is correct. So keep the engine tests and inspect the gameplay, too. You can also

11:21 ask the architect to run these browser tests through its tools. Tell it to wait for the reports, read any failed checks, and inspect the screenshots before ending the turn. That lets it use the findings in the review without you copying every browser action into the conversation. Run a second check with the mobile preset to look at the narrower layout. I would still test the keyboard controls manually and verify saved best times across a reload. Browser automation can get stuck on unsupported interactions and I want those limitations reported rather than counted as success. If the timer keeps

11:51 running after changing difficulty, for example, give that exact behavior back to the architect. It can assign a focused fix, rerun the affected tests, and repeat that browser journey. You can check the revised saved diff with Jev again when there’s new evidence to assess. That’s the loop we’re aiming for. Clear assignments, implementation, useful evidence, and a focused fix when something is wrong. Jev helps at selected points while the architect and workers continue doing the development. Without a Jeff key, you can follow the same process using the normal worker conversations, diffs, tests, and browser

12:24 panel. You can also enable only decision assistance and keep testing the interface yourself. There’s no requirement to add another model service just to use the team feature. Now about keeping this economical. Start with work that can actually be separated. Two independent components can justify a team. A oneline change probably doesn’t need two workers and several review rounds. Keep the assignment specific and the checkpoints concise. If a cheaper model repeatedly gets stuck, a stronger worker might finish the job for less overall. The cheapest token price doesn’t necessarily give you the

12:55 cheapest completed task. include the architect workers retries, bambooed subscription, and any jev or browser helper usage when comparing costs. I would use the extra checks where they save repetitive investigation. Then measure the complete run. Adding another model doesn’t automatically save tokens or time. You can still use the MCP approach from the post if you prefer putting together your own setup. What appeals to me here is selecting the team in one place, following its progress, and reviewing the work in an interface that looks and feels much better than

13:25 another plain coding window. It is still $20 a month, and it’s still alpha, but the architect and worker workflow is builtin. The profiles are easy to reuse, and Jev adds some interesting optional checks around it. You can start with your existing models and add the extra pieces only when they help. Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments. If [music] you like this video, consider donating through the super thanks option or becoming a member by clicking the join button. [music] Also, give this video a thumbs up and subscribe to my channel. I’ll see you in the next one.

13:56 Until then, bye.