跪拜 Guibai
← Back to the summary

One Model Isn’t Enough: Multi-Model API Routing Powers a Job-Search Agent

After Two-Plus Years of GPT, I Recently Switched Models and Also Built a Job-Search Pitfall-Avoidance Agent


theme: condensed-night-purple

image

Hello everyone, I’m Programmer Navy (程序员海军), OPC | AI enthusiast | independent developer.

GPT has been the AI tool I used the most over the past two-plus years.

From the very beginning, I used it to look up information and write code; later I used it for requirements analysis, developing AI applications, and even trivial everyday things. I basically opened GPT first for everything. Calling it my main battlefield is no exaggeration.

But over the last few months, using it has genuinely become annoying.

Sometimes the requirements are already explained very clearly, and it still misunderstands; for slightly complex tasks, several rounds of back-and-forth still can’t wrap things up. In the past I felt it saved me trouble; now I constantly have to watch it and correct it. Occasionally switching to a high-intensity mode like Astra Pro makes the experience a bit better.

Of course, this is my own experience. I wouldn’t dare say the model has definitely gotten worse; it may be related to task complexity, usage patterns, changing expectations, and other factors. But one thing I am increasingly certain of: you can’t bet all your work on a single model.

So recently I researched model API platforms once more, and looked at quite a few relay stations along the way. After all that work, I finally chose Aiionly. I happened to have a small job-search project I had wanted to build for a while, so I used it as the application scenario for this choice.

image

To Switch Models, I Researched API Platforms All Over Again

Previously I was just chatting, and whichever tool was convenient, I used it; I didn’t feel there was a problem. But once I started building AI applications myself, things changed.

An application may need to handle long text, recognize screenshots, analyze user input, and hold continuous conversations. Different tasks have different requirements for models, and price, response speed, and call cost all need to be considered. It’s not reasonable to register a new account, recharge, and rewrite a set of integration logic every time I want to switch models.

When selecting a platform this time, I mainly looked at three things: whether model selection is flexible enough, whether API integration is troublesome, and whether the cost structure is clear.

The one I finally chose, Aiionly, positions itself as a multi-model API aggregation platform. Put simply, you don’t need to deal with different model vendors separately; through one platform you can select and call multiple models. For someone like me who writes code, tinkers with Agents, and builds various small products, this approach is considerably more convenient.

image

What I care about most is its unified API interface. For developers, having a relatively unified interface means that when you need to switch models later, adjusting the model configuration is much simpler than integrating a whole new service. Of course, parameters, capabilities, and response formats can still differ between models, and the places that need adaptation still have to be adapted.

image

Then there is cost. Aiionly offers pay-per-use calls and also Token Plan packages, so you can choose based on whether you are testing occasionally or frequently running Coding and Agent tasks. The console shows usage and bills, which matters to me. While building a demo, a few tokens might have seemed insignificant, but for long-term operation, costs can’t be left vague.

image

Let me make this clear: an API platform does not add intelligence to models. The same underlying model will not suddenly become much smarter just because you changed platforms.

image

What I value is model choice and convenience of integration, not some so-called “magic boost.” As for long-term stability and actual speed, those still need to be verified continuously in my own projects; you can’t just look at the marketing page.

AiiOnly and WorkBuddy have completed model routing integration. You can also go to “Agent Routing → WorkBuddy” in the AiiOnly client to select the model you need and complete the configuration with one click.

image

Using it is also simple. It provides an OpenAI-compatible interface; you can configure and use it in Workbuddy or other AI tools (Trae, Codex). Here we’ll use Workbuddy to demonstrate:

image

image

image

I Interviewed 50+ People This Year and Wanted to Build a Job-Search Pitfall-Avoidance Agent

Speaking of this small project, the origin is simple.

This year I interviewed more than 50 candidates one after another, and friends and netizens often come to me to talk about resumes, interviews, and job hunting. Having seen a lot of this, I found that many people focus on “can I pass the interview,” but one question is easily overlooked: is this company and this position actually worth my time?

Last year I also encountered a job opportunity that differed greatly from the actual situation. Although I cut my losses in time, the time and energy spent in the middle could not be recovered. That experience also made me feel strongly about “understand things clearly first, then make a choice.”

Especially since finding a job is not easy these days. Sending resumes, scheduling interviews, preparing for written tests, and sometimes taking special leave just to make a trip. Only after all the conversation do you find inconsistent salary terms, unacceptable working hours, or a job description that is nothing like what you first saw, and the time has been spent.

image

So I started thinking about whether I could build an Agent that first screens job postings for job seekers.

The earliest idea was straightforward: identify junk positions, zombie positions, and pitfall positions. But when I really sorted through the requirements, I found that phrasing too crude. Relying only on a screenshot of a job posting, AI can hardly judge whether a company is reliable; a vaguely written position does not mean the people behind it are scammers.

Later I changed the direction to something more practical, temporarily calling it “Workplace Evaluation.” It does not judge whether a company is good or bad; instead, combined with the job seeker’s own situation, it decides whether this opportunity is worth continuing to invest time in.

image

My approach is that the user first uploads a resume and sets their job preferences, such as desired city, salary, double weekends, and remote work. Then they feed in the job JD, company introduction, and screenshots of chats with HR, and let AI assist with the analysis.

image

There are three questions to examine separately: first, whether you have the ability to do the job; second, whether this position meets your personal requirements; third, whether there is anything in the recruitment information that needs to be treated with caution or verified further.

For example, a position says “20~30K, including performance bonus,” and your requirement is a fixed monthly salary of at least 20K. No matter how well the skills match, it cannot simply tell you “meets the requirement.” What should actually be done is to mark the salary structure as pending verification, then tell you how to clarify it with HR in the next step.

As another example, a job posting that does not mention overtime does not mean the company definitely has double weekends; nor can you conclude it follows 大小周 just because it is not written. Not knowing is not knowing; AI should not be forced to guess.

Final Thoughts

This project also made me rethink what kind of AI tools I actually need.

Models update too quickly now. Today this one is strong; after a while, it may be replaced by another. Every time a new model is released, everyone rushes to test leaderboards and compare who is smarter. I follow that too, but when it actually comes to building projects, the most important thing is whether it can get the task at hand done.

For example, this job-search Agent may use different capabilities for screenshot understanding, resume extraction, and position analysis. Whichever model handles a task more steadily and at a more suitable cost should be responsible for that task, instead of being limited to one model from start to finish. This is also why I chose a multi-model entry point like Aiionly.

Of course, the platform is only one part. Whether AI analysis is reliable still depends on whether the requirements are clearly defined, whether the input materials are sufficient, and whether the results are supported by evidence. Especially for job-search decisions, AI’s speculation must not be packaged as fact. Resumes and HR chat records contain personal information, so masking and privacy protection need attention when using them.

I still use GPT now; after all, it has done a lot of work with me. It’s just that compared with before, I no longer want to bind myself to one tool or model. Tools can be changed; projects and the ability to solve problems are what truly stay with you.

Finally, here is the platform used this time. If you are interested, you can take a look:

Aiionly official site: https://www.aiionly.com/

My referral registration link: https://maas.aiionly.com/login?inviteCode=0088482

Under the current new-user promotion, registering through this link lets you claim a 16-15 platform coin recharge coupon, plus a 5-yuan no-threshold Token Plan coupon. The specific claim conditions, validity period, and scope of use are subject to the activity page after registration.

If you only occasionally ask a few questions, there is no need to bother with APIs. But if, like me, you often use AI for programming, build Agents, or want to turn one of your ideas into a product, the multi-model access approach is worth understanding.