I Built My Own AI Studio. Here’s What It Cost.

0:00 I was scrolling recently and ended up on Higsfield's GitHub. They have open source developer tools there, including their SDKs. So, naturally, I started looking through what we could actually

0:09 use. There's even a framework for training models across GPUs. But then I noticed something much closer to the kind of projects we build here, API access with its own console. And I

0:20 thought, okay, could I connect a small app of my own to these image and video models? Let's give it a try. Higsfield is sponsoring this video. I'm going to walk you through my actual attempt,

0:30 including the setup problems and how I fix them, so you can use this in your own project. I kept the first test simple. Connect the app, generate an image, animate it, and check the actual

0:40 bill. That gives us one complete loop to understand. I started with the interface first, a model library on the left, a prompt in the middle, and a big preview on the right. But when I check the

0:50 connection, it says the API is not connected. So now I need to connect this interface to a real backend. Here is the part I wanted to understand properly. The browser sends my prompt to my own

1:01 server. That server adds the Higsfield credentials and makes the request. The secret stays on the server. It never needs to be part of the page someone downloads. Start at the Higsfield API

1:11 console on desktop. That is where you find the model catalog, keys, billing, and request analytics. The API has its own pay as you go wallet separate from the regular Higsfield subscription. My

1:22 account already has $70 available here with zero requests in the before recording. That is my starting balance, not a promise of $70 free. For your own account, check billing in the ad credits

1:33 option before making a paid request. In Explore, I look through the available workflows, then the image models and the video models. One model can have several modes. Text to video starts with a

1:44 description. Image to video also needs a starting image. Before wiring one into the app, check its required inputs in the docs. The settings are not identical across every model. I also try a quick

1:54 image on the Higsfield website. I enter a beach boardwalk at Golden Hour. Check the image model and click generate. Then I open the finished image. This is a separate website test. The API wallet

2:06 and the app come next. For the integration, Higsfield already gives us a setup prompt. It is right here on the console's quick start page. I click copy prompt, switch over to codeex, and paste

2:16 it into the chat. Then I add the folder path for the app I already built and send it. The prompt tells Codex to inspect the project and read Higsfield's current documentation before making

2:26 changes. That is the starting point they provide. The project path is the part I add. Codeex starts checking the project and the docs. I want the existing interface connected to real generation.

2:36 Submit the request, keep its ID, follow the progress, and load the result when it is ready. The first integration only covered a few options. So I asked for the wider catalog and controls that

2:47 match the original design. This version lists 76 models and modes that is catalog coverage. I have not personally tested every one of them. Next I open API keys and create a key. I name it

2:59 cloud. Then wait for the full credential to appear. Now I click copy API key. That name is just a label. The copied credential is what the server needs. Store it privately. Here I paste the

3:10 full credential into Notepad so I can split it. Before the colon is the key ID. After the colon is the secret, I move each part into its matching field. Then remove the temporary line. It is a

3:21 colon, not a semicolon. I actually tripped over the file itself. The credentials were inenv.ample while the server was reading. Env. So the app kept saying the API was

3:32 required. The values were there just in the wrong file. I know it's a silly mistake, but we're human. It happens. The fix was to put them in the real.v file, save it with control s and restart

3:45 the server. The example file goes back to placeholders. If your app still says not connected, check the file name and whether the server has reloaded it. Now look at what the server sends. The model

3:55 determines the endpoint. The authorization header combines the ID and secret and the body contains the prompt plus that model settings. For this run, I use soul 2 and asked for a running

4:05 horse. There is another important step between clicking generate and seeing an image. A generation is a job. You get a request ID, then check its status while it is cued or processing. Keep that ID

4:17 so the app can follow the same job. Higsfield recommends starting those checks about 2 seconds apart and gradually backing off to 10 seconds. Stop when the job reaches a final state.

4:27 Now I enter the running horse prompt, choose the image settings, and click generate. Then the app shows submission unknown with no horse in the preview. From this screen alone, I cannot tell

4:37 whether the provider accepted the request. The integration log explains what happened. Higsfield returned a status link using its platform domain. My app expected the API domain and

4:47 rejected the link. The image had completed. My app was failing to retrieve its status. We corrected that handling for the known Higsfield URL and checked the existing request through the

4:57 documented API endpoint. The horse appeared without submitting another generation. That is a useful distinction. Retrying a status check is different from creating a new paid job.

5:07 Here's the completed request and its returned image URL. That URL is what the preview can load and the download button can save. A response marked completed with the actual output is much stronger

5:18 evidence than a green connected badge. And here is the original image. I deliberately kept the prompt simple. Before spending time on elaborate creative direction, I want to know that

5:28 the request, response, preview, and download are all connected. Once that works, improving the prompt becomes a separate task. Next, I click animate this image. The finished soul image

5:38 becomes the starting reference for the video request. I use Cance 2.0 in this run. Even though the catalog also shows other models, the save job tells us exactly which one produced the result. I

5:49 ask it to animate the running horse. Check the duration and resolution, then submit. Settings matter here. Changing the length, resolution, or audio can change the price. match the settings you

5:59 are paying for to what your project actually needs. While that runs, the app keeps the request in history and checks for progress. The visible waiting time is cut down in this edit. When the job

6:09 finishes, the preview switches to the returned video. Here is the original 5-second file with its generated sound. That is our imagetovideo loop working inside the app. The image becomes a

6:25 reference. The video model adds motion and we get a file we can download. It proves this path works. It does not tell us how every model will behave on every prompt. Now the part I would check

6:36 before building anything bigger, the bill. The after recording shows two requests, $130 spent and a balance of $68.70. The starting balance was 70. So those

6:47 numbers agree. The dashboard breaks that into 1 cent displayed for soul 2 and $1.29 for the seed dance video. Those are the displayed rounded amounts for this run. Most of the spend went into

6:58 the video, so that is where I would watch duration and resolution first. One thing I still want to improve is the estimate inside my app. Right now, this version links to console for pricing.

7:08 Higsfield documents an estimate endpoint that accepts the generation settings and returns the cost before submission. That would be my next integration step. The important part is using the exact same

7:18 model and settings for the estimate and the generation. If someone changes the duration after seeing the price, refresh the estimate. A number that no longer matches the request is not useful

7:28 guidance. The pricing page in my recording advertises up to 50% off two video models and one image model for 7 days. The campaign also offers business email verification credits. Check the

7:39 current eligibility and prices in your own account before you choose your models. Higsfield also says to contact its sales team during your first week if you want to arrange a one-year price

7:48 lock. I have not activated that in this demo. It is worth asking about if you are planning ongoing usage rather than a small test like mine. For a local experiment, this is enough to learn a

7:58 lot. Before opening it to other people, I would add proper sign-in per user spending limits and durable storage for the outputs. Download the files you want to keep. The documentation only promises

8:09 access for at least 7 days. A working generation button is the start of an application, not the whole application. My biggest takeaway is to keep each part observable. Can the server read the

8:20 credentials? Did the provider accept a request? Is it still processing? Or did it return a file? Following that chain helped recover the result instead of paying to repeat it. If you want to try

8:31 the Higsfield API, my link and the documentation are in the description. Start with one image, follow its request through to completion, then animate it. You will understand far more from that

8:41 small working loop than from a huge unfinished interface.