Create AI agent by describing it
Turn a plain-English job into a cloud agent, review a real run, and freeze the accepted workflow for reuse.
Read the guide →Your model behind a tested inference endpoint
An agent can call a custom model after you deploy and verify an inference endpoint it can reach through the supported model workflow. Package the model with the FlyMy.AI CLI, declare inputs and outputs, and test a small request first. Confirm GPU availability, model compatibility and scaling behavior before promising production latency or cost.
Identify the model weights, license, dependencies, GPU memory and expected input size. A fine-tuned Stable Diffusion model or LoRA needs its actual compatibility verified; this guide does not establish support for every checkpoint or adapter.
Use the documented CLI commands below. Load weights in initialize and perform one inference in predict. Keep the declared input/output types within the current CLI contract. The current documentation says predict accepts and returns plain dictionaries.
Follow the CLI authentication guide and deploy from the initialized project. Inspect the resulting metadata and endpoint schema. Keep credentials out of committed model files and published examples.
Confirm one real inference, its output and resource usage before adding the endpoint to an agent. Discover the supported model call contract and current price. Verify scale-to-zero and cold-start behavior for this deployment before relying on them.
pip install git+https://github.com/flymyai/fma-custom-models.gitRun in your chosen Python environment, then follow the CLI documentation.
mkdir my-project && cd my-project
fma init my_modelImplement model.py and review metadata.yaml before deploying.
fma deployAuthenticate using the documented CLI flow first. This command is copied from the deployment step; it is not evidence that the model has been deployed.
model: your deployed endpoint input: a schema-valid sample request status: completed after verification output: declared model result agent_step: use the verified endpoint contract
Return the declared inference output to the calling application or agent. Image, audio and file fields have documented types; choose an explicit delivery or storage step if the result must leave the execution.
GPU time, model size, dependency loading and request payloads affect resource usage. Measure startup, peak memory and inference latency on the chosen configuration. [[FACT NEEDED: verified LoRA/checkpoint compatibility, GPU selection, scale-to-zero policy, cold-start latency and price for the specific custom model.]]
Check current pricing| Approach | What to evaluate |
|---|---|
| A custom FlyMy.AI model | Use when your reviewed weights and inference code need an endpoint that the agent can call. Verify the actual deployment contract. |
| An existing catalog model | Useful when a listed model already meets the job, so you do not need to maintain weights and packaging. |
| Your own GPU service | Useful when you want to operate the deployment, scaling, authentication and resource monitoring yourself. |
No universal compatibility claim is made here. Verify the selected weights, adapter, dependencies and GPU memory with a real sample.
Confirm the current scaling and billing policy for the specific deployment. This guide does not promise zero idle cost or a fixed cold-start time.
The documented initialize method prepares the model when its container starts; predict handles inference requests. Keep the request path bounded and measure its memory use.
Turn a plain-English job into a cloud agent, review a real run, and freeze the accepted workflow for reuse.
Read the guide →Plan a CSV-to-images workflow with a tested generation step, bounded concurrency and per-row execution records.
Read the guide →Sources checked 2026-10-23. Examples are documentation excerpts, not a claim that a paid run has been performed.