Execute AI Model returns response of type `ai.AIRunResponseAudio` for `TextToImage` request

[amanbolat]

Confirm this is a Go library issue and not an underlying Cloudflare API issue

• This is an issue with the Go library

Describe the bug

Hi,

I tried to use this library to generate an image from the text prompt. According to the example here the response should follow the scheme:

{
    "type": "object",
    "contentType": "application/json",
    "properties": {
        "image": {
            "type": "string",
            "description": "The generated image in Base64 format."
        }
    }
}

Besides, I would expect that ai.AIRunResponseUnion could be casted to a TextToImage specific struct.

However, when I run the provided code snippet, I get the result where the type of the response is ai.AIRunResponseAudio.

Questions:
Is it an expected behavior?
Is there a specific type for TextToImage response?

Example spew dump of the response is below:

(ai.AIRunResponseAudio) {
 Audio: (string) "",
 JSON: (ai.aiRunResponseAudioJSON) {
  Audio: (apijson.Field) {
   raw: (string) "",
   status: (apijson.status) 0
  },
  raw: (string) (len=814380) "{\"image\":\"/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH"}",
  ExtraFields: (map[string]apijson.Field) (len=1) {
   (string) (len=5) "image": (apijson.Field) {
    raw: (string) (len=814370) 
"\"/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH",
    status: (apijson.status) 2
   }
  }
 }
}

To Reproduce

1. Run client.AI.Run with model @cf/black-forest-labs/flux-1-schnell and body ai.AIRunParamsBodyTextToImage
2. Debug the response using spew.

Code snippets

package ai_test

import (
	"context"
	"errors"
	"fmt"
	"os"
	"testing"

	"github.com/cloudflare/cloudflare-go/v4"
	"github.com/cloudflare/cloudflare-go/v4/ai"
	"github.com/cloudflare/cloudflare-go/v4/option"
	"github.com/davecgh/go-spew/spew"
	"github.com/stretchr/testify/require"
)

func TestName(t *testing.T) {
	client := cloudflare.NewClient(
		option.WithAPIToken("<api_token>"),
	)
	res, err := client.AI.Run(
		context.TODO(),
		"@cf/black-forest-labs/flux-1-schnell",
		ai.AIRunParams{
			AccountID: cloudflare.F("<account_id>"),
			Body: ai.AIRunParamsBodyTextToImage{
				Prompt: cloudflare.F("red cat on the table"),
			},
		},
	)
	if err != nil {
		var apierr *cloudflare.Error
		if errors.As(err, &apierr) {
			t.Log(string(apierr.DumpRequest(true)))
		}
		t.Fatalf("err should be nil: %s", err.Error())
	}

	fmt.Printf("%T", *res)

	// v, ok := (*res).(*ai.AIRunResponseAudio)

	f, err := os.Create("./dump.txt")
	require.NoError(t, err)
	spew.Fdump(f, *res)
}

OS

macOS

Go version

go1.24.2

Library version

github.com/cloudflare/cloudflare-go/v4 v4.2.0

[jhutchings1]

Thanks for reporting, I've directed this to the feature team to have a look.

[github-actions]

This issue hasn't been updated in a while. If it's still reproducing, please comment to let us know. Thank you!

[ranyu696]

Based on the Cloudflare Go SDK document you provided, I now have a deeper understanding of the technical details of the BGE-M3 audio response issue. Let me analyze this issue:
In-depth technical analysis of the BGE-M3 audio response issue

1. SDK type system issue
   From the document, you can see that the Cloudflare Go SDK uses a strict type system:
   Apply to embedding_se...
   This union type includes:
   AIRunResponseTextEmbeddings - text embedding response
   AIRunResponseAudio - audio response
   Various other response types
   The problem is that when we call BGE-M3, the SDK returns the AIRunResponseAudio type instead of the expected AIRunResponseTextEmbeddings type.
2. Problems at the model routing level
   From your code call:
   Apply to embedding_se...
   We correctly used:
   AIRunParamsBodyTextEmbeddings as the request body type
   shared.UnionString(processedText) as the text input
   But Cloudflare's model routing system still returned AIRunResponseAudio, which indicates that the problem occurs in the model scheduling layer inside Cloudflare.
3. Possible root causes
   A. Model identifier mapping error
   Cloudflare may have incorrectly mapped @cf/baai/bge-m3 to the endpoint of the audio processing model instead of the text embedding model.
   B. Request body parsing problem
   Although we sent AIRunParamsBodyTextEmbeddings, Cloudflare's API gateway may have incorrectly parsed it as an audio request.
   C. Confusion caused by BGE-M3's multimodal nature
   BGE-M3 supports multiple input formats:
   Standard embedding: {"text": "string"}
   Query-context: {"query": "...", "contexts": [...]}
   This multimodality may cause confusion to Cloudflare's routing system.
4. Why other models work fine
   From the SDK documentation, other models such as @cf/baai/bge-base-en-v1.5 are single-purpose embedding models that:
   Only support AIRunParamsBodyTextEmbeddings input
   Only return AIRunResponseTextEmbeddings output
   No multimodal capabilities, simpler routing
5. Correctness of our current solution
   Our error detection and downgrade mechanism is correct:
   Apply to embedding_se...
   This correctly:
   Detected the type mismatch
   Logged the specific problem
   Triggered the downgrade mechanism
6. Proposed solution
   Short-term solution (which we have implemented):
   ✅ Detect audio response type
   ✅ Downgrade to analog embedding
   ✅ Detailed error log
   ✅ The service continues to run
   Interim solution:
   Report to Cloudflare: Report the model routing issue of BGE-M3 to Cloudflare technical support
   Try different call formats: Test whether using array format will have different results
   Monitor problem patterns: Collect more data to help Cloudflare diagnose
   Long-term solution:
   Wait for Cloudflare to fix the routing issue of BGE-M3
   Consider using other stable embedding models
   Or switch to other cloud service providers
   Conclusion
   This is indeed an infrastructure issue of Cloudflare Workers AI platform, not a problem with our code. The multimodal nature of the BGE-M3 model has a compatibility issue with Cloudflare's model routing system, causing text embedding requests to be incorrectly routed to the audio processing endpoint.
   Our current solution (error detection + degradation mechanism) is the best practice for handling such platform-level issues, ensuring the stability and availability of the service.

When I encountered this error, AI gave me the answer

[github-actions]

This issue hasn't been updated in a while. If it's still reproducing, please comment to let us know. Thank you!