The Cost of Getting AI Work Done: Trioma’s Case for Orchestration

1. Guest Background

Iskander Malikov appears in this roughly 55-minute Eye on AI interview as a representative of Trioma, speaking with host Craig S. Smith. The supplied guest information does not establish his precise job title. His comments are best read as an account from someone involved in the product and its commercial direction, rather than as an independent assessment of the platform’s performance.

Malikov supplies some relevant professional context himself. He says he previously built and scaled consumer applications involving trading and charting. He draws on that experience when discussing consumer churn, distribution and the convenience of moving software into a browser. The interview does not identify those earlier products or provide their scale or results, so the background supports an understanding of his perspective without establishing a broader record of commercial success.

His present subject is Trioma’s proposed connection between user requests, model capabilities and computing resources. He describes an interface layer with web and desktop applications, a middle layer containing 65 models and orchestration, and a GPU foundation. Mobile applications are described as forthcoming. He also positions the service across consumer and business uses: individuals create content, code and ask questions, while businesses seek complete workflows such as website building, customer support and compliance automation. That breadth explains why Smith’s questions extend beyond model access to software delivery and infrastructure economics.

2. What the Episode Covers

The opening product question is whether Trioma simply routes a request to an appropriate model. Malikov describes a more involved process: analyze the prompt, divide the work into subtasks, then choose one model or a combination. He acknowledges a cost in responsiveness. Understanding a complicated request and deciding how to execute it can take longer than asking a frontier model a direct question. The episode therefore treats orchestration as an execution layer whose contribution must be judged against its overhead.

One claimed feature is switching models when a content restriction prevents a subtask from being completed, then returning to the more efficient original model. The interview provides no task trace or explanation of the controls surrounding that behavior. Another feature, which Malikov calls an internal translator, is intended to turn ordinary language into executable requests. Asked about implementation, he mentions changing weights and parameters and says the CTO would be better placed to explain the engineering. The intended user experience is clearer than the disclosed architecture.

The commercial explanation begins with purchasing power. Malikov says enterprise relationships and bulk API consumption secure discounts from model providers. He cites millions and billions of tokens without specifying a period or discount rate. Trioma also acts, in his account, as a distribution layer that develops a user base and community for those providers. This explains a possible source of purchasing advantage, but the interview does not quantify what reaches the customer.

The infrastructure discussion introduces a separate vocabulary. TGN denotes the GPU network; TES is described as its energy stream; TY represents AI credits. Buying a seat or software license is said to generate an entitlement that can be exchanged for credits. Malikov also mentions stablecoin withdrawal and retaining the generated energy. However, he is unsure whether the minimum purchase is about $30 or $50, and does not establish generation rates, exchange ratios, fees or exit conditions. His suggestion that a purchase can support continued usage is conditional on generation meeting the user’s token needs.

Current infrastructure and the intended ownership model also need separating. Malikov explicitly says Trioma rents GPUs from cloud companies and is moving toward ownership. He then describes buying equipment, renting capacity to other companies and running open-weight models internally as ways to improve economics and support AI sovereignty. No equipment inventory or operating figures are supplied. Similarly, his global ambition has contractual boundaries: he identifies the company as UAE-based, confirms access to Chinese models including GLM, and says partner restrictions prevent service in markets including North Korea and Iran.

Finally, the product chronology remains relative. Malikov says development began in January of that year, users gained access in August and the formal launch happened the day before the interview. The upload date does not establish when the conversation was recorded. His emphasis is on gathering feedback to choose among content creation, coding and business API demand, which frames these statements as an evolving product proposition.

3. Core Views: Reasoning, Examples, and Limits

The strongest analytical idea in the conversation is a change in the unit of comparison. Malikov asks users to consider the cost of obtaining an acceptable result. His illustration contrasts spending $20 or $30 and roughly 15 iterations on a document or image edit with reaching satisfaction through one prompt and a small adjustment elsewhere, potentially at one-tenth the cost. The reasoning is useful: repeated attempts and an unsuitable model can overwhelm an apparent advantage in token pricing. But the numbers describe a hypothetical comparison. The episode supplies no matched inputs, acceptance criteria or bills that would establish that saving for Trioma.

Model selection is a second part of that argument. Malikov suggests an ordinary model may be sufficient for some tasks and could cost ten times less. The operative condition is sufficiency: a cheaper model only improves the result economics if its output meets the requirement. He says users can inspect spending by model in a dashboard, which could make consumption easier to investigate. That visibility would still need to be paired with quality assessment. When Smith asks whether Trioma covers all of Perplexity’s capabilities for less money, Malikov returns to total cost without demonstrating feature equivalence. The title’s question about the cheapest way to use AI, and its reference to more than 65 models tested, are therefore episode framing rather than a substantiated market ranking.

The interview is more persuasive about the work orchestration requires than about its universal superiority. Malikov says adding a newly available API can take days or sometimes hours, while making the model useful inside the engine requires more engineering. Connecting a model and assigning it an appropriate role are distinct achievements. Audio, images and copy may call for different capabilities, but decomposition also introduces processing time. His acknowledgment of slower responses makes the tradeoff explicit. His stronger assertion that three, four or five models always produce a better result than a single supplier is not accompanied by benchmarks. Complementary strengths offer a reason to test combinations, not evidence that every combination improves every task.

Smith’s experience with the same named model through different services raises a related attribution problem. He reports differences that seem larger than ordinary answer variation. Malikov attributes them to internal orchestration and explains that Trioma’s automatic mode can select separate models for audio, video, images and copy. Yet the conversation does not establish what other providers actually invoked. His speculation about their internal behavior should not become a factual allegation that a selected model was substituted. A shared model label does not control every condition of a comparison; different outputs alone also cannot identify which platform variable caused the difference.

Malikov’s subscription argument applies the same cost concern to suppliers. He reasons that each generation consumes computing resources, so users who fully exploit an allowance can change the profitability of a subscription. From that he predicts more restrictions and an eventual move toward usage-based payment. This is a commercial forecast, not a demonstrated destination for every provider. His own description of Trioma subscriptions as incentives delivering extra credits also leaves room for subscriptions and metered consumption to coexist. The episode identifies pressures worth examining without establishing a complete industry cost model.

The discussion of SaaS shifts from purchasing intelligence to delegating work. Smith asks about building a missing HeyGen integration or a version of Photoshop tailored to personal needs. Malikov contrasts the convenience of browser software—installation-free access, sharing and cross-platform use—with an interface in which users ask AI to perform the task. His cofounder’s reported ten-minute messenger application supplies the memorable example: audio, video, webcam support, chats and groups appeared quickly enough to surprise him. He then argues that product purpose, intended users and community become more important as development becomes less scarce. The example can motivate a discussion of prototyping, but no code, test results or production evidence establishes that a full engineering lifecycle was replaced in ten minutes.

Two later claims sharpen the distinction between an impressive outcome and a verified workflow. Malikov reports that coding users favor desktop access to terminals, local files and applications, and that demand is moving from questions toward creation and automation. These are observations about his users without proportions or trend data. Separately, he says Studio can meet Smith’s four-video-stream and one-audio-stream editing requirement, and can produce videos up to 60 minutes despite a model’s 30-second limit. Neither capability is demonstrated. Output duration does not establish continuous generation, synchronization or editing quality. A result-based approach only becomes meaningful when those dimensions are included in the definition of success.

4. Learning and Application

An individual buyer can turn the episode’s central argument into a small task ledger. Choose recurring work—a document, an image revision or a coding change—and define an acceptable output before trying competing services. Record total charges, revision count, elapsed time and whether the output passes that standard. Include failed attempts. This tests the proposed advantage at the point where it matters to the user. If a cheaper service requires substantial correction, or a higher-quality service exceeds the available time, the tradeoff should remain visible in the decision.

For a comparison involving the same named model, first decide whether the object of evaluation is the model or the complete platform. Keep source material and acceptance criteria consistent, and record automatic mode, available tools and any disclosed invocation information. If the service does not expose its execution path, leave causal attribution unresolved. For orchestration specifically, request an example showing task decomposition and handling of an unsuccessful step. Model selection, coordination and interpretation of everyday language deserve separate examination. The acceptable delay depends on the task: a complex deliverable and an immediate answer need not share a latency budget.

Payment choices should follow observed consumption rather than the interview’s illustrative spending bands. Malikov mentions $20 and $100 monthly spending when explaining subscription incentives, but the heavier-use passage contains a transcription error around the figures 500 and 5,000. It should not be treated as a precise plan description. Compare the credits actually available, overage charges and applicable limits against a record of your own tasks. If demand varies, examine both light and heavy months. The argument for metering does not establish that every user should abandon subscriptions.

For a development team, the messenger anecdote is a useful prompt for a bounded prototype exercise. Ask an agent to implement one observable workflow, then assess functionality, tests, permissions, deployment and maintenance responsibility separately. Measure prototype time without presenting it as the total delivery schedule. Desktop execution may help where terminals and local files are necessary, but those permissions should be specified in the trial. A video team can use Smith’s request as an acceptance case: test synchronization, camera switching, consistency across segments, manual corrections and total cost. Exported running time alone would leave the central workflow unexamined.

TGN calls for a separate information request. Establish the license entitlement, TES generation rules, TY conversion, fees and stablecoin exit process in explicit terms, and distinguish rented infrastructure from planned ownership. Without those conditions, the conversation cannot support a payback calculation or a promise that one purchase covers continuing AI use. Describing the components as a loop does not resolve their economics.

Finally, Malikov’s community proposal can become a practical learning format: share real task specifications, failed attempts and acceptance methods so that user discussions produce reusable knowledge. His simultaneous concern about entry-level support, compliance and legal work should shape how teams evaluate that learning. Observe which tasks change before making staffing assumptions, and consider how newcomers will acquire judgment as responsibilities shift. His optimism about knowledge access and creativity is a perspective to investigate, not a measured employment forecast or a substitute for preserving opportunities to learn.

Source

• Original episode: Is This the Cheapest Way to Use AI in 2026? (65+ Models Tested) | Iskander Malikov,Trioma