Today, a colleague asked me if there is a reason not to mostly use Kimi K3 and GLM 5.2 on a rate limited LLM provider plan (Cline-pass).

Knowing that I use Deepseek V4 Flash ('dsf4') for a lot of my work, he asked if there is a downside to just always using Kimi K3 and GLM 5.2.

My response, tempered by the direction this conversation took, was:

One major benefit of dsf4 is how fast it performs. You'll get tasks completed much more quickly with it, as long as the challenge is within its capability.

Also, there tends to be a sort of simplicity in dsf4's solutions, which can be beneficial. Imagine speaking with a genius compared to an average person. The genius may go down rabbit holes that don't necessarily need to be explored. Larger models can sometimes pollute a project with unnecessary feature creep, and drive you crazy with unnecessary attention to scope creep.

I've had dsf4 create much better solutions than GPT, for several small projects, because it's planning wasn't as lofty. Those simpler solutions were easier to iterate upon, and in the end, provided a better foundation to build upon, because the LLM didn't try to think so deeply about all the complicated possibilities related to where the project might need to go, and over-engineer in the beginning.

Also Kimi K3 will absolutely blow up your rate limit. Even GLM 5.2 will blow up your rate limit, and it's several times smaller than Kimi K3. I meant it when I said dsf4 will do 98% of your work and use 2% of your rate limit, while Kimi K3 will do 2% of your work, and use 98% of your rate limit.

Kimi K3 should be treated like the senior project developer, not the entire mid-level engineering staff that grinds away at every line of code or content. Use it to check everyone else's work, and to help with problems that the other LLMs can solve.

And don't forget, if you're working on a project that doesn't require constant access to a local environment, build as much as you can with GPT.

Use the zip file routine in GPT (https://aibynick.com/thread/3) for as much work as possible. There are still no realistic rate limits, and the current version of GPT is exceptionally smart.

Tell it to start with a simple solution - or better yet, define the exact requirements much more specifically. It's not unusual for me to spend a 1/2 hour writing prompts for complicated goals. I've spent more than an hour at times, crafting a single prompt - providing explanations, screen shots, and engineering guidelines to clarify the problem and the exact intended output.

Ask it to ask you questions about any decision it has to make about engineering choices. You can rely on frontier LLMs to think intelligently about the full scope of a problem, and a proposed solution, but they often have a different perspective about an imagined outcome, and all the potential pieces involved.

My most used words with smaller LLMs are 'work in baby steps'. I do most of the engineering thinking with small LLMs - they just provide working code. With bigger LLMs you can provide much deeper, more detailed requirement specifications, and they go to work on the long horizon goal.

With smaller LLMs, I do more of the planning, make more of the tool choices, rely more on my own engineering involvement, specifically instruct more tests to be performed, etc., and give the LLM smaller tasks to complete. Prompts, tasks, and goals are all simpler with smaller LLMs.

One point to clarify is that I tend to use either the Chat GPT zip file workflow or other LLMs in a local agent.

If I'm working on a project that doesn't require lots of interaction with a local environment, then I use GPT all the way. If basically endlessly free to use, and it's extremely capable

If I'm working on a project which requires lots of iteration with a local environment, then I get everything possible completed with dsf4, and use a big model to evaluate completed work at checkpoints, help with problems that dsf4 gets stuck on, work on larger scope planning, research about overarching approaches to achieving a solution, etc.

I may use a bigger model to complete a larger plan for a complicated project, before beginning - even use GPT to build an initial solution for a project that requires lots of local iteration - then unzip that project locally and have dsf4 perform all the local iterations within the environment.

For example, if the project involves compiling lots of tools from downloaded source code repositories, interacting with local auth systems, installing piles of prerequisites on the OS, and then building code which interacts with all those pieces, than that will be a Pi project. If I'm building a Flask app from the ground up, using only well known pip installed libraries, that will be a GPT project. I'll very rarely ever ask GPT for instructions about how to install something on a system, for example - dsf4 will just do that work.

Another common workflow lately, has been for clients to build their own small demo applications in Pi, running on a development server hosted at Contabo or some similar VPS provider. They do all their own vibe coding work in Pi, directly on the VPS development server, so that the demo app can be accessed by internal users. They use only fake data during development iterations, and have employees and other users interact with the vibe coded prototype, provide their feedback and suggest additional requirements to make the app functionally useful. When the prototype has been built to a point where most of the basic functionality is complete, then they pass the project over to me - I review code, logic, database schema, and functionality, add auth, logging, UI improvements, and other features, ensure compliance requirements are satisfied, build APIs to integrate with other existing apps and databases, populate dummy field data in the demo app with live data pulled from existing DBs, etc., and install final application releases on the production server.

In that workflow, I may at times perform work in a separate Pi session on the server, and/or download a zip file of the project and work with it in ChatGPT. Often, when dealing with PHI, I download the project zip file onto my locally hosted servers, so that I can work through development iterations using actual sensitive production data, without ever having to send any info out to data centers. In the case of HIPAA and other compliance laws, I'll often have my local GPUs generate fake data sets with the exact same shape as the production data, and pass that fictitious data set back to ChatGPT and the development Pi environments.

In the end, what ties together every piece of a multi-environment workflow like that, is the process of preparing zip files which contain all the code, database schema, installed libraries, .env variables, and all other prerequisite environment configuration information, documentation, etc. - everything required to set up the application on another server, entirely in a single zip file. Very often, zip files will contain multiple applications which are connected by REST APIs that enable them to interact (and/or perhaps they interact by working with the same database schema...).

If clients vibe code an app prototype on a development VPS, whether or not I add to that development effort on the server (it's common that I get involved with development cycles on the server, whenever clients get stuck vibe-coding a functionality) - the end goal is to export that prototype as a zip file. From there, I can work with the zip file in ChatGPT, or on my local servers. And whatever path those development cycles take through various dev environments, the project gets uploaded to the production server as a zip file.

The cheat sheets below cover the process of how servers are set up, and how Flask projects are transferred and installed from zip files:

So, no matter the development environment or workflow process, coordinating work in all those environments, in my way of working as a solo developer, all relies on using zip files which contain the full scope of a project at any snapshot point. When work needs to be merged from multiple branches, I typically have ChatGPT or another frontier model perform the work of integrating functionalities from separate development branches, into a master branch, and move on with that merged snapshot zip file as the source of truth, once that new master branch been fully tested.

My colleague asked about switching models in the middle of a Pi-session, particular because that may interfere with cache processing.

Sure, you lose some of the cache hit efficiency, which is one thing that dsf4 does cheaper than any other model, but it's still so inexpensive, it just hardly seems to matter.

I tend to think in terms of building artifacts. In my workflows, those artifacts tend to be built by a single model.

For example, yesterday, I was working on a scheduling system which involved a Google Calendar .ics file that was filled with PHI. The overall project was being built by GPT, but I needed to give GPT access to the .ics file structure and demo data. So I used a local Qwen 3.6 model to generate an .ics file copy with all the PHI replaced by fake patient data, then I had dsf4 ensure that no sensitive data was included in the generated fake data file (and had it generate a report to document that effort). Then I passed the fake data file to GPT.

I used Qwen during the process above because that model performs much faster on local hardware, and the job simply required getting a large volume of simple repetitive work completed (replacing thousands of names, birthdays, and other info in the .ics calendar export). I relied on dsf4 to perform the more thorough and intelligent job of evaluating whether any PHI was left in the fake data file. It would have taken many times longer for the locally hosted dsf4 model to do all the busy work that Qwen was able to perform quickly.

In the case above, the goal was to create an artifact that the models could pass around and use. An entire project created by GPT, in a zip file, could be another sort of artifact that other LLMs could work with.

I most often have GPT build an entire project, and then have a local LLM iterate with tests on sensitive data, for example. Then zip up that completed work as a project zip file, and have GPT perform a final code review, and/or continue building out more features...

For most steps in any development effort, I'll tend to use one single model to create whatever artifact is required for a given stage of development, and I'll divide up work between the LLMs, agents, and other tools that I know will get a particular job done best. For lots of typical Flask project development work, the entire project stays in GPT, and I just upload zip files to deploy in dev and production environments.

For projects that involve lots of IT configuration, at least those phases start in Pi.

Whatever the goal, if you're working with file artifacts - even full project zip files that contain all the code, database schema definitions, UI in code (or even in the form of screen shots, if needed), environment config info (required libraries, .env variables), documentation, etc., then those artifacts can be passed around to the LLM and agent system that is most effective for a given stage of a project (ChatGPT for high intelligence with virtually endless rate limits, Pi + dsf4 for lots of local iterations, Pi + some local model to deal with PHI, etc.).

That doesn't mean I never run into a situation where I don't switch models in a Pi session. When I created those long tech tutorials last week, I regularly typed in 'I just switched models from Deepseek v4 Flash to GLM 5.2 [or Kimi K3], please review all the work we've completed, check the current document for correctness, and fill in any gaps in the content which require expanded coverage.". Then I went back to dsf4 to deeply expand upon the content proposed by Kimi, at a cheap rate, and continued that loop...

I could also choose to have GPT work on improving any of those tutorials which dsf4, GLM 5.2, and Kimi K3 created last week. GPT wouldn't need any access to the history of thinking, research, interactions with me, etc., that those LLMs took part in, in Pi. It just needs the artifact - the existing tutorial.

Most of the time with software development projects, the situation is the same - any LLM I want to involve, just needs the current project zip file artifact. It doesn't need any more information about the history of how it was created. It just starts working on the current project, as it exists in that snapshot, and it builds another snapshot.

If I have a feature from another branch of development, which I want integrated, I provide both project zip files, and explain very carefully the details of the alternative branch, which need to be merged into the master branch. Whenever I perform that sort of merge, I make it extremely clear in the prompt, that no other functionalities in the master branch should be changed, and no other features from the alternative branch should be incorporated into the master branch. I've developed a lot of language which I've discovered works well with LLMs to ensure unintended regressions don't show up as a result of merge efforts.

In many cases, the situation is reversed. Often a project zip file, even with all the code, database, UI, and environment files, doesn't provide enough context. Often, I want the LLM to understand all the discussion, exploration, and failed branching effort which has occurred during the creation of a project zip file snapshot.

In those cases I provide full conversation histories, again as file artifacts - saved .mhtml files (or text files containing copied portions of ChatGPT conversations), .html exports of Pi sessions, and any relevant supporting file uploads that were attached to those conversations, etc. That can save me an extraordinary amount of time re-explaining requirements which haven't yet been satisfied, and avoid re-exploring rabbit holes which proved fruitless.

But again, those histories are file artifacts which the LLM can open, review, understand, and summarize. If that summarization process can be carried out by a sub-agent, then virtually none of the main conversation context is wasted. This is the way conversation compression should be handled - it's far far better than having your agent automatically compress your main conversation. ChatGPT and agents such as Hermes, Codex, Claude Code, etc., can automatically delegate tasks to sub-agents (on local machines this can also help maximize GPU use and speed up overall token generation performance). I tend to prefer managing all that manually in Pi.

One of the primary concepts is always reducing the size of the current working context in the current LLM conversation. You don't ever want to reach a state where the LLM has reached its context limit and needs to compact the conversation, because then you lose control of the details that are contained in the context. An auto-compaction of the conversation means that the LLM gets to choose which details are discarded during the session compression, and that can mean that important details get removed. Avoid auto-compaction for that reason.

Always keep in mind that LLMs work more effectively, the shorter you keep a conversation context. They'll get confused and perform worse, the longer the conversation context gets, especially if you've gone in several failed or unused directions while exploring potential solutions to your task.

Keep these guidelines in mind:

  • Start with a fresh context (start new conversation sessions) as often as possible.
  • Try to get a particular set of tasks completed in a conversation context, and end that conversation when that set of tasks is completed.
  • Save the completed work as file artifacts (a project zip file and exported conversation history).
  • Every time you begin a new phase of work, start a fresh conversation context, and provide only the artifacts that are required for your LLM to understand everything needed to move forward. In most cases, this should just be the project zip file.