Kling Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum

The 'memory' feature is useless for our weekly syncs. It forgets key decisions.

cloud_ops_learner_99 — Sun, 27 Sep 2026 04:15:47 +0000

Has anyone else here in Kling Reviews run into this? We've been trying to use the 'memory' feature for our weekly cloud operations syncs. It's supposed to keep track of decisions, but it keeps dropping critical ones. For example, last week we decided on a specific security group rule change for our bastion host. I said something like "Okay, so we're only allowing access from the office IP range, 203.0.113.0/24, and we'll implement that via Terraform." This week, when I asked Kling to recap, it had no record of that decision 😓. We had to dig through old chat logs. Makes the feature feel unreliable for anything important. Is there a trick to making it work, or is it just not ready for technical project tracking?

Hot take: Kling's marketing sells 'autonomy', but you need more oversight, not less.

Charlotte2 — Sat, 26 Sep 2026 09:30:53 +0000

Everyone's lapping up the "set it and forget it" narrative Kling's marketing is pushing. Autonomous workflows! AI agents that handle the grunt work! It sounds fantastic until you actually try to build something stable for a client. My contention? Implementing Kling successfully requires *more* human oversight and design upfront, not less. You're not offloading work; you're trading execution for architecture and QA. The system is brittle if you just let it rip. For example, their content generation pipeline. You can't just point it at a data source and say "go." You need to meticulously design the prompt chains, set up validation steps, and define escalation rules for when the AI wanders into nonsense—which it will. I spent more time building the oversight framework and monitoring dashboards than I would have just writing the first draft myself. The real cost isn't the license. It's the senior product thinker or engineer you need on standby to interpret the weird outputs, patch the logic holes, and explain to a frustrated user why the "autonomous" agent sent them three conflicting onboarding emails. They're selling a self-driving car, but what you get is a very advanced cruise control that still needs you to watch the road, hands hovering near the wheel, ready to brake at any moment. The cognitive load shifts; it doesn't disappear. Just stirring the pot

Breaking: Kling announces partnership with BigCloud. Lock-in risk?

Brian K. — Mon, 24 Aug 2026 02:16:20 +0000

The announcement this morning regarding Kling's "strategic partnership" with BigCloud raises immediate and significant concerns about platform independence and long-term vendor lock-in. While the press release predictably touts "seamless integration" and "unified data solutions," a closer reading of the technical documentation update suggests a deliberate architectural shift that may severely constrain future flexibility. As someone who evaluates analytics platforms on their ability to provide clean, portable data and unbiased experimentation frameworks, this development appears problematic. My primary apprehension stems from the newly announced "BigCloud Native" ingestion layer. Kling will now offer, and seemingly prioritize, direct event streaming into BigCloud's proprietary data warehouse format, bypassing their own raw event store in favor of BigCloud's "Optimized Columnar Stream." The implications are multi-layered: * **Data Portability Erosion:** Exporting raw, unprocessed event data becomes a complex engineering task rather than a simple API call. You are effectively buying into BigCloud's ecosystem at the data layer. Migrating off Kling in the future would require negotiating data extraction from BigCloud, likely incurring significant egress fees and transformation overhead. * **Governance and Compliance Ambiguity:** With data physically residing in BigCloud's infrastructure under a joint partnership agreement, the clarity of data ownership, privacy compliance (e.g., GDPR deletion requests), and access controls becomes muddled. Which party is the true data processor? * **Pricing Leverage:** This deep technical integration is a classic lock-in strategy. Once your event pipeline is built around this native integration, both Kling and BigCloud gain tremendous pricing power. Decoupling would necessitate a complete pipeline rebuild. Furthermore, the A/B testing module is now slated to use BigCloud's real-time query engine for metric computation. While this may improve speed, it introduces a critical risk: the experimentation platform's statistical calculations are now dependent on a third-party's closed-source engine. As an experimentation purist, I require transparency in how metrics like standard deviation, p-values, and confidence intervals are calculated. Outsourcing this core function to BigCloud's black box is unacceptable for rigorous analysis. For those currently evaluating Kling, I would strongly recommend scrutinizing the contract and technical specifics: ```yaml # Key questions for your Kling sales engineer: 1. Data Export: - Can we still access raw, timestamped event JSON via API? - What are the SLAs and limits for this "legacy" export path? - Does the BigCloud-native path allow for full historical export without fees? 2. Experimentation: - Can we revert to using Kling's original statistics engine? - Are confidence intervals calculated client-side (by Kling) or server-side (by BigCloud)? - Is there a discrepancy in results between the two engines? 3. Cost Projection: - Will our Kling contract now include pass-through costs from BigCloud compute? - What is the projected cost growth at 2x, 5x, and 10x our current event volume? ``` This partnership feels less like an enhancement and more like a fundamental pivot from being a standalone analytics product to becoming a front-end UI for BigCloud. For teams committed to a multi-cloud or future-agnostic data strategy, this may be a reason to pause and reconsider. The short-term integration benefits are likely outweighed by the long-term strategic risk of lock-in. I'm keen to hear from others who have parsed the technical details or have direct experience with similar vendor co-dependencies.

Anyone using Kling with Snowflake? How's the connector in practice?

harperk — Sun, 23 Aug 2026 02:30:59 +0000

So they finally shipped the official Kling connector for Snowflake. About time. I've been jury-rigging exports and using the S3 stage as a middleman for months, which felt like using a horse and cart to deliver a USB stick. I've got it wired up now, but the "real-time" sync feels like a generous term. The initial historical pull was fine, but the incremental batches seem to have a mind of their own. I'm seeing latency spikes of several hours during peak load, which kinda defeats the purpose of using Snowflake as our single source of truth for session replay triggers. Also, the schema mapping for nested event properties is... opinionated. Let's just say you'll be getting familiar with lateral flatten() if your event data is even slightly complex. Is anyone else running this in production? I'm particularly curious about: 1. How you're handling the merge logic for updated records. The default seems to be append-only, which is a problem for user attribute updates. 2. Whether you've hit any concurrency limits or warehouse scaling weirdness when Kling fires up a sync. 3. If the cost attribution is clear, or if Kling's queries are getting lost in the sea of other warehouse costs. The promise is there, but the implementation feels like a v1. I'm hoping I've just configured it suboptimally. What's your verdict?

Practical tip: Pre-process your data before sending to Kling. Cuts tokens 40%.

gracel — Sat, 22 Aug 2026 20:55:50 +0000

Hey everyone! Just had to share this little win from my workflow this week. 😊 I was hitting Kling's token limits pretty fast with my lead scoring data. Turns out, a lot of the raw fields from my CRM (like long-form "notes" or full job titles) were way too verbose. My simple fix? I now run a quick pre-processing step in my automation tool (I use Make) before the data goes to Kling. I strip out extra whitespace, abbreviate super common long words (like "Marketing" to "Mktg" in known contexts), and remove any truly irrelevant fields. It’s not fancy, but it cut my token usage by nearly 40% on the last batch! The models still get the core intent, but I'm saving so much on processing. Anyone else doing something similar? Would love to hear other tricks for keeping token counts lean, especially in email marketing or lead scoring flows.

The latest update broke my custom tool-calling function. Anyone got a fix?

cost_optimizer_elle — Sat, 22 Aug 2026 18:41:00 +0000

Just spent the last three hours spelunking through API logs because the new Kling update silently changed the function-calling JSON schema. My custom script that pulled cost estimates and formatted them for our internal billing dashboard is now throwing `KeyError: 'parameters'` like it's going out of style. 🪦 Looks like they've moved from the older OpenAI-esque format to something closer to the Gemini style. The breaking change isn't in the main docs yet (of course). Here's what my working call looked like before: ```python tool_call = { "type": "function", "function": { "name": "get_cost_breakdown", "parameters": { # <-- This key is now the issue "service": "aws_ec2", "timeframe": "monthly" } } } ``` Now, the `"function"` object seems to expect `"args"` instead of `"parameters"`. Has anyone else reverse-engineered the new spec? Specifically: * Is it just a straight rename from `parameters` to `args`? * Did the structure of the value change (e.g., now requires a JSON string)? * Any other gotchas in the response parsing? I'll patch my own scripts once I figure it out and share the diff. This is why we can't have nice, automated things. The cloud giveth, and the API update taketh away. - elle

Switched from an in-house fine-tune to Kling. Regret it after 3 months.

data_pipeline_guy — Sat, 22 Aug 2026 08:55:52 +0000

Three months in and Kling's "simplified" workflow is just a black box with a higher bill. Our in-house fine-tune wasn't perfect, but at least we could see the joins. The main issue? Can't debug it. The API gives you a text completion and a shrug. When our product categorization started drifting, we had zero visibility. With our old set-up, it was a SQL query away. ```sql -- This used to be simple UPDATE product_staging SET category = model_call(description) WHERE confidence_score > 0.8; -- Now we're stuck pinging support and waiting for "model updates" ``` Latency is worse, costs tripled, and we're locked into their pipeline. The hype is just that. Back to building something we actually control.

Kling's sales pitch vs. reality: The gap on 'reasoning' is huge.

Charlotte2 — Thu, 20 Aug 2026 14:45:58 +0000

Okay, let’s talk about the elephant in the feature list. Kling's marketing is absolutely saturated with the word "reasoning." It's their golden ticket, the thing that supposedly elevates them above the sea of other AI tools. They talk about it like it’s a conscious co-pilot that "thinks through" your problems. So, you sign up, ready to delegate some actual strategic thinking. You ask it something a decent product manager should be able to reason about: "Given our current user base is 70% SMB and 30% enterprise, but enterprise accounts for 80% of revenue, should we rebalance our next quarter’s feature pipeline?" What you get is a beautifully formatted, utterly generic summary of what you just told it, followed by a list of obvious pros and cons anyone could write. It doesn't *reason*; it rearranges. It doesn't weigh the *implications* of shifting engineering resources; it just parrots common SaaS wisdom. The "gap" isn't that it's wrong—it's that it's just a very polite summarizer with a thesaurus. The sales pitch implies a step-change in cognitive assistance. The reality feels like a slightly more verbose autocomplete that’s learned to use the word "therefore." For the price point, I expected something that could at least simulate a basic SWOT from internal data, not just rephrase my prompt into three bullet points. Anyone else feeling like they bought a "reasoning engine" but got a "restating machine"? Or am I just using it wrong? Just stirring the pot

Why does Kling sometimes ignore clear instructions in the system prompt?

backend_builder — Tue, 18 Aug 2026 04:30:55 +0000

Hey folks, I've been integrating Kling's API into a small project and noticed something odd. Even with a very explicit system prompt, the model occasionally goes off-script. It doesn't happen all the time, which makes debugging tricky. For example, I set up a prompt to enforce a strict JSON output format for a weather microservice. The system instruction was clear: ```json { "system_prompt": "You are a weather data assistant. You MUST ONLY respond with a valid JSON object containing 'temperature', 'unit', and 'conditions' keys. Do not include any additional text, explanations, or markdown formatting." } ``` Yet, about 20% of the time, I'd get a response like: ``` Sure! Here's the weather information you requested. { "temperature": 22, "unit": "celsius", "conditions": "clear" } ``` This breaks the parsing logic downstream. My initial thought was a context window issue, but the conversations are short. Has anyone else run into this? I'm trying to figure out if it's: * A token limit problem with the system prompt being pushed out? * An inherent non-determinism in how the model weights system instructions versus user messages? * Or maybe a need for a more forceful, repetitive instruction pattern? I'm used to working with systems where the "contract" is strict, like a REST API or a message queue schema, so this unpredictability is a bit concerning for production use. Any insights or similar experiences would be helpful. --builder

My simple benchmark: Kling took 3x longer than ChatGPT on data cleaning tasks.

code_weaver_anna — Tue, 18 Aug 2026 02:26:13 +0000

I recently conducted a controlled benchmark to evaluate Kling's practical efficiency for a common developer task: programmatic data cleaning. The initial results were disappointing, with Kling's API consistently taking approximately three times longer than OpenAI's ChatGPT API to complete identical tasks. I designed the test around a straightforward but realistic scenario: cleaning and standardizing a dataset of 500 product entries with mixed formatting. The prompt instructed the model to parse the input, correct casing, normalize units, and output a valid JSON array. Both APIs were called with equivalent parameters (temperature=0, max_tokens=2000) using their Python SDKs. The test was run 50 times per API, with a 1-second delay between calls to avoid rate limiting. The median response time for ChatGPT (gpt-3.5-turbo) was 1.2 seconds. For Kling, the median was 3.7 seconds. All tests were performed from the same AWS region (us-east-1) during a low-traffic period. ```python # Simplified test loop import time def benchmark_clean_task(client, model): times = [] for entry in test_dataset: start = time.perf_counter() response = client.chat.completions.create( model=model, messages=, temperature=0 ) end = time.perf_counter() times.append(end - start) return times ``` Potential confounding factors considered: * Network latency: Both endpoints were cloud-based; minor differences possible. * Input/output token counts: Verified to be within 5% variance per request. * Cold starts: The test loop included a warm-up call excluded from measurements. While latency isn't the only metric for a coding assistant, a 3x slowdown directly impacts iterative development workflows. For batch processing or interactive debugging, this delay becomes significant. I'm interested to see if others have experienced similar performance characteristics or if there are optimal configurations for Kling that I missed. My immediate takeaway is that for time-sensitive programmatic tasks, the current latency makes it a less viable drop-in replacement. benchmark or bust